Possible causes to your problem :
- Some application settings might be configured as "slot-specific." If these settings include configurations pointing to older builds or deployment artifacts, they may cause inconsistencies when slots are swapped.
- During the slot swap, if the testing slot does not retain the updated deployment after the swap, it could be due to a configuration issue or a rollback mechanism reverting to the older deployment.
- If there are multiple pipelines deploying code or if old pipelines are still active, they might overwrite the deployment in the testing slot after the swap.
- The swap operation might not fully complete due to caching or lock conflicts. Although it shows as successful, there might be underlying issues with the swap operation.
-App Service might still hold onto older deployment artifacts due to filesystem caching or incomplete cleanup during redeployments.
-A GitHub Actions job or another CI/CD process might inadvertently redeploy an older version after the swap operation completes.
To help you troubleshoot your issue :
Go to Configuration in the Azure Portal for your App Service to check for any slot-specific settings (marked with a check in the "Slot Setting" column).
You can use the Kudu Console (accessible via https://<app_name>.scm.azurewebsites.net/
) to verify the content in the wwwroot
directory and then clear it.
In your GitHub workflows, review the logs to see if old jobs are being triggered and redeploying to the testing slot.
If the issue remains unresolved, contact Azure Support with detailed logs from your CI/CD pipelines, deployment logs, and swap diagnostics.