ci: automatically publish suppressions after merged PRs#8527
Open
chadlwilson wants to merge 4 commits into
Open
ci: automatically publish suppressions after merged PRs#8527chadlwilson wants to merge 4 commits into
chadlwilson wants to merge 4 commits into
Conversation
…nt type Signed-off-by: Chad Wilson <29788154+chadlwilson@users.noreply.github.com>
…eratedSuppressions branch Signed-off-by: Chad Wilson <29788154+chadlwilson@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates GitHub Actions workflows to run in the safer pull_request_target context with clearer warning comments, and gates publishing suppressions to merged PRs.
Changes:
- Switch
publish-suppressionsto trigger onpull_request_target(closed) for a specific branch/path and only proceed when the PR is merged. - Add
pull_request_targetsafety warning comments to workflows.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| .github/workflows/publish-suppressions.yml | Adds pull_request_target trigger + merge gate for suppression publishing, plus safety notes. |
| .github/workflows/lint-pr.yml | Adds pull_request_target safety notes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description of Change
Alternate implementation of #8516 which triggers off merged pull requests targetting the branch.
As noted in #8516 (comment) the
on.branchor normalon.pull_requesttriggers won't work, as they operate in the context of the relevant branch; however https://github.com/dependency-check/DependencyCheck/tree/generatedSuppressions is a bare tree/orphaned branch which does not contain the workflow definitions - so there is nothing to trigger. You can simulate a similar warning if you try and use workflow dispatch off this branch, which it wont let you:The alternative is to use the (somewhat risky)
pull_request_targetevent; which operates in the context of thedefaultbranch's workflow (main), in the PR target repository. This means it always uses the workflow definition offmain, which in our case is what we want - albeit with some downsides.This event type is pretty notorious recently for repos getting script-injected and tokens stolen due to "untrusted PR code" being used when misconfigured; so we have to be careful here, similar to the "Lint PR" workflow too. To mitigate all this, this only runs on post-review PR merges (which unfortunately GHA does not have a dedicated event for), and only those targeting the
generatedSuppressionsbranch (and filepathsto be extra paranoid).IMO risk should be OK given it always checks out code from hard-coded
generatedSuppressionsbranch, and does not inject/interpolate any variables from the PR context. We probably need some GHA workflow static analysis tooling though, to prevent regression.Testing off my fork: https://github.com/chadlwilson/DependencyCheck/actions/workflows/publish-suppressions.yml
Related issues
Have test cases been added to cover the new functionality?
N/A