auto-approve-action: GITHUB_TOKEN read-only breaks github action

Sorry for taking a while to get to this!

I think switching from pull_request to pull_request_target should work. I’m pretty sure that the read-only tokens introduced last month should only apply to Dependabot pull requests triggered by pull_request events. Switching to pull_request_target will run the workflow in the target branch (e.g. main rather than the PR’s branch), but that’s not a problem for this action as it just leaves a review and doesn’t look at the code in the pull request.

I tried both, and confirmed that pull_request_target does work as expected:

pull_request

This actions run was triggered using the pull_request event, and it failed because the token only had read access to pull requests.

pull_request_target

This action was triggered using pull_request_target event. It worked as expected.

I’m adding some more useful error messages, which should help folks catch this in the future.

If you’re seeing “Resource not accessible by integration” with a workflow file (in a public repo) that already has been switched over to pull_request_target, can you point me to the actions run? I don’t think that should be happening, so if it is I’d like to investigate.

Aside: I don’t think the linked Security Lab blog post is relevant. It raises a security issue associated with checking out potentially vulnerable code in the course of an Actions workflow, which this action doesn’t do.

Glad to hear it’s working!

I just published v2.1.0 which includes better error handling. If you want to track v2 rather than pinning to a specific patch release you can also use hmarr/auto-approve-action@v2 now.

Thank you for helping with this ticket @hmarr . I believe you are correct that switching to pull_request_target fixes it. I’m going to close this and hopefully other folks will be able to use it for updating their own code.

But for me, even with pull_request_target, it doesn’t work, I have a action triggered outside of a pull_request error 🤔

@skjnldsv I saw this on the auto-merge-action, as it supports the pull_request_target only since a few days. If we bump ahmadnassri/action-dependabot-auto-merge to @v2 it works. (or specific commit, as alex mentioned).

@skjnldsv I tried to answer this above - you are fine with an open contributing policy - the primary restriction is you should probably be using pull_request_target for any workflows that need to write back to your repo because pull-request-target operates in the base branch (i.e. 3rd party code cannot accidentally run!).

If you need to also do something with the code itself (i.e. run tests) - pull_request actions run without any secrets in the branch being PR’d and you can run these in parallel. For more complicated edge-cases (i.e. you want to provide a BrowserStack token to do some E2E testing) GitHub’s recommendation is you invoke these workflows manually after auditing the code.

In the context of my action & this one - I don’t think that enabling either of these for 3rd parties is wise - you probably shouldn’t be approving unaudited code - BUT if you would like to, pull_request_target triggered by humans will work.

@jotoeri The docs are awfully confusing - this is intel pieced together from a Github Support thread, many pages of docs, and the two blog posts GitHub have on this. I’m feeding back in the support thread, so hopefully this will be clarified.

The intent is as you summarised however - so if you bear that in mind you should be okay!

The key thing to consider is: A lot of this depends on the actor firing the event.

If it’s a bot dependabot - both pull_request and the new pull_request_target with the default created & edited events will not allow read-access to secrets.

The labeled event for pull_request_target, however, does allow this as it is restricted to those with label access - and only special cases (i.e. dependabot or other explicitly installed apps) are still able to label PRs despite not having full access to the repository. So it is “safer”.

And it triggers a workflow, with read-access to secrets, and in read/write scope (e.g. the GITHUB_TOKEN allows one to issue an automatic approval - you can see an example of this here).

Another change I made here - is checking for the creator of the pull-request, not the actor associated with an event, so that the action can be re-triggered & debugged manually. If / when this action fails again, I’ll be able to re-trigger the workflow and since the original creator was dependabot - it works as normal.

    if: github.event.pull_request.user.login == 'dependabot[bot]'