fix(ci): the Gate's coverage artifact had the name its only consumer wanted, plus .json - #110
Conversation
…wanted, plus .json Maint Coverage Guard failed the moment it was unheld, on both runs (#3 scheduled, #4 manual), with: error: Coverage verification could not find required coverage artifacts on a successful Gate run. warn: Unable to locate a recent successful Gate workflow run with required coverage artifacts: gate-coverage-trend, gate-coverage-trend-history, gate-coverage. maint-coverage-guard.yml downloads exactly three artifact NAMES. The Gate produced the first two under those names and the third as "gate-coverage.json", so the guard probed ten successful runs, found two of three every time, and reported no usable run at all. Measured rather than inferred: Gate run #241 (main, success) uploaded gate-coverage-summary.md, gate-coverage.json, gate-summary.md, gate-coverage-3.13-1, gate-coverage-trend-history, gate-coverage-trend, gate-coverage-summary, gate-coverage-3.12-1 -- trend and trend-history present, "gate-coverage" absent. An artifact NAME and the FILE inside it are different things, and this step conflated them. Renaming the artifact is safe and was checked, not assumed: "gate-coverage.json" as an artifact name appears nowhere else in this repo, and the only download-artifact steps in any workflow here are the guard's three. The file inside is still gate-coverage.json, so anything reading contents is unaffected. A paired literal in two files that disagreed -- this repo's signature defect -- and it stayed invisible for as long as the guard was held. That is the second thing the holds were concealing, after PR #90's six F821s. pr-00-gate.yml is create_only in the Workflows sync manifest with Orchestrator absent from overwrite_repos, so this local fix persists. The same mismatch likely affects every consumer whose Gate emits coverage, which is worth raising upstream separately. 448 collected, ruff and black clean, test_ci_gate_config 12 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 51 minutes. View limit detailsLimit details: You’ve used the included review currently available. Your 71 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
Automated Status SummaryHead SHA: e142d61
Coverage Overview
Updated automatically; will refresh on subsequent CI/Docker completions. Keepalive checklistScopeNo scope information available Tasks
Acceptance criteria
|
|
Workflow state fingerprint for Agents Gate Followups. Do not edit. |
The Coverage Guard's annotations, fixed. This is the second defect the workflow holds were concealing, after #90's six
F821s.What the annotations said
Both newly-unheld runs failed — #3 (scheduled) and #4 (manual):
The cause: an artifact name and a file name are not the same thing
maint-coverage-guard.ymldownloads exactly three artifact names (L251/261/271). Measured on Gate run #241 (main, success), the Gate uploaded:gate-coverage-trendgate-coverage-trend-historygate-coveragegate-coverage.jsonPlus
gate-coverage-summary.md,gate-summary.md,gate-coverage-summary,gate-coverage-3.12-1,gate-coverage-3.13-1.So the guard probed ten successful runs, found two of three every time, and correctly concluded it had no usable run.
name:is the artifact name;path:is the file. This step conflated them.A paired literal in two files that disagreed — this repo's signature defect — invisible for exactly as long as the guard was held.
Why renaming is safe (checked, not assumed)
gate-coverage.jsonas an artifact name appears nowhere else in this repo — its only occurrence was its own upload step.download-artifactsteps in any workflow here are the guard's three.gate-coverage.json, so anything reading contents is unaffected.pr-00-gate.ymliscreate_onlyin the sync manifest with Orchestrator absent fromoverwrite_repos, so this fix persists rather than being clobbered.Worth raising upstream separately
The mismatch is between an upstream-templated Gate and an upstream-synced guard, so every consumer whose Gate emits coverage likely has the same silently-broken guard. I haven't filed that — it's a Workflows-repo change and you may want it batched with the
app-iddeprecation below.Also in those annotations, not fixed here
Five warnings, all the same:
Input 'app-id' has been deprecated with message: Use 'client-id' instead— fromcreate-github-app-tokeninmaint-coverage-guard.yml, which is a normal synced file. Editing it locally would be clobbered by the next template sync, so the fix belongs upstream. Harmless today; it will break when the action drops the input.Verification
test_ci_gate_config.py12 passed, 448 collected,ruffandblackclean, YAML parses. No test asserts on artifact names, so nothing needed updating — arguably a gap, but adding a test that pins two upstream-owned literals together is the kind of paired assertion that goes stale; the guard failing loudly is now the real check.