Safely run reviewdog on pull_request_target events

[jcapriot]

Summary

Updates permissions for reviewdog actions.

Looks like it explicitly needs to be given read permissions for the contents, and write permissions for the pull-requests to modify PR's from public forks.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.54%. Comparing base (999d18c) to head (d6c911d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1427   +/-   ##
=======================================
  Coverage   82.54%   82.54%           
=======================================
  Files         167      167           
  Lines       25700    25700           
=======================================
  Hits        21214    21214           
  Misses       4486     4486           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[santisoler]

I'm not sure I understood why it needs writing permissions. Does it push changes running black on the PRs? Or it just comments suggestions on the PRs?

[jcapriot]

It needs write access to comment on the PR's, but apparently it doesn't get that permission from PR's opened from forked repositories... Whereas the first PR I made had to come from this repo itself in order to run the first action, it went unnoticed. I'm still looking at options to set though.

[jcapriot]

Ok, just figured this out in what is probably the safest way to do this. First though the issue:

For workflows triggered from pull requests from forks of public repositories, secrets.GITHUB_TOKEN only has read permissions, and this cannot be changed by anyone.

• This is a good thing: you don't want to open up the repository to arbitrary code execution that could modify the repository from outside actors (even if we still have to approve workflows to run from first-time contributors).

The solution:
For every pull request, two GitHub events are triggered, pull_request and pull_request_target. The pull_request_target event runs are in the context of the target of a pull request, therefore it runs with all of the permissions associated with a branch on this repository, meaning secret.GITHUB_TOKEN gets read and write access. Note:

• You still don't want to execute anything that depends on items from the pull_request's source. (i.e. don't run pip install -r requirements.txt when requirements.txt would be from the pr source.) That would defeat the purpose of holding write permissions from the public PRs.

So what this modification here does for a pull request is:
For each pull request:

• Trigger the pr target's workflow (not the pr source's workflow).
  • Download's the target branch source code
  • Install's style requirements defined in the target's source code
  • Download's the pull request source into another working directory
  • runs reviewdog in the pull request's working directory (This step only analyzes the code, it will never execute anything in that source.) The only thing it will look at that effects the execution of the style checkers are black and flake8 configurations (which again just parse those as text files).

[jcapriot]

Note that when we update the flake8 or black versions in the requirements file, this will not alter the annotation workflow until it is merged into the target, so there might be an issue causing out-of-sync comments, but it would only effect that specific PR, and be resolved once it's merged.