iTranslated by AI
GitHub Actions Workflow Not Triggering Despite Conditions Met by Another Workflow
Prerequisites
As part of the release automation, I had set up a workflow to "deploy to the production preview environment when a pull request to the main branch is created."
This automation is achieved with the following two workflows:
- Create a pull request from the
developbranch to themainbranch at 9:00 AM every fixed day of the week. - Deploy the source branch to the production preview environment when a pull request to the
mainbranch is opened.
What Happened
- Workflow 2 was no longer triggered after Workflow 1 ran.
- Workflow 2 starts if I manually create a pull request to the
mainbranch. - Even if I manually run Workflow 1, Workflow 2 does not start.
In short, I ended up in a state where:
Workflow 2 does not start when a pull request to the main branch is created from Actions.
The conditions were met, and it had been working until now, so why...!
I See!
Workflow 1 was creating pull requests using automatic token authentication with GITHUB_TOKEN.
- name: Create Pull Request to master
id: create-pull-request
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
PULL_REQUEST_URI=$(gh pr create --base master --title "$CURRENT_DATE Release" --body "")
echo "PULL_REQUEST_URI=$PULL_REQUEST_URI" >> $GITHUB_OUTPUT
You can obtain a token simply by writing secrets.GITHUB_TOKEN without needing to issue one explicitly.
I used it because it's simple and convenient, but I had fallen right into a trap regarding this token.
While it is clearly stated in the documentation, I never suspected the GITHUB_TOKEN specifications were the cause, so I couldn't find the answer at all.
When you use the repository's
GITHUB_TOKENto perform tasks, events triggered by theGITHUB_TOKEN(with some exceptions such asworkflow_dispatchandrepository_dispatch) will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs.
It seems this was a consideration to prevent events from being triggered unintentionally.
For example, if a workflow run pushes code using the repository's
GITHUB_TOKEN, a new workflow will not run even if the repository contains a workflow configured to run when push events occur.
on:
# Run on PR creation and manual execution
workflow_dispatch:
pull_request:
types: [opened, synchronize]
branches:
- main
I wanted a workflow with conditions like the above to be triggered, but since the pull request was created using the default GITHUB_TOKEN, the second workflow didn't fire.
By the way, the reason why this workflow suddenly stopped working is a mystery. It stopped around June 2023.
I hadn't touched the yml file, so I thought some specifications might have changed, but the most recent Change Log regarding GITHUB_TOKEN was from September 2022, stating that GITHUB_TOKEN could now be used with workflow_dispatch and repository_dispatch.
If anyone knows anything about this, I'd be overjoyed if you could leave a comment.
Solution
You can solve this by using either a personal access token or a GitHub App token instead of GITHUB_TOKEN.
With a personal access token, the workflow will fail when the token expires.
Since failures from this cause aren't frequent, developers who aren't familiar with Actions might end up wasting a lot of time when they encounter this error.
As stated in the documentation, a personal access token is like a password, so there is also a risk of leakage.
Therefore, I am solving this using a GitHub App.
Once set up, it can be reused across workflows in other repositories, and it only took about 1 to 2 hours to implement.
When I used a personal access token, I would waste about an hour whenever the token expired because I'd forget how to fix it, so I recommend solving it with a GitHub App.
I think this blog post will be very helpful for everything from creating a GitHub App to using it in a workflow!
Discussion