feat(release): split version suffix from registry channel - #615
Conversation
The registry stores `registry-tag` as a free-form string and moves it atomically per worker, so extra channels needed no API change — only the Create Tag / Publish skills dispatch inputs were a closed choice of latest|next. Adds rc, beta and alpha to both, and validates the value parsed from the annotated tag message against the same closed set. Without that check a typo (`latests`) would publish a channel nothing ever resolves.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
skill-check — worker0 verified, 49 skipped (no docs/).
Four for four. Nicely done. |
📝 WalkthroughWalkthroughRegistry release channels now include ChangesRegistry channel expansion
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/sops/release.md`:
- Around line 134-136: Standardize the spelling of “prerelease” throughout
release.md by replacing any “pre-release” variants with the document’s chosen
consistent form, while preserving the existing release behavior and wording
otherwise.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: bde71858-5fc6-4ebc-80b6-6e51d196b8d9
📒 Files selected for processing (8)
.github/scripts/parse_release_tag.py.github/scripts/tests/test_parse_release_tag.py.github/workflows/_container.yml.github/workflows/_publish-registry.yml.github/workflows/_publish-worker-skills.yml.github/workflows/create-tag.yml.github/workflows/publish-worker-skills.ymldocs/sops/release.md
| With tag message including a prerelease channel (`registry-tag: rc`, `beta`, | ||
| `alpha` or `next`). Marks the GitHub Release as prerelease; still builds and | ||
| publishes (unless `interface_smoke: false`). |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Standardize “prerelease” spelling.
release.md mixes prerelease and pre-release; use one spelling consistently across the document.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~134-~134: Do not mix variants of the same word (‘prerelease’ and ‘pre-release’) within a single text.
Context: ...eta.1 ``` With tag message including a prerelease channel (registry-tag: rc, `beta`, `a...
(EN_WORD_COHERENCY)
[uncategorized] ~135-~135: Do not mix variants of the same word (‘prerelease’ and ‘pre-release’) within a single text.
Context: ...or next). Marks the GitHub Release as prerelease; still builds and publishes (unless `in...
(EN_WORD_COHERENCY)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/sops/release.md` around lines 134 - 136, Standardize the spelling of
“prerelease” throughout release.md by replacing any “pre-release” variants with
the document’s chosen consistent form, while preserving the existing release
behavior and wording otherwise.
Source: Linters/SAST tools
Channel and pre-release suffix are independent axes, not one list. A release is `<version>@<channel>`: 1.2.4-rc.1@next. Create Tag gains a `suffix` input (none|alpha|beta|rc|stable) alongside the existing bump, while `tag` stays a channel and gains `experimental`. Bump picks the base version, suffix decides whether that base ships as a pre-release, so `bump: none` iterates a pre-release without walking the version forward and `stable` promotes it to its base. The counter comes from existing git tags, so re-running with the same base and suffix advances -rc.1 to -rc.2 instead of colliding with the pushed tag. Each suffix line advances independently at the same base. parse_release_tag.py validates the channel against a closed set: the registry stores `registry-tag` verbatim, so a typo (or a suffix passed as a channel) would publish to a channel nothing resolves, with no unpublish to undo it.
* Revert "fix(release): trigger alpha tag publish (#633)" This reverts commit 45b212f. * Revert "fix(release): trigger alpha publish pipeline (#632)" This reverts commit 4f1b339. * Revert "fix(ci): simplify alpha release inputs (#628)" This reverts commit 72a6595. * Revert "feat(release): add alpha releases from pull request branches (#626)" This reverts commit ac0f750. * Revert "fix(release): isolate alpha releases (#631)" This reverts commit 156f5dd. * Revert "chore(image-resize): bump to v0.1.13-alpha.1" This reverts commit 0cba488. * Revert "feat(release): split version suffix from registry channel (#615)" This reverts commit d0bc06d.
Problem
The distribution channel and the pre-release suffix are independent axes, and the workflow modelled them as a single list. A release is
<version>@<channel>—1.2.4-rc.1@next. That was not expressible:tagwas achoiceclosed tolatest|nextand there was no suffix input at all, so the SOP read "Create Tag cannot produce prerelease suffixes. Push a manual annotated tag".Change
create-tag.ymlgains asuffixinput and keepstagas the channel:bumppatchminormajornonesuffixnonealphabetarcstabletaglatestnextexperimentalThe two axes compose freely.
bump: noneiterates a pre-release without walking the version forward;stablepromotes a pre-release to its base without bumping:The counter comes from existing git tags (
--workeronmanifest_version.py bump), so repeating the same base and suffix advances-rc.1to-rc.2instead of colliding with the tag already pushed — the "Check tag does not exist" step would otherwise fail the release. Separate suffix lines at the same base advance independently.parse_release_tag.pyvalidates the channel against a closed set. The registry storesregistry-tagverbatim in a free-form column and there is no unpublish: a typo — or a suffix passed as a channel, exactly the confusion that prompted this PR — would publish to a channel nothing resolves, with no way to undo it.Reusable workflow descriptions updated (
registry_tagwas alreadytype: string, so no contract changed).Compatibility
suffixdefaults tonone, which reproduces current behaviour byte for byte. Existing stable releases are unaffected.1.2.4-rc.1normalises under PEP 440 (1.2.4rc1), so Python workers do not break.Known limitation (outside this repo)
Publishing to
next/experimentalworks end to end, but installing by channel name does not — and that already applied to thenextthat existed before this PR. The registry resolver only treatslatestas an alias (resolver.service.ts:208-227); any other string falls through to semver validation and returnsinvalid_version. Vector indexing is also hardcoded totag = 'latest'.Enabling
iii worker add <worker>@nextrequires a change iniii-hq/registry— filed as iii-hq/registry#76. Documented in the SOP so the limitation is not a surprise.Worth noting that suffixed versions are filtered out of the resolver by
isStable— that is the desired behaviour: a^1.2.0must never silently resolve to1.2.4-rc.2.Testing
Full suite: 158 passed.
test_manifest_version.py: parametrised suffixes,bump: nonepreserving the base,stablepromoting, invalid suffix rejected.TestPrereleaseCounter: counter continuing from existing tags and ignoring another suffix, another worker and another base.test_parse_release_tag.py: theexperimentalchannel, a suffixed version on any channel markingis_prerelease, and invalid channels rejected — includingalpha, which is a suffix and never a channel.