feat(release): add an experimental flag to Create Tag - #646
Merged
Conversation
Create Tag gains an `experimental` checkbox that marks the worker experimental in the registry. It is a badge, not a channel: the version publishes to the channel the operator picked, installs normally, and resolves normally. This is what replaces the reverted `experimental` channel — that one needed resolver support the registry never had, and isolating a release from `latest` is not what "this is unstable" should mean. The flag rides the annotated tag message next to `registry-tag:`, since the tag is all the Release workflow receives, and travels from there through `parse_release_tag.py` to the publish payload. Anything but the literal `true` publishes as stable, so a lightweight tag, a missing line, or a typo can never mark a stable worker by accident. The payload always carries the key as a real boolean. The registry reads a missing flag as the promotion signal and clears the badge, and rejects a stringly-typed value with 422 — a CI value that lost its type should fail loudly rather than silently promote a worker. Requires iii-hq/registry#81, which adds the column and the badge.
guibeira
added
the
no-ticket
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
skill-check — worker0 verified, 50 skipped (no docs/).
Four for four. Nicely done. |
📝 WalkthroughWalkthroughThe release flow now records experimental status in tags, parses and forwards it through GitHub Actions, and always includes it as a boolean in registry publish payloads. Tests and release documentation cover default, valid, normalized, and invalid annotation values. ChangesExperimental release metadata
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant Operator as Release Operator
participant CreateTag as create-tag.yml
participant ParseTag as parse_release_tag.py
participant Release as release.yml
participant Publish as _publish-registry.yml
participant Payload as build_publish_payload.py
Operator->>CreateTag: Select experimental option
CreateTag->>ParseTag: Create annotated tag with experimental field
ParseTag->>Release: Emit normalized experimental output
Release->>Publish: Pass experimental workflow input
Publish->>Payload: Pass experimental value
Payload-->>Publish: Generate payload with boolean experimental field
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 |
guibeira
marked this pull request as ready for review
July 30, 2026 19:58
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/scripts/build_publish_payload.py (1)
332-332: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAvoid truthiness coercion for
experimental.
bool("false")isTrue. The CLI currently normalizes its string before callingbuild_payload, but a direct caller passing a string could accidentally publish a stable worker as experimental. Validate that this parameter is a real boolean, then emit it directly.Proposed fix
def build_payload( *, @@ bundle: dict[str, Any] | None = None, experimental: bool = False, ) -> dict[str, Any]: + if not isinstance(experimental, bool): + raise TypeError("experimental must be a bool") + root = repo_root / worker @@ - "experimental": bool(experimental), + "experimental": experimental,Also applies to: 368-372
🤖 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 @.github/scripts/build_publish_payload.py at line 332, Update build_payload’s experimental parameter handling to require an actual boolean rather than coercing arbitrary values with bool(). Validate and reject string or other non-boolean inputs, then emit the validated experimental value directly in the payload while preserving the default False behavior.
🤖 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 113-116: Update the experimental release documentation near the
parse_release_tag.py flow to state that the value is trimmed and compared
case-insensitively, so variants such as “TRUE” and “ true ” are accepted while
missing or other values publish as stable.
---
Nitpick comments:
In @.github/scripts/build_publish_payload.py:
- Line 332: Update build_payload’s experimental parameter handling to require an
actual boolean rather than coercing arbitrary values with bool(). Validate and
reject string or other non-boolean inputs, then emit the validated experimental
value directly in the payload while preserving the default False behavior.
🪄 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: 3fa88d93-6344-457b-bf83-b6f5a7c46251
📒 Files selected for processing (8)
.github/scripts/build_publish_payload.py.github/scripts/parse_release_tag.py.github/scripts/tests/test_build_publish_payload.py.github/scripts/tests/test_parse_release_tag.py.github/workflows/_publish-registry.yml.github/workflows/create-tag.yml.github/workflows/release.ymldocs/sops/release.md
Comment on lines
+113
to
+116
| It travels the same way the channel does: `experimental: true` in the | ||
| annotated tag message, read by `parse_release_tag.py`, forwarded through | ||
| `release.yml` to the publish payload. Anything but the literal `true` — a | ||
| missing line, a lightweight tag, a typo — publishes as stable. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Document the normalization rule for experimental.
parse_release_tag.py accepts case-insensitive values and surrounding whitespace (TRUE, true), but this says only the literal true is accepted. State the trim-and-lowercase behavior explicitly so the documentation matches the parser and tests.
🤖 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 113 - 116, Update the experimental release
documentation near the parse_release_tag.py flow to state that the value is
trimmed and compared case-insensitively, so variants such as “TRUE” and “ true ”
are accepted while missing or other values publish as stable.
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
1 participant
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.
Adds an Experimental checkbox to Create Tag. Ticking it marks the worker
experimental in the registry — a badge, nothing more: the version publishes
to the channel you picked, installs normally, and resolves normally.
This is the replacement for the
experimentalchannel reverted in #643. Thatone needed resolver support the registry never had, and isolating a release
from
latestis not what "this is unstable" should mean.Depends on iii-hq/registry#81 (the column + the badge). Merging this
first would 422 every publish: the registry's publish payload is a strict
object, so it rejects the unknown field.
The path the flag takes
It rides the tag annotation next to
registry-tag:because the tag is allthe Release workflow receives — anything the publish needs has to be written
there.
Two rules worth knowing
Anything but the literal
trueis false. A lightweight tag, a missingline, a typo (
experimental: yes) — all publish as stable. Marking a workerexperimental is the deliberate choice, so it takes the exact word.
Leaving the box unticked is the promotion. The registry treats a release
without the flag as the signal that the worker stabilised and drops the
badge, so there is no separate promote step. Re-releasing while still
experimental keeps the original mark.
The payload always carries the key, always as a real boolean — the registry
422s a stringly-typed value, and a workflow input is a string.
Verification
.github/scripts/tests/: 157 passed (7 new — 5 on the annotationparsing incl. typo/casing/absent, 2 on the payload's boolean)
carrying
experimental: trueproduced"experimental": true(JSON bool)in the payload; the same tag without the line produced
falseSummary by CodeRabbit
New Features
Bug Fixes
false.false.Tests