feat: add dependabot security backport labels#24484
Conversation
jdomeracki-coder
left a comment
There was a problem hiding this comment.
Code Review — PR #24484
🤖 Generated with Coder Agents
Summary
This PR adds automatic backport labeling for Dependabot security update PRs and customizes the Slack notification to call them out. The approach is straightforward and the step ordering is correct (label before approve/merge so the backport workflow triggers on close).
🟡 IMPORTANT — Prefer alert-lookup over body-text grep
The dependabot/fetch-metadata action (already used at the metadata step) natively supports security alert detection via its alert-lookup input. Enabling it:
- name: Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@ffa630c65fa7e0ecfa0625b5ceda64399aea1b36 # v3.0.0
with:
github-token: "${{ secrets.GITHUB_TOKEN }}"
alert-lookup: truegives you steps.metadata.outputs.alert-state (OPEN, FIXED, or DISMISSED) and steps.metadata.outputs.ghsa-id. Then the security check becomes:
if: steps.metadata.outputs.alert-state != ''This is more reliable than grepping the PR body for dependabot alert|security vulnerabilit(y|ies) because:
- Fragility — if Dependabot ever changes their PR body template wording, the regex breaks silently and security PRs stop getting backported with no alert.
- False negatives — a different phrasing or a non-English locale could bypass detection.
- False positives — a version-update PR whose changelog happens to mention "security vulnerability" would get incorrectly labeled.
The structured output from the action itself is the canonical signal.
🔵 NITPICK — Minor observations
-
Step output when skipped: When the
ifcondition skips the step (label already present),steps.security_backport.outputs.addedis empty. The|| 'false'fallback in the Slack step handles this correctly — looks good. -
Shell safety: Passing
github.event.pull_request.bodyvia thePR_BODYenv var (not inline) correctly avoids shell injection. Good pattern.
Verdict
The logic and integration with the existing backport workflow are sound. The main suggestion is to replace the body-text grep with alert-lookup: true on the existing fetch-metadata step for a more reliable detection mechanism.
matifali
left a comment
There was a problem hiding this comment.
This is a good enhancement but I wonder if there can be a case when an upgrade may not be a valid backport for an older release.
Also @f0ssel is there a process to inform the release manager when a new back port PR needs review or approval?
Good point - yes, I think that can happen. A dependency/security bump on main may still need adjustments on an older release branch, or may turn out not to be the right backport as-is. This change does not auto-merge anything into release branches though; it only makes sure eligible Dependabot security PRs get the existing backport label. The backport workflow still opens normal backport PRs for review, so we can adjust or close them if a straight backport is not valid. On the release-manager question: I did not add anything in this PR to explicitly notify the release manager when a generated backport PR is opened. This PR only covers labeling the original Dependabot security PR and improving that Slack notification. If we want release-manager notification/review routing for the backport PRs themselves, that seems like a good follow-up. |
If we have a slack notification that is enough. |
Dependabot security update PRs should be backported with the workflow added in #24025, but today they still rely on someone noticing and adding the backport label manually.
This updates the dependabot workflow to add the existing backport label automatically when a newly opened Dependabot PR looks like a security fix, and it adjusts the Slack notification text so those PRs are called out explicitly.