Fix misplaced zizmor ignore comment in GHES host step generator#39740
Conversation
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
Hey
If you'd like a hand, you can assign this prompt to your coding agent:
|
…ock files Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
✅ Design Decision Gate 🏗️ completed the design decision gate check. No ADR enforcement needed: PR #39740 does not have the 'implementation' label and has only 2 new lines of code in business logic directories (≤100 threshold). |
|
🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅ |
|
✅ PR Code Quality Reviewer completed the code quality review. |
|
✅ Test Quality Sentinel completed test quality analysis. |
There was a problem hiding this comment.
⚠️ Not ready to approve
The lockfile regeneration includes additional semantic diffs (e.g., validation schema changes like optionalPositiveInteger → issueOrPRNumber) that aren’t explained by the stated zizmor-suppression fix and need confirmation or separation.
Pull request overview
This PR fixes the placement of the # zizmor: ignore[github-env] suppression associated with the GHES host configuration step so that zizmor’s span-based matching actually applies the suppression in compiled workflows.
Changes:
- Updated
generateGHESHostConfigurationStep()to emit the zizmor suppression inline on therun: |line (instead of as a sibling YAML comment line). - Tightened the unit test to assert the suppression is specifically on the
run:line. - Regenerated workflow lock files to propagate the corrected emitted YAML across compiled workflows.
File summaries
| File | Description |
|---|---|
| pkg/workflow/ghes_host_step.go | Moves the zizmor ignore annotation onto the `run: |
| pkg/workflow/ghes_host_step_test.go | Updates the assertion to validate suppression placement (on `run: |
| .github/workflows/*.lock.yml (249 files) | Regenerated compiled workflows to reflect the updated GHES host step YAML output (and includes some additional regenerated content that should be confirmed as intended). |
Copilot's findings
- Files reviewed: 251/251 changed files
- Comments generated: 2
Note
Your feedback helps us improve the quality of this feature.
Please use 👍 or 👎 to tell us whether this assessment is correct.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "pull_request_number": { | ||
| "optionalPositiveInteger": true | ||
| "issueOrPRNumber": true | ||
| }, |
| "pull_request_number": { | ||
| "optionalPositiveInteger": true | ||
| "issueOrPRNumber": true | ||
| }, |
🧪 Test Quality Sentinel Report✅ Test Quality Score: 100/100 — Excellent
📊 Metrics & Test Classification (1 test analyzed)
Go: 1 ( Verdict
|
There was a problem hiding this comment.
🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer
| shell: bash | ||
| # zizmor: ignore[github-env] - GITHUB_SERVER_URL is set by GitHub Actions, not user input. | ||
| run: | | ||
| run: | # zizmor: ignore[github-env] - GITHUB_SERVER_URL is set by GitHub Actions, not user input. |
There was a problem hiding this comment.
[/diagnose] Correct placement — the inline # zizmor: ignore[github-env] on run: | puts the suppression annotation within the block scalar span that zizmor associates with the github-env finding. This is the right fix.
One small observation: zizmor runs only in the daily static-analysis-report workflow (scheduled), not as a PR gate. This means similar silent suppression regressions would go undetected until the next scheduled scan. Consider whether adding gh aw compile --zizmor (or a targeted zizmor invocation against a sample lock file) to the standard PR CI pipeline would be worthwhile to catch these sooner.
There was a problem hiding this comment.
✅ LGTM — correct fix, no blocking issues
The zizmor suppression was genuinely broken: a YAML comment on a sibling line above run: | is a separate AST node and lies outside the block scalar span that zizmor associates with the github-env finding. Moving the annotation inline onto run: | is the right fix.
Review summary
pkg/workflow/ghes_host_step.go — surgically correct. Two lines (standalone comment + plain run: |) replaced by one (run: | # zizmor: ignore[github-env] - ...). Block scalar content is unchanged.
pkg/workflow/ghes_host_step_test.go — the assertion tightening from Contains(step, "zizmor: ignore[github-env]") to Contains(step, "run: | # zizmor: ignore[github-env]") is strictly stronger; it now verifies placement, not just presence.
249 .lock.yml files — consistently regenerated; no residual standalone # zizmor: ignore[github-env] lines remain in the tree.
Non-blocking note: pkg/workflow/frontmatter_extraction_yaml.go and pkg/workflow/jobs.go still emit standalone # zizmor: ignore[dangerous-triggers] comments, but those are above workflow_run: and if: mapping keys respectively (not run: block scalars), making them a separate concern outside this PR's scope.
Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
proxy.golang.org
To allow these domains, add them to the
network.allowedlist in your workflow frontmatter:
network:
allowed:
- defaults
- "proxy.golang.org"See Network Configuration for more information.
🔎 Code quality review by PR Code Quality Reviewer
The
# zizmor: ignore[github-env]annotation emitted bygenerateGHESHostConfigurationStep()was placed as a standalone YAML comment on the line aboverun:. Per zizmor's span-based matching, this comment is outside the block scalar span that owns thegithub-envfinding, so suppression silently never took effect — causing the High to persist in every compiled workflow that includes the GHES host step.Changes
pkg/workflow/ghes_host_step.go— Move annotation from a sibling comment line to inline onrun: |, placing it within the span zizmor associates with the finding:pkg/workflow/ghes_host_step_test.go— Tighten assertion fromContains(step, "zizmor: ignore[github-env]")toContains(step, "run: | # zizmor: ignore[github-env]"), so placement is validated, not just presence.249
.lock.ymlfiles — Recompiled; all now emit the annotation on the correct line.