fix: ensure labels exist before creating regression issues#1763
Conversation
The `needs-investigation` label doesn't exist in this repo, causing the GitHub API to return 422 when the performance monitor tries to create regression issues. Add a step to ensure both labels exist before issue creation, and add error handling around the issue creation step itself. Fixes #1759 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✅ Coverage Check PassedOverall Coverage
📁 Per-file Coverage Changes (1 files)
Coverage comparison generated by |
There was a problem hiding this comment.
Pull request overview
Updates the performance monitoring workflow to prevent regression issue creation from failing when required GitHub labels are missing, addressing issue #1759.
Changes:
- Adds a pre-step that ensures
needs-investigationandperformancelabels exist (creating them when absent) before attempting issue creation. - Wraps regression issue creation in
try/catchand surfaces failures viacore.setFailed()with a logged success URL on creation.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/performance-monitor.yml |
Ensures required labels exist to avoid GitHub API 422s and improves failure reporting for regression issue creation. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 1/1 changed files
- Comments generated: 0
Smoke Test Results
Overall: PASS
|
Smoke Test Results
Overall: PASS PR: fix: ensure labels exist before creating regression issues — @Mossaka
|
|
Smoke test results:
|
Smoke Test: GitHub Actions Services Connectivity ✅
All service connectivity checks passed.
|
Mossaka
left a comment
Mossaka
left a comment
There was a problem hiding this comment.
Security Review — PR #1763
Scope
Reviewed the diff adding an "Ensure labels exist" step and error handling to the performance-monitor.yml workflow.
[Info] Workflow Permissions — Correctly Scoped
The workflow declares top-level permissions:
permissions:
contents: read
issues: writeissues: write is the minimum required for both issues.createLabel and issues.create. No other write permissions are granted. This follows the principle of least privilege. No concerns here.
[Info] Token Scope — Appropriate
The GITHUB_TOKEN used by actions/github-script@v7 is the default workflow token, automatically scoped to the repository. It cannot access other repositories or elevated organization permissions. Combined with the explicit permissions block above, the token's effective scope is minimal. No concerns.
[Info] Label Injection — Not a Risk
The label names are hardcoded string literals ('needs-investigation', 'performance'). They are not derived from any external input such as PR titles, commit messages, branch names, or benchmark output. An attacker cannot influence what labels are created or applied. No concerns.
[Info] GitHub API Usage — Safe
The actions/github-script@v7 steps use only context.repo.owner and context.repo.repo, which are repository-scoped values controlled by GitHub, not user-supplied strings. The issue title uses new Date().toISOString() (deterministic, no injection vector). The issue body reads from benchmark-results.json which is generated by the workflow's own benchmark script from git rev-parse HEAD and internal metrics — not from attacker-controlled input. There is no template literal injection risk from context variables.
[Low] Error Suppression — Catching HTTP 422
The new label-creation code catches errors with status === 422 and treats them as "label already exists." This is correct behavior — the GitHub API returns 422 when creating a duplicate label. However, 422 can also indicate other validation failures (e.g., invalid color hex, label name exceeding length limits).
Assessment: In practice, since the label names, colors, and descriptions are all hardcoded constants, the only realistic 422 scenario is "already exists." Non-422 errors are correctly re-thrown. The risk of masking a real error is negligible. No action required.
[Info] Issue Creation Error Handling — Improvement
The original code had no error handling around issues.create. The new code wraps it in try/catch and calls core.setFailed() on failure, which is a clear improvement — failures will now surface as workflow failures rather than silently passing. Good change.
Summary
| Finding | Severity | Verdict |
|---|---|---|
| Workflow permissions scoped correctly | Info | Pass |
| Token scope minimal | Info | Pass |
| No label injection vector | Info | Pass |
| GitHub API usage safe (no context injection) | Info | Pass |
| 422 error catch scope | Low | Acceptable — hardcoded inputs eliminate ambiguity |
| Issue creation error handling | Info | Improvement over prior code |
Overall: No security concerns. The changes are well-scoped and follow security best practices for GitHub Actions workflows. The hardcoded label definitions, minimal permissions, and proper error handling make this a clean change.
— Security Review Agent
Summary
needs-investigationandperformancelabels if they don't already exist, preventing API 422 errorscore.setFailed()instead of silently failingTest plan
Fixes #1759
🤖 Generated with Claude Code