feat(scripts): mechanise the release lifecycle with release-status.sh - #74
Merged
Conversation
The skill's eight scripts all run before the tag, and the guards only block bad commands. Everything after the tag — rewriting the body into a narrative, crediting contributors inline, confirming the registries actually serve the version — is prose. That is the part that gets skipped, because a release with an auto-generated body renders exactly like a finished one. Measured on one session releasing six packages: the step-9 overhaul was skipped on 4 of 7 releases, and nobody noticed until a reader did. release-status.sh is the release-side counterpart to git-workflow's pr-status.sh: it reports where the repo sits in the lifecycle and ends in a computed NEXT (prepare-release, merge-release-pr, signed-tag, await-release-workflow, rewrite-release-notes, verify-publication, ok), exiting non-zero until the release is genuinely finished. release-notes-status.sh answers the narrower question and is reusable on its own: is the published body still CI output, is every harvested contributor @mentioned, was a Contributors section hand-written where inline credit belongs, did an overhaul clobber the CI-appended blocks. Both were validated against real releases while being written: - correctly cleared seven overhauled releases - correctly flagged three that were never overhauled, naming a reporter the author of those notes had missed - found a repository whose release workflow declares an extension-key and a TER token while TER 404s the key — a publication claim that has never been true, which the "verify each publication claim" rule asks for and nothing enforced - the TER assertion is gated on the workflow actually declaring it, after an early version raised a false alarm on a repo that deliberately does not publish there - a stale-worktree guard, after an early version reported ok for a version released two tags ago /release-status now defers to the script and keeps its manual steps for explaining a verdict. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
github-actions
Bot
added
documentation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
The pointer to the new scripts pushed SKILL.md to 643 words against a 500 limit that it already sat exactly on, so Skill Validation failed. Trimmed the pointer to two lines and condensed step 9, whose detail — inline crediting, reporters, the harvest-vs-git-log rule — is already stated verbatim in references/release-process.md Phase 5, which it now links instead of repeating. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
… lookup The declared-version chain covered ext_emconf.php and composer's extra.typo3/cms.version. A skill repo declares its version only in .claude-plugin/plugin.json, so every skill repo resolved to an empty declared version and the verdict came out as prepare-release no matter how cleanly it was released (checked against concourse-ci-skill at v1.9.3: declared <none>, NEXT prepare-release; with the fallback: declared 1.9.3, NEXT verify-publication). latest_tag was assigned and never read (shellcheck SC2034), costing one API call per invocation. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
Member
Author
|
Manual review standing in for Ran against the PR head: Two findings, both fixed in 642bb7a on this branch: 1. Skill repos always came out as
That is the whole skill fleet — the tool's main audience here — getting a wrong answer. Added 2. Two observations, not changed here:
|
Running the script against its own repo exposed the gap your plugin.json fix uncovered from the other side: a skill repo (composer type ai-agent-skill) is not a Packagist package, so the version assertion failed it forever. "Packagist does not know this package" (404 on the package) now means skip; "package known, version absent" still means the publication has not landed. Same distinction the TER check already makes. Verified both directions: the skill repo now reads ok, and t3x-nr-llm v0.26.0 -- a real Packagist package -- is still asserted. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The gap
All eight existing scripts run before the tag, and the guards only block bad commands. Everything after it — rewriting the body into a narrative, crediting contributors inline, confirming the registries actually serve the version — is prose in
release-process.md.That is the part that gets skipped, and it is skipped for a structural reason rather than carelessness: a release whose body is still the auto-generated PR-title list renders on GitHub exactly like a finished one. There is no red signal anywhere.
Measured on one session that released six packages: the step-9 overhaul was skipped on 4 of 7 releases. It surfaced only because a reader opened one and asked where the contributors were.
Compare the two skills today:
pr-status.sh→ computedNEXTWhat this adds
release-status.sh— the release-side counterpart topr-status.sh. Reports where the repo sits and ends in a computedNEXT:Exits non-zero until the release is genuinely finished, so it works as a gate.
release-notes-status.sh— the narrower question, usable on its own and with--last Nto sweep a backlog. Checks the published body against the rules this skill already states: auto-generated shape, CI stub, harvested contributors never@mentioned, a hand-written## Contributorssection where inline credit belongs, CI-appended blocks clobbered by an overhaul./release-statusnow defers to the script and keeps its manual steps for explaining a verdict.Validated while writing, not after
okextension-keyandTYPO3_TER_ACCESS_TOKENwhile TER 404s the key: a publication claim that has never been true. This is exactly what "Verify each publication claim before reporting the release done" asks for, and nothing enforced it.Two false starts are pinned as behaviour rather than left as lore:
okfor a version released two tags ago — the working tree declared the older version and nothing compared it to the latest releaseTests
tests/release-notes-status.test.sh, following the existingharvest-contributors.test.shpattern — pure helpers, no network, 8 assertions green. It pins the false positive that cost the most time: the harvest script's own header contains@mention each INLINE at their change, so extracting credits without dropping comment lines invents a contributor named@mentionand reports every finished release as missing them.