Github private docker registry, the token expires before the deployment completes

[leonk]

I'm using private GitHub packages for my docker registry, and deploying to Azure App Service.

In order to authenticate with the GitHub docker registry, I need to use an access token. Most of the online tutorials suggest to use a personal access token (PAT), but I really want to avoid that, and instead use the access token provided by github actions.

However, what I've found that is that because the access token expires when the github action workflow completes, this happens before the deployment in Azure has completed. We then end up with authentication errors in Azure cannot pull the image from GitHub.

Example github actions yaml

...
  job-name:
    name: Example job
    runs-on: ubuntu-20.04
    steps:
      - name: Azure Login
        uses: Azure/login@v1.4.3
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Update secret on PR deployment slot
        uses: Azure/cli@v1.0.7
        with:
          inlineScript: az webapp config container set
            --name ${{ vars.AZURE_WEBAPP_NAME_SBOX }}
            --resource-group ${{ vars.AZURE_RESOURCE_GROUP_SBOX }}
            --slot preview-pr-${{ github.event.pull_request.number }}
            --docker-registry-server-user ${{ github.actor }}
            --docker-registry-server-password ${{ secrets.GITHUB_TOKEN }}

      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v2
        with:
          app-name: ${{ vars.AZURE_WEBAPP_NAME_SBOX }}
          slot-name: preview-pr-${{ github.event.pull_request.number }}
          images: ghcr.io/${{ github.repository }}:sha-${{ github.sha }}

The only way I can see to get it to work, is to add in something like

        run: sleep 30s

But ideally the azure/webapps-deploy would wait until the deployment had successfully completed.

[leonk]

I suspect this a limitation with the azure api.

A workaround I've got is using the following step:

      - name: Wait for deployment to finish
        uses: nev7n/wait_for_response@v1
        with:
            url: ${{ steps.environment_url.outputs.url }}
            responseCode: 200
            timeout: 2000
            interval: 500

[github-actions[bot]]

This issue is idle because it has been open for 14 days with no activity.

[sgollapudi77]

Hi @leonk, in case of deployment to custom containers, we're just updating the App configuration pointing to new image and restarting the app as seen from here. We're not awaiting on the deployment status because that is taken care by App Restart which is failing because the Github token expires assuming the action is completed.

Currently there are two ways to workaround this:

1. You can use PAT tokens with expiry date so that App uses this token to pull the image. This is the recommended way.
2. The second way is awaiting till deployment is complete as you're doing to prevent the GITHUB_TOKEN from expiring. This is usually not the recommended way because this may fail in the cases where the worker on which App is running may restart or a different worker spawns up your App by which time the GITHUB_TOKEN would have expired.

Please let us know if there is anything you need from our side. Thanks.

[leonk]

Thanks @sgollapudi77, good to know about the restart. I'm guessing there's no other way to initiate a deployment using a docker image?

In regards to your comments about why you recommend against using GITHUB_TOKEN (and to use a PAT instead)

this may fail in the cases where the worker on which App is running may restart or a different worker spawns up your App by which time the GITHUB_TOKEN would have expired.

Firstly, I believe that Azure cache's the docker image. When we restart our app service, which was using a GITHUB_TOKEN, the app still runs successfully.
Secondly, a PAT could also have expired when an app service is restarted (this is probably why Azure cache's the docker image), so this would still be an issue (although less likely to occur, depending on how long you set your PAT to expire).

Ultimately using GITHUB_TOKEN has several benefits (security and maintenance) so we'll continue trying to use this.

However, we found another issue with it. The step we added uses: nev7n/wait_for_response@v1 (see previous comment) would sometimes run even before the deployment/restart had commenced. Resulting in a 200, from the previous deployment, this would then finish our deployment GH actions workflow, and so the GITHUB_TOKEN would be expired before the deployment/restart had finished. So to resolve this we are now running a run: sleep 5s before the wait_for_response step. Not ideal, but it works (for now).

[github-actions[bot]]

This issue is idle because it has been open for 14 days with no activity.