GitHub Events not being triggered for auto-merged Dependabot PRs
Background
A really nice feature of this configuration is that when a PR is created in GitHub a test static website environment site is built in Azure to review the changes. When the PR is closed the test environment site is deleted.
This functionality is working fine for manually created PRs irrespective of whether the PR is manually merged and closed, or completed using the Github auto-merged feature.
Issue
The problem occurs if Github Dependabot and Actions based automation is used.
If a PR is created by Dependabot and manually merged, all the workflows trigger correctly to deploy the updated site and delete the test environment, as expected.
However, if I use a version of the Github documented 'approve a Dependabot pull request' action workflow to approve any Dependabot created PRs, as follows
1name: Dependabot auto-merge
2on: pull_request
3
4permissions:
5 pull-requests: write
6 contents: write
7
8jobs:
9 dependabot:
10 runs-on: ubuntu-latest
11 if: ${{ github.actor == 'dependabot[bot]' }}
12 steps:
13 - name: Dependabot metadata
14 id: metadata
15 uses: dependabot/fetch-metadata@v1.1.1
16 with:
17 github-token: "${{ secrets.GITHUB_TOKEN }}"
18 - name: Enable auto-merge for Dependabot PRs
19 if: ${{steps.metadata.outputs.update-type == 'version-update:semver-patch'}}
20 run: |
21 gh pr review --approve "$PR_URL"
22 gh pr merge --auto --merge "$PR_URL"
23 env:
24 PR_URL: ${{github.event.pull_request.html_url}}
25 GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
it is not working as expected. What is happening is the PR is merged, but other workflows are not triggered, so the site is not redeployed off main and the test environment is not deleted, so I soon reach the limit for the maximum number of test environments I can have, so future PRs fail through lack of available Azure environment slots.
Analysis
The issue was the use of the GITHUB_TOKEN
, the automatically generated action session token. I had not considered that GitHub Actions triggers do not happen when an operation is performed with the GITHUB_TOKEN
, as documented by Github
This is still true then the action is triggered by the gh
command line tool, as in the above example. It is the use of the GITHUB_TOKEN
that is the key factor.
Thanks to Rob Bos for reminding of this constraint, and also letting me know I was not the only one to have been recently caught out by this, as can be seen in William Brawner's recent blog post.
Solution
Armed with this information and using Rob's blog post on using Github Apps for authentication, I performed the following steps:
Created a Github App with the following permissions
- Repo - Contents: Read & Write
- Repo - Metadata: Read-only (automatically selected)
- Repo - Pull Requests: Read & Write
Created secrets (Settings > Secrets & Variables > Dependabot) to provide the Dependabot triggered workflow with the App ID and Key need to get a short-lived token for the workflow to use.
Remember Dependabot cannot access Actions secrets or variables, it has its own set of secrets to minimise any potential secret leakage
Updated the workflow to use a token generated from a GitHub App
1name: Dependabot auto-merge
2on: pull_request
3
4permissions:
5 pull-requests: write
6 contents: write
7
8jobs:
9 dependabot:
10 runs-on: ubuntu-latest
11 if: ${{ github.actor == 'dependabot[bot]' }}
12 steps:
13 - name: Get Token
14 id: get_workflow_token
15 uses: peter-murray/workflow-application-token-action@v3
16 with:
17 application_id: ${{ secrets.GH_APP_ID }}
18 application_private_key: ${{ secrets.GH_APP_KEY }}
19
20 - name: Dependabot metadata
21 id: metadata
22 uses: dependabot/fetch-metadata@v1.1.1
23 with:
24 github-token: "${{ steps.get_workflow_token.outputs.token }}"
25 - name: Enable auto-merge for Dependabot PRs
26 if: ${{steps.metadata.outputs.update-type == 'version-update:semver-patch'}}
27 run: |
28 gh pr review --approve "$PR_URL"
29 gh pr merge --auto --merge "$PR_URL"
30 env:
31 PR_URL: ${{github.event.pull_request.html_url}}
32 GITHUB_TOKEN: ${{ steps.get_workflow_token.outputs.token }}
Once all these changes were made the workflows operated as expected. The test environment was deleted and the site redeployed off main as soon as the PR was closed, whether merged or not.
So an interesting little learning experience. I hope the steps in this post helps others who have been caught out by this issue.