Pull request created in a GitHub action does not trigger workflows with pull_request trigger

[mlegner]

Select Topic Area

Bug

Body

I have a (manual) workflow that automatically creates a pull request through the GitHub API (a variant of https://github.com/hrvey/combine-prs-workflow).

Unfortunately, my other workflows with an on: pull_request trigger don't run for this PR (even though they work perfectly fine on other PRs). When I then do a force push on the created branch, the workflows are triggered as expected.

Any idea what the problem could be?

[d-suter]

Hi Markus,

It seems like the GitHub Actions is not being triggered because the pull request is created via the GitHub API. When a pull request is created this way, the pull_request event is not triggered, and therefore, the workflows that rely on this event do not run.

However, when you do a force push on the created branch, it triggers the pull_request event, which is why the workflows are then triggered as expected.

As a workaround, you might consider using a different event to trigger your workflow. For example, you can use the repository_dispatch event to trigger a workflow run. This event allows you to trigger a workflow from an external source, like the GitHub API.

Here is an example of how you could set up your workflow file to be triggered by a repository_dispatch event:

name: My Workflow
on:
  repository_dispatch:
    types: [create-pull-request]
jobs:
  myJob:
    runs-on: ubuntu-latest
    steps:
      ...

And then, you can create a repository dispatch event via the GitHub API like this:

curl -X POST \
  -H "Authorization: token YOUR_GITHUB_TOKEN" \
  -H "Accept: application/vnd.github.everest-preview+json" \
  https://api.github.com/repos/OWNER/REPO/dispatches \
  -d '{"event_type": "create-pull-request"}'

I hope this helps!

[mlegner]

Thanks for the insights and pointers, @ceodavee!

It doesn't really make sense to me that creating a PR through the API wouldn't trigger PR workflows, but I guess I have to work around that...

I'm not sure that your suggestion with repository_dispatch works for my purpose, however: As far as I understand, this triggers the workflow on the last commit of the default branch, while I want the workflow to run for the head branch of the PR / the PR merge branch.

[d-suter]

Hi @mlegner ,

I share your confusion about the GitHub Actions triggers' behavior. It indeed seems counterintuitive that creating a PR via the API doesn't trigger the pull_request event.

You are correct about the repository_dispatch event; it triggers the workflow on the default branch, not the PR branch, so it may not be suitable for your use case.

An alternative could be using the check_run or check_suite event as a trigger. These events are triggered when a check run or check suite is created, completed, or has a status update. Here's how you could adjust your workflow file to be triggered by a check_run event:

name: My Workflow
on:
  check_run:
    types: [completed]
jobs:
  myJob:
    runs-on: ubuntu-latest
    steps:
      ...

This way, your workflow would be triggered when the check run is completed on the PR branch.

It might also be worth raising this as a bug directly with GitHub, as it seems like an inconsistency in the behavior of the GitHub Actions triggers.

Hope this helps! Please let me know if there are any other questions or if there's anything else I can assist with.

Best regards

[mlegner]

Thanks a lot for your help, @ceodavee!

Coincidentally, I just realized that I can completely circumvent my problem with the new grouping feature of Dependabot, which makes the API-based PR creation I used unnecessary.

It might also be worth raising this as a bug directly with GitHub, as it seems like an inconsistency in the behavior of the GitHub Actions triggers.

I will do that. 👍

[mlegner]

Actually, I just found another discussion on this topic, which answers why no workflow is triggered: https://github.com/orgs/community/discussions/57484

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.

The issue wasn't that I used the API but that I used it from a GitHub workflow and authenticated with the GITHUB_TOKEN.

[d-suter]

Great to hear that you found a solution with the new Dependabot grouping feature!

Also, thanks for sharing the link to the other discussion. It's always helpful to understand the root cause of the issue, and it seems like a problem others have encountered as well.

[dominicfraser]

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.

[lydell]

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! 💙