Reputation: 23280
I'm currently testing GitHub Actions workflows on this repository. I'm trying to use this workflow:
on:
workflow_dispatch:
jobs:
job:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: |
date > report.txt
git config user.name github-actions
git config user.email [email protected]
git add .
git commit -m "generate or update report.txt file"
git push
to trigger this workflow:
on:
push:
paths:
- '**/report.txt'
pull_request:
paths:
- '**/report.txt'
jobs:
job:
runs-on: ubuntu-latest
steps:
- run: echo "Report .txt file has been updated"
I followed the GitHub Actions documentation to implement the second workflow with a filter pattern.
When I update the report.txt
file locally, then commit and push the code to the repository, the second workflow triggers.
However, I don't understand why the second workflow doesn't trigger when the first workflow is completed, even with the report.txt
file being updated on the default branch. Did I miss something on the first workflow to make it trigger the second, or should I add something on the second workflow to make it being triggered by the first one?
I know I could trigger the second workflow using other trigger event types (examples: repository_dispatch
or workflow_run
), but I'm trying to do it from a git push
command on another workflow.
Upvotes: 12
Views: 4827
Reputation: 4093
There are three ways of authentication within a GitHub action.
The GITHUB_TOKEN
is always available and implicitly defined by GitHub.
- uses: actions/checkout@v4
with:
token: ${{ secrets.GITHUB_TOKEN }}
It has limited permissions, though, as it cannot trigger new workflow runs. This is why your second workflow does not start.
A personal access token can be generated in your developer settings. You can then add it as an encryped secret, e.g. PAT_TOKEN
to the GitHub project and use it instead of the GITHUB_TOKEN
:
- uses: actions/checkout@v4
with:
token: ${{ secrets.PAT_TOKEN }}
Subsequent push actions in the same workflow will then trigger any configured GitHub workflow as if they were pushed manually.
Be aware that the personal access token has access to all of your repositories and hence can be a potential security risk.
You can generate a dedicated SSH keypair and add it to the repository as a Deploy Key. This is an alternative to the token-based authentication and has the same effect as the personal access token, but it only provides access to a single repository. It is done as follows:
Generate an SSH keypair:
ssh-keygen -N "" -f deploy_key -C "github-actions"
Add the private key (generated file deploy_key
) as an encryped secret, e.g. COMMIT_KEY
to the GitHub project.
Add the public key (generated file deploy_key.pub
) as a deploy key with write access to the GitHub project. Tick the Allow write access
checkbox.
When checking out the source code in your workflow, add the SSH key:
- uses: actions/checkout@v4
with:
ssh-key: "${{secrets.COMMIT_KEY}}"
Upvotes: 4
Reputation: 3561
No, you didn't miss anything in your workflows.
You just need a different token.
When you use actions/checkout, it uses the GITHUB_TOKEN
for authentication, and according to the documentation it doesn't trigger a new workflow run:
When you use the repository's GITHUB_TOKEN to perform tasks on behalf of the GitHub Actions app, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs.
To make it work, you need to generate a PAT (Personal Access Token), store it in your repository secrets, and use it in your checkout step:
- uses: actions/checkout@v4
with:
token: ${{ secrets.YOUR_PAT_TOKEN }}
Upvotes: 17