fix(release-notes-status): count Container image among the CI blocks - #148
Conversation
The check that reports a CI-appended block destroyed by an overhaul looked for three sections: Installation, Verify your download and Software Bill of Materials. release-go-app.yml emits a fourth, `## Container image`, for every run that builds one -- the three rolling tags a consumer pulls. It was never in the list, so an overhaul that replaced the whole body destroyed it in silence and the script answered `ok`. Measured on netresearch/ldap-manager v1.7.0: the overhaul dropped both `## Container image` and `## Verify your download`, the check flagged only the second, and the release went out naming no image anywhere. The list moves into ci_block_sections() so the test reads what the check reads. A retyped copy in the test would agree with whatever the check does and stay green when a section is dropped; three assertions pin it instead, each verified by a mutation aimed at it -- removing "Container image" from the function reddens two, putting the literal list back in the loop reddens the third, and shellcheck stays clean. references/release-process.md gains the other half. The capture recipe it already documents only works BEFORE the first edit; afterwards the reflex is to copy the block out of the previous release, which is an output of the same pipeline and usually carries the same damage. The sibling comparison cannot catch that either: once a block is gone from every release on the line, nothing is left to compare against. The authority is the workflow that emits it. Learning-Id: retro-20260922-ci-block-container-image Assisted-by: claude-code:claude-opus-5 Agent-Session: https://claude.ai/code/session_013GWpRpyiM13Rh1NMQMBJo5 Agent-Host: 0493f0 Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe release process reference now instructs operators to preserve the original release body and reconstruct missing CI-generated sections from the orchestrator workflow. The status script defines a shared list of four CI sections, including Priority: ⬇️ Low Change: Bug fix Merge Risk: 🔵 Low · up to Valid binary-only releases may be incorrectly flagged for CI-section restoration when compared with a container-building sibling. Make the check conditional before merging. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 2 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches 💡 2📝 Generate docstrings 💡
🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
documentation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
|
|
Self-review: f3c75d1 The bot review this pull request demands is unsatisfiable (Copilot quota wall or repeated bot failures on this head). The diff on this head was reviewed by the PR author; this comment is the on-the-record attestation the merge gate reads back. It stops matching on the next push. |
Merging this makes
release-notes-status.shreport a destroyed## Container imageblock instead of answeringok, and tells the reference what to do once the original body is already gone. Only the checker, its test and one reference paragraph change.The defect
The CI-block check looked for three sections:
Installation,Verify your downloadandSoftware Bill of Materials.release-go-app.ymlemits a fourth for every run that builds a container —## Container image, holding the three rolling tags a consumer pulls (theCompose release bodystep, around line 795). An overhaul that replaces the whole body destroys it, and nothing objected.Measured on
netresearch/ldap-managerv1.7.0: the overhaul dropped## Container imageand## Verify your download, the check flagged only the second, and the published release named no image at all. The same was true of v1.6.0, destroyed by an earlier overhaul in the same way.The fix
The list moves into
ci_block_sections(), one section per line, and the loop reads it. That is what lets the test assert on the real list rather than a retyped copy — a copy would agree with whatever the check does and stay green when a section is dropped.Three assertions, each verified by a mutation aimed at it:
"Container image"fromci_block_sectionsThe tree was restored from a copy between mutations, the full suite is green on it (20 of 20), and
shellcheckis clean on both files.The other half, in the reference
references/release-process.mdalready documents the capture recipe. It only works before the firstgh release edit; afterwards the original is gone and the reflex is to copy the block out of the previous release with its version strings rewritten. That release is an output of the same pipeline and usually carries the same damage, so the repair inherits it — and the sibling comparison cannot catch that, because a block missing from every release on the line leaves nothing to compare against. The added paragraph names the orchestrator'sCompose release bodystep as the authority and cites the measured case.Not touched
The sibling comparison itself, its same-major scoping,
body_has, and every other verdict the script computes. Thelostreporting path is unchanged — it now simply has a fourth section to find.Assisted by claude-code:claude-opus-5 — Session