A Personal Access Token is not actually required. A GITHUB_TOKEN will work about enable-pull-request-automerge HOT 4 CLOSED

Hi @grintor

Thank you for sharing this workflow. I'm aware of pull_request_target being a workaround for needing a PAT, but was a bit hesitant to suggest this because it can be misused and potentially dangerous. However, it does look like you have made it safe with the USER_ALLOWLIST. I still would recommend people use a PAT, but I'm sure some users would prefer this solution.

When I have some time I'll test this out and likely add it to the readme. For now I'll leave this issue open for people to find. Thanks!

from enable-pull-request-automerge.

Thanks @peter-evans,

I did fine one caveat in doing it this way though. Since "events triggered by the GITHUB_TOKEN will not create a new workflow run", you cannot have any workflows that are triggered by the merge event created by this workflow.

So for example, if you have some CD workflow meant to deploy the main branch upon a new merge, that workflow will not be triggered when using a GITHUB_TOKEN here. That may or may not affect a given repository, but it's good to be aware of for when it does. I was scratching my head for quite a while trying to figure out why another workflow wasn't running on my main branch merges.

from enable-pull-request-automerge.

Ah yes, that is quite a big downside. I expect most use cases will have a workflow that runs on push to the main branch.

from enable-pull-request-automerge.

I had time to test auto-merging dependabot PRs. I've added an example in the readme.

https://github.com/peter-evans/enable-pull-request-automerge#dependabot-example

The conclusion is the same, you can use GITHUB_TOKEN but the merge won't trigger further workflow runs. Use a PAT if that is necessary.

from enable-pull-request-automerge.