I originally tested the workflow on an edk2 fork. Due to a lack of readily available extra GitHub accounts, the pull requests for testing originated from the fork to the fork. The pull_request trigger type originally chosen will not support the ability to write to the PR from a public fork which is the case in edk2.
This change simply moves the trigger to pull_request_target. The rest of this message contains verbose details related to that and some tweaks to use that trigger type. This also has the advantage that the workflow will run for all contributors, even first-time contributors (regardless of GitHub repo settings), since the workflow runs in the context of the master (base) branch which is trusted, so it is a better approach anyway.
This was verified on a PR from a public fork with the default GitHub token.
Because pull_request_target runs the pull request in the context of the base branch (not the PR branch) some logic needs slightly modified. The main change is that the GitHub context will no longer give the PR branch HEAD as the PR commit SHA (i.e. github.event.pull_request.head.sha). The SHA will be the base branch (master) SHA as that is what is checked out for the workflow run. So, the actual PR SHA is now fetched separately.
[ ] Breaking change?
[ ] Impacts security?
[ ] Includes tests?
How This Was Tested
Verified on a pull request coming from a public fork
Description
I originally tested the workflow on an edk2 fork. Due to a lack of readily available extra GitHub accounts, the pull requests for testing originated from the fork to the fork. The
pull_requesttrigger type originally chosen will not support the ability to write to the PR from a public fork which is the case in edk2.This change simply moves the trigger to
pull_request_target. The rest of this message contains verbose details related to that and some tweaks to use that trigger type. This also has the advantage that the workflow will run for all contributors, even first-time contributors (regardless of GitHub repo settings), since the workflow runs in the context of themaster(base) branch which is trusted, so it is a better approach anyway.This was verified on a PR from a public fork with the default GitHub token.
Because
pull_request_targetruns the pull request in the context of the base branch (not the PR branch) some logic needs slightly modified. The main change is that the GitHub context will no longer give the PR branch HEAD as the PR commit SHA (i.e.github.event.pull_request.head.sha). The SHA will be the base branch (master) SHA as that is what is checked out for the workflow run. So, the actual PR SHA is now fetched separately.How This Was Tested
Integration Instructions