Add configurable classification labels to dependency review workflow#624
Add configurable classification labels to dependency review workflow#624
Conversation
…workflow Co-authored-by: fr4nc1sc0-r4m0n <215478872+fr4nc1sc0-r4m0n@users.noreply.github.com>
oblt-aw/ai/merge-ready as allowed label in dependency review workflow
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughReplaces a hard-coded two-label labeling flow in the dependency-review workflow with a configurable comma-separated input named Possibly related PRs
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
| - The updated dependency is used only in workflows triggered by push-to-main, release, schedule, or workflow_dispatch (cannot be validated in PR context) | ||
|
|
||
| Only apply `needs-human-review` and `higher-risk` labels. | ||
| - **`oblt-aw/ai/merge-ready`**: Apply when: |
There was a problem hiding this comment.
oblt-aw/ai/merge-ready is defined as "safe to merge without human review," but the workflow only adds labels and never removes existing ones. On reruns, a PR can retain a prior needs-human-review/higher-risk label and also receive oblt-aw/ai/merge-ready, which creates contradictory automation signals.
Please make oblt-aw/ai/merge-ready explicitly mutually exclusive (e.g., only apply it when neither risk label is present, or remove stale risk labels before adding it).
|
@copilot we want the workflow to stay generic so we'll want to take a workflow input or allowed labels and then we'll want to apply them or not similar to our pr labeler, we'll also need to add the relevant instructions to the prompt |
…of hardcoding label Co-authored-by: strawgate <6384545+strawgate@users.noreply.github.com>
Done in commit a9edd8a. Instead of hardcoding |
oblt-aw/ai/merge-ready as allowed label in dependency review workflow|
@copilot "add-labels We don't know that we can apply those other two labels. Perhaps we need to change this into an allowed list of labels like pr labeler and have the label plus its description written to disk maybe and then read by the agent? And then if the caller wants to provide additional instructions they can |
…ve all hardcoded labels Co-authored-by: strawgate <6384545+strawgate@users.noreply.github.com>
Done in commit b921b78. Replaced |
|
@copilot what do we call it in the pr labeler? I'm wondering if we just call the input line "allowed-labels" or just "labels" classification labels seems weird |
The |
|
@copilot fix dirty lock files |
Co-authored-by: strawgate <6384545+strawgate@users.noreply.github.com>
| .map((s) => s.trim()) | ||
| .filter(Boolean) | ||
| ); | ||
| if (allowed.size === 0) { |
There was a problem hiding this comment.
The empty-allowlist path currently fails open: when classification-labels is unset, this step returns early and leaves any add_labels operation untouched, while the safe-outputs config no longer enforces an allowed list. In that state, a model output containing arbitrary existing repo labels can still be applied, which conflicts with the stated contract (If empty, no labels are applied).
Please fail closed when allowed.size === 0 (e.g., strip all add_labels entries before processing) or reintroduce an allowlist constraint derived from classification-labels in the handler config.
|
@copilot please address PR feedback |
Co-authored-by: strawgate <6384545+strawgate@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/gh-aw-dependency-review.md:
- Line 84: Step fixes inconsistent version pin for the GitHub Action: change the
usage of actions/github-script@v7 to actions/github-script@v8 to match other
steps; locate the line using "uses: actions/github-script@v7" and update the tag
to "@v8" so all github-script invocations are consistent across the workflow.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e46b7524-4351-4ef8-9340-f6e9e212580f
📒 Files selected for processing (3)
.github/workflows/gh-aw-dependency-review.lock.yml.github/workflows/gh-aw-dependency-review.md.github/workflows/trigger-dependency-review.yml
✅ Files skipped from review due to trivial changes (1)
- .github/workflows/trigger-dependency-review.yml
| - "higher-risk" | ||
| steps: | ||
| - name: Pre-sanitize labels from input allowlist | ||
| uses: actions/github-script@v7 |
There was a problem hiding this comment.
Version inconsistency: @v7 vs @v8 used elsewhere.
This step pins to github-script@v7 while all other github-script usages in the workflow compile to v8. Consider updating to @v8 for consistency.
Suggested fix
- uses: actions/github-script@v7
+ uses: actions/github-script@v8📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: actions/github-script@v7 | |
| uses: actions/github-script@v8 |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/gh-aw-dependency-review.md at line 84, Step fixes
inconsistent version pin for the GitHub Action: change the usage of
actions/github-script@v7 to actions/github-script@v8 to match other steps;
locate the line using "uses: actions/github-script@v7" and update the tag to
"@v8" so all github-script invocations are consistent across the workflow.
Summary
This PR makes dependency-review labeling configurable instead of hardcoded.
What changed
classification-labelsinput to the dependency review reusable workflow.add_labelsoperations to only labels fromclassification-labels.classification-labelsdynamically, and to skip labeling when the input is empty.classification-labelsand define label semantics viaadditional-instructions.classification-labels(alladd_labelsops are removed when no labels are configured).Impact
needs-human-review,higher-risk,merge-ready).The body of this PR is automatically managed by the Trigger Update PR Body workflow.