Build mmaps for comparison on PR branch. #949
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The GitHub Action which generates the mmap comparison link for pull requests currently applies the YAML patches from the PR branch using the SVDs and tooling from the master branch in order to avoid running the untrusted tooling code from the PR branch in a context where it has access to secrets. For more context see #919.
This replaces that workflow with a pair that implement the pattern described in GitHub's blog post on how to combine an untrusted build with privileged actions.
Unfortunately (as is typical of CI changes) I haven't been able to test the new workflows as that would require setting up a bunch of temporary repositories.
Since this switches from the
pull_request_target
event topull_request
, workflows may no longer run automatically for PRs submitted by first-time contributors. You should check the setting for when to run workflows for PRs from forks.The switch to the
pull_request
event also means that the job to generate the mmaps will run on a commit generated by GitHub that merges the PR head branch into master, and that it won't run at all if there are merge conflicts. I think that's probably a good thing, but if you want, I think I can change it to run on the PR head commit.I would also recommend changing the default
GITHUB_TOKEN
permissions to "Restricted". That will ensure that Actions jobs don't have write access to anything unless they request it specifically with thepermissons
setting in their YAML file. I've looked over the other workflows and I think all of the ones that need extra permissions already request them.