Debugging an Azure Container Apps Deploy Failure in GitHub Actions

Also see Azure Container Apps ImagePullBackOff Error

I had a PROD GitHub Actions workflow that had been deploying fine, then suddenly started failing on the azure/container-apps-deploy-action@v1 step with an UNAUTHORIZED error when pulling the image. Here’s how I added temporary debug steps to the pipeline to pin down the actual cause instead of guessing.

The failure

The az containerapp update call the action runs under the hood failed with:

1
2
3
4
5
6
ERROR: Failed to provision revision for container app 'chatbot-worker-produk'. 
Error details: The following field(s) are either invalid or missing. 
Field 'template.containers.chatbot-worker-produk.image' 
is invalid with details: 'Invalid value: "myregistry.azurecr.io/myapp:8489162": 
GET https:?scope=repository%3Amyapp%3Apull&service=myregistry.azurecr.io: 
UNAUTHORIZED: authentication required, visit https://aka.ms/acr/authorization for more information. CorrelationId: ...'

This is a pull error, not a push error - the build/push job earlier in the workflow succeeded, so the image was definitely in ACR. Something about how the Container App itself authenticates to pull was broken.

Add debug steps instead of guessing

Rather than trying random fixes against a live PROD app, I added two extra steps after the deploy step with if: always(), so they run whether or not the deploy step succeeded:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
- name: Debug - show current ACR registry config on the Container App
  if: always()
  run: |
    az containerapp registry list \
      -g chatbot-worker-produk-rg \
      -n chatbot-worker-produk \
      -o table
    az containerapp show \
      -g chatbot-worker-produk-rg \
      -n chatbot-worker-produk \
      --query "properties.template.containers[0].image" \
      -o tsv

- name: Debug - check AcrPull role assignment for the deploy service principal
  if: always()
  run: |
    acrId=$(az acr list --query "[?loginServer=='${{ vars.PRODUK_ACR_SERVER }}'].id" -o tsv)
    spClientId=$(az account show --query user.name -o tsv)
    az role assignment list --assignee "$spClientId" --scope "$acrId" -o table

The first step dumps whatever registries are currently configured on the Container App plus the image it’s actually running. The second checks whether the service principal used by azure/login has an AcrPull role assignment scoped to the ACR.

What the debug output revealed

az containerapp registry list came back empty - no registries configured on the app at all. And the image query returned mcr.microsoft.com/k8se/quickstart:latest, the default placeholder Azure ships with new Container Apps. That told me this app had never successfully received an image from ACR, despite previous “successful” workflow runs.

That’s the key detail: a Container App remembers its registry credentials on the resource itself, not just for the run that configured them. Once az containerapp registry set runs successfully, that config sticks around across every future deploy. This PROD app just never had it set in the first place.

The fix

azure/container-apps-deploy-action needs registryUsername/registryPassword (or acrUsername/acrPassword if using acrName) to configure that registry the first time:

1
2
3
4
5
6
7
8
with:
  registryUrl: ${{ vars.PRODUK_ACR_SERVER }}
  registryUsername: ${{ secrets.PRODUK_ACR_USER }}
  registryPassword: ${{ secrets.PRODUK_ACR_PASSWORD }}
  imageToDeploy: $ACR_SERVER/$ACR_USER:$IMAGE_TAG
  containerAppName: chatbot-worker-produk
  containerAppEnvironment: chatbot-produk
  resourceGroup: chatbot-worker-produk-rg

Running the workflow with these in place fixed the deploy immediately - the debug step’s registry list was no longer empty, and the image matched what had actually been pushed.

This also explained something that had been bugging me: a sibling UAT workflow deploys fine without registryUsername/registryPassword at all. That’s because UAT’s Container App already had its registry configured from an earlier deploy, so it doesn’t need to be told again. Once I confirmed the same was now true for PROD, I removed the debug steps and the credentials from the workflow, and a follow-up deploy still succeeded - the config had persisted on the Container App resource itself.

Takeaway

If azure/container-apps-deploy-action fails with an ACR UNAUTHORIZED pull error, don’t assume it’s the service principal’s role assignment. Check what’s actually configured on the Container App with az containerapp registry list first - if it’s empty, the app has simply never had registry credentials set, and providing registryUsername/registryPassword once will fix it for good.

Docs: Azure Container Apps Build and Deploy action • az containerapp registry