webapps-deploy: Docker image deployment not triggering image pull
We use a Docker deployment for our Web App, using the example that was provided here: https://github.com/Azure/actions-workflow-samples/blob/master/AppService/docker-webapp-container-on-azure.yml
The only difference is that we don’t do
- name: 'Deploy to Azure Web App for Container'
uses: azure/webapps-deploy@v2
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }}
images: ${{ env.CONTAINER_REGISTRY }}/nodejsapp:${{ github.sha }}
but instead
- name: 'Deploy to Azure Web App for Container'
uses: azure/webapps-deploy@v2
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }}
images: ${{ env.CONTAINER_REGISTRY }}/nodejsapp:latest <-- we use latest instead of the SHA
… because we can’t afford to have a new image SHA for every deployment we do and have that pushed to ACR. We only have the dev
and latest
tags for now, for our development and production environments, respectively. That’s enough for this small app we’re building.
Even though the GitHub Action mentions that the deployment has finished:
Deploying image ***.azurecr.io/REDACTED:dev to App Service REDACTED-backend-dev
Successfully deployed image to App Service.
Successfully updated deployment History at https://REDACTED.scm.azurewebsites.net/api/deployments/REDACTED
App Service Application URL: http://REDACTED-backend-dev.azurewebsites.net
… the App Service doesn’t download the latest image. I have to go into the Azure Portal and click “Restart” - then the updated image will be downloaded.
It looks like a similar issue was fixed in Azure Pipelines a while ago: https://github.com/microsoft/azure-pipelines-tasks/issues/9530
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 2
- Comments: 18 (5 by maintainers)
Hi, We have investigated this issue and we will be working on it soon.
Hmm so at the API level, I assume some check like
if (oldTag === newTag) { return; }
is done, would it make sense to remove this check or would that be throwing out the baby with the bathwater?One solution could be to add a check for the tag “latest” but if you’ve got other distribution tags where it still needs to trigger, the problem will persist for those non-latest tags.
Another solution which I think makes more sense in checking that the image has changed since last deploy, is by checking the image digest (sha256 string), if that one changed since last time you know for sure whether you should trigger a deploy, regardless of whether the tag changed or not.