Some guidelines have now been added here:

https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#triggering-further-workflow-runs

Pull requests created by the action using the default GITHUB_TOKEN cannot trigger other workflows. If you have on: pull_request or on: push workflows acting as checks on pull requests, they will not run.

There are a number of workarounds with different pros and cons:

Use the default GITHUB_TOKEN and allow the action to create pull requests that have no checks enabled. Manually close pull requests and immediately reopen them. This will enable on: pull_request workflows to run and be added as checks. To prevent merging of pull requests without checks erroneously, use branch protection rules.

Use a repo scoped Personal Access Token (PAT) created on an account that has write access to the repository that pull requests are being created in. This is the standard workaround and recommended by GitHub. However, the PAT cannot be scoped to a specific repository so the token becomes a very sensitive secret. If this is a concern, the PAT can instead be created for a dedicated machine account that has collaborator access to the repository. Also note that because the account that owns the PAT will be the creator of pull requests, that user account will be unable to perform actions such as request changes or approve the pull request.

Use SSH (deploy keys) to push the pull request branch. This is arguably more secure than using a PAT because deploy keys can be set per repository. However, this method will only trigger on: push workflows.

Use a machine account that creates pull requests from its own fork. This is the most secure because the PAT created only grants access to the machine account's fork, not the main repository. This method will trigger on: pull_request workflows to run. Workflows triggered on: push will not run because the push event is in the fork.

Use a GitHub App to generate a token that can be used with this action. GitHub App generated tokens are more secure than using a PAT because GitHub App access permissions can be set with finer granularity and are scoped to only repositories where the App is installed. This method will trigger both on: push and on: pull_request workflows.

In case someone at GitHub reads this, I think it would be great if the story for this was simplified! Let me tell a story.

I had been procrastinating on automating creating pull requests in a repo based on certain events, because I thought it would be complicated. I finally got around to doing it, and boy was I amazed at how smooth it was! That the gh CLI tool is just available out of the box in GitHub Actions is incredibly useful.

This is my workflow in essence:

on:
  whatever:
jobs:
  my-cool-job:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          # do stuff, including git commit
          # then, create the PR:
          gh pr create --fill
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

I didn’t even need to fiddle with creating tokens or anything – the above Just Works out of the box!

There’s just one little detail. Nothing much. Not a show stopper. Just that you can’t merge the automatically created pull request. 🙃 But who needs merging, right? 😉

The reason they can’t be merged is because of status checks not firing. Status checks set as Required in branch protection rules. Which are great, and GitHub is promoting them with this banner at the top of your repos without a branch protection rule:

Now, I get why workflows using GITHUB_TOKEN don’t trigger other workflows. Protecting against accidental workflow loops is an awesome feature.

But have a look at this issue for a very popular action for creating pull requests: peter-evans/create-pull-request#48. At the time of writing, it has 246 issues or pull requests linking to it, from various open source projects documenting why they had trouble with workflows not running for pull requests created from GitHub Actions. And that’s not counting all private projects.

I think this shows that there’s demand for a way to automate pull request creation without jumping through hoops. I mean, we’re so close already! Falling on the finishing line always hurts the most.

Looking back at my short and sweet workflow, reading the recommendations on how to work around the problem didn’t feel super nice. It was exactly the things I dreaded when procrastinating on my automation. Making a PAT seems the simplest, but they expire every year, and I’d have to remember to update it. Making a GitHub App felt pretty complicated. You know what? I’m gonna go with the stupid workaround of manually closing and re-opening the pull request to trigger the checks. It means I have to wait for the checks to finish (instead of them being done once I see the PR), but it is what it is.

I have one solution idea. The goal with the current limitations is to prevent recursion loops. Instead of disallowing workflows using GITHUB_TOKEN from triggering other workflows altogether, what if we only disallowed recursion? Keep a list of workflows that have run as state, and if we’re about to run a workflow that’s already in the list, don’t run it again. We could even have a hard limit of like 10 or 100 on that list to prevent run-away triggers if wanted.

My branch protection rules usually have just one single workflow as a required status check. If at least that worked, that would be a huge improvement. Thanks for reading! 💙

I am using Fine-grained PAT and it still does not work.