PRs created don't trigger other actions

[abatilo]

It seems that any PRs that get created by this action will not trigger any actions waiting on a pull request event, which means that you can have any required status checks.

Any ideas for how to get around this?

[peter-evans]

This is a deliberate limitation imposed by GitHub Actions that an action cannot trigger other workflows. From the documentation:

An action in a workflow run can't trigger a new workflow run. For example, if an action 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.

https://help.github.com/en/articles/events-that-trigger-workflows#example-using-more-than-one-event

I'm not sure if there are any work arounds. I guess you would need another event to trigger the additional workflow.

[peter-evans]

I've found a work around. It looks like GitHub are determining that API calls are coming from actions by checking the authentication token. If you use a repo scoped token instead of the default GITHUB_TOKEN then the on: pull_request workflow will run checks against the created pull request.

Create a repo scoped token at https://github.com/settings/tokens and then add it as a secret to the repository your workflow runs in. It will be under https://github.com/[username]/[repo]/settings/secrets

Use that secret in your workflow and assign it to the environment variable GITHUB_TOKEN.

    - name: Create Pull Request
      uses: peter-evans/create-pull-request@v1.3.1
      env:
        GITHUB_TOKEN: ${{ secrets.REPO_SCOPED_TOKEN }}

There is a downside to this method. The PR is no longer created by the github-actions bot user and instead appears to be created by the user associated with the token.

[peter-evans]

I contacted GitHub about this issue and their response confirms that using a personal token as I outlined above is the correct approach.

From GitHub Support:

This is a deliberate decision by the Actions team in order to prevent accidental "infinite loop" situations, and as an anti-abuse measure.
You will be able to work around this using a Personal Access Token in place of the provided token. As this needs to be explicitly provided it will remove any potential for possible abuse, so we recommend using this method when needing to create a pull request.

[Mike-E-angelo]

Ah what a pain. Resorting to a token that applies to every repository of the user without being able to scope specifically to the desired repository is quite the security concern.

(My complaints are to GitHub, not this repo BUT SOMEONE MUST HEAR ME AS I SHOUT POWERLESS INTO THE VOID!! 😅)

[Mike-E-angelo]

Hey all, check it out... another possible workaround is to use an on.schedule.cron trigger as discussed here:

pascalgn/automerge-action#37 (comment)

Here's my (sample/testing 😁) configuration:

https://github.com/ExtendedXmlSerializer/NextRelease/blob/959614d9e72c08f80d7e71a0e52265a42ed91c75/.github/workflows/automerge.yml#L25-L30

Not as elegant as a direct trigger, but certainly better than having to resort to a Personal Access Token.

Thought I'd share. 👍

[dogmatic69]

There is a massive drawback to using this token, if a repository owner uses a personal token they will not be able to request changes nor approve a PR. This is due to the fact that the PR will be created by the owner.

[peter-evans]

Thanks to @proudust for bringing it to my attention, an alternative to using a PAT is SSH Deploy keys that can be set per repository. See the documentation here for how to use Deploy keys with create-pull-request action. Note that this method will only trigger push workflows, not pull_request, so checks must be in an on: push workflow.

[peter-evans]

Using deploy keys is now even easier because actions/checkout now supports checkout with SSH keys. See the updated documentation here.

[brockfanning]

Sorry if this has been explained - do I understand correctly that if the repository needs to have workflows triggered on pull_request and has a branch rule requiring that status checks pass, a PAT is the only option? Otherwise, the generated PR will be stuck in "Waiting for status to be reported" and won't be able to be merged?

[peter-evans]

@brockfanning There are actually a number of different workarounds now with various pros and cons. I've summarised them and updated the documentation here.

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

[swinton]

Resorting to a token that applies to every repository of the user without being able to scope specifically to the desired repository is quite the security concern

Another approach is to create a GitHub App, install that app on your repo, and then generate a token using that App / installation, e.g. using tibdex/github-app-token.

There's an example of this here. In this example, a workflow in one repo is setting up branch protections in a separate repo, using Terraform (because the default GitHub token is scoped only to the repo where the running workflow lives) but you could also use this same approach to open a PR. This PR would then trigger other workflows in the repo.