What's going on?
The changesets PR contains commits through the changeset/action that seems to not trigger other GitHub Actions workflows.
Why is this happening?
-
GitHub Actions doesn’t trigger itself.
The changeset/action by default acts on behalf of the github-actions user:
According to the GitHub Actions "Triggering a workflow" docs:
When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur. For more information, see Use GITHUB_TOKEN for authentication in workflows.
The proposed solution is:
If you do want to trigger a workflow from within a workflow run, you can use a GitHub App installation access token or a personal access token instead of GITHUB_TOKEN to trigger events that require a token.
-
Act as as different user.
Even in case the changeset/action gets an access token of another user as parameter, the action still acts on behalf of github-actions[bot].
- uses: changesets/action@v1
with:
...
+ env:
+ GITHUB_TOKEN: ${{ secrets.DEVOPS_SERVICEUSER_PAT }}
According to the Changesets Release Action docs, the is another parameter commitMode:
commitMode - Specifies the commit mode. Use git-cli to push changes using the Git CLI, or github-api to push changes via the GitHub API. When using github-api, all commits and tags are GPG-signed and attributed to the user or app who owns the GITHUB_TOKEN. Default to git-cli.
- uses: changesets/action@v1
with:
...
+ commitMode: github-api
env:
GITHUB_TOKEN: ${{ secrets.DEVOPS_SERVICEUSER_PAT }}
-
GitHub API only supports non-executable files and directories.
With commitMode: github-api, with our repo we hit another error: Error: Unexpected executable file at helm/.gitignore, GitHub API only supports non-executable files and directories. You may need to add this file to .gitignore
To remove the executable flag (that's checked into the git index), we have to add a step to the workflow that executes the following command:
git ls-files | while read -r file; do [ -x "$file" ] && chmod -x "$file" || true; done
+- name: GitHub API only supports non-executable files and directories
+ run: git ls-files | while read -r file; do [ -x "$file" ] && chmod -x "$file" || true; done
- uses: changesets/action@v1
with:
...
commitMode: github-api
env:
GITHUB_TOKEN: ${{ secrets.DEVOPS_SERVICEUSER_PAT }}
Once that’s done, the changeset/action runs as the service user properly, and the workflows triggered by on.push start working.

What's going on?
The changesets PR contains commits through the changeset/action that seems to not trigger other GitHub Actions workflows.
Why is this happening?
GitHub Actions doesn’t trigger itself.
The
changeset/actionby default acts on behalf of the github-actions user:According to the GitHub Actions "Triggering a workflow" docs:
The proposed solution is:
Act as as different user.
Even in case the
changeset/actiongets an access token of another user as parameter, the action still acts on behalf of github-actions[bot].- uses: changesets/action@v1 with: ... + env: + GITHUB_TOKEN: ${{ secrets.DEVOPS_SERVICEUSER_PAT }}According to the Changesets Release Action docs, the is another parameter
commitMode:- uses: changesets/action@v1 with: ... + commitMode: github-api env: GITHUB_TOKEN: ${{ secrets.DEVOPS_SERVICEUSER_PAT }}GitHub API only supports non-executable files and directories.
With
commitMode: github-api, with our repo we hit another error: Error: Unexpected executable file at helm/.gitignore, GitHub API only supports non-executable files and directories. You may need to add this file to .gitignoreTo remove the executable flag (that's checked into the git index), we have to add a step to the workflow that executes the following command:
Once that’s done, the
changeset/actionruns as the service user properly, and the workflows triggered byon.pushstart working.