(MOT-4299) feat(release): resolve promotion candidates from next by default - #714
(MOT-4299) feat(release): resolve promotion candidates from next by default#714ytallo wants to merge 2 commits into
Conversation
The harness_smoke setup output has had no consumer since 7f57418 gated candidates on the smoke only; candidate-ready hardcodes the harness gate as skipped.
A promotion always ships the candidate behind next, so Promote Worker now only requires the worker: the version is resolved from the Registry and the Release run is located from the resulting tag. Both inputs remain as overrides for the repair paths (retrying after next moved on, dispatched Release re-runs).
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
skill-check — worker0 verified, 54 skipped (no docs/).
Four for four. Nicely done. |
📝 WalkthroughWalkthroughThe promotion workflow now resolves omitted version and Release run inputs automatically. It validates resolved values and uses them throughout promotion. The release workflow no longer detects or exposes Harness smoke targets. The release SOP documents the new defaults. ChangesWorker promotion resolution
Harness smoke detection removal
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Operator
participant PromoteWorker
participant Registry
participant ReleaseWorkflow
Operator->>PromoteWorker: Dispatch with optional version and release_run_id
PromoteWorker->>Registry: Read next channel when version is omitted
Registry-->>PromoteWorker: Return candidate version
PromoteWorker->>ReleaseWorkflow: Find run by worker version tag
ReleaseWorkflow-->>PromoteWorker: Return release run ID
PromoteWorker->>PromoteWorker: Validate and export resolved values
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 @.github/workflows/promote-worker.yml:
- Around line 91-94: Update the stable-version validation regex in the
workflow’s version-check block to require each MAJOR, MINOR, and PATCH component
to be either 0 or a nonzero digit followed by digits, rejecting values such as
01.2.3 while preserving acceptance of valid stable MAJOR.MINOR.PATCH versions.
- Around line 96-105: Update the Release workflow lookup in the run_id
resolution block to pass the tag through the documented branch filter instead of
head_branch. Keep the existing tag construction, run selection, and missing-run
handling unchanged, using branch="${WORKER}/v${version}" in the gh api request.
🪄 Autofix
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: 2cdabf97-7b79-4d16-9f06-4081979120aa
📒 Files selected for processing (3)
.github/workflows/promote-worker.yml.github/workflows/release.ymldocs/sops/release.md
💤 Files with no reviewable changes (1)
- .github/workflows/release.yml
| [[ "$version" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]] || { | ||
| echo "::error::candidate must be stable semver MAJOR.MINOR.PATCH (got ${version}); prereleases are not promotable" | ||
| exit 2 | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Reject numeric identifiers with leading zeroes.
The expression accepts values such as 01.2.3. Those values are not valid SemVer. This permits an invalid override to pass validation and fail later when the workflow uses the mismatched tag.
Proposed fix
- [[ "$version" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]] || {
+ [[ "$version" =~ ^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)$ ]] || {Semantic Versioning forbids leading zeroes in normal version identifiers. (semver.org)
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| [[ "$version" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]] || { | |
| echo "::error::candidate must be stable semver MAJOR.MINOR.PATCH (got ${version}); prereleases are not promotable" | |
| exit 2 | |
| } | |
| [[ "$version" =~ ^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)$ ]] || { | |
| echo "::error::candidate must be stable semver MAJOR.MINOR.PATCH (got ${version}); prereleases are not promotable" | |
| exit 2 | |
| } |
🤖 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/workflows/promote-worker.yml around lines 91 - 94, Update the
stable-version validation regex in the workflow’s version-check block to require
each MAJOR, MINOR, and PATCH component to be either 0 or a nonzero digit
followed by digits, rejecting values such as 01.2.3 while preserving acceptance
of valid stable MAJOR.MINOR.PATCH versions.
| run_id="$RUN_ID_INPUT" | ||
| if [[ -z "$run_id" ]]; then | ||
| tag="${WORKER}/v${version}" | ||
| run_id=$(gh api -X GET "repos/${GITHUB_REPOSITORY}/actions/workflows/release.yml/runs" \ | ||
| -f head_branch="$tag" --jq '.workflow_runs[0].id // empty') | ||
| [[ -n "$run_id" ]] || { | ||
| echo "::error::No Release run found for tag ${tag}; pass release_run_id explicitly" | ||
| exit 2 | ||
| } | ||
| echo "::notice::candidate evidence expected in Release run ${run_id}" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
workflow=.github/workflows/promote-worker.yml
sed -n '96,105p' "$workflow"
# Expected: the workflow-run API query uses `branch="$tag"`.
rg -n -C 2 'actions/workflows/release\.yml/runs|head_branch|branch=' "$workflow"Repository: iii-hq/workers
Length of output: 1561
🌐 Web query:
GitHub REST API list workflow runs query parameter branch workflow_runs documentation
💡 Result:
In the GitHub REST API, the branch parameter is used to filter workflow runs by a specific branch name [1][2]. This parameter is available for the following endpoints used to list workflow runs: 1. List workflow runs for a repository: GET /repos/{owner}/{repo}/actions/runs [1][2] 2. List workflow runs for a workflow: GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs [1][2] When using the branch parameter, you must provide the name of the branch associated with the push event [1][2]. It is a query parameter used to narrow the results of the request [1][2].
Citations:
- 1: https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10
- 2: https://docs.github.com/rest/actions/workflow-runs
Query the Release workflow runs by branch, not head_branch.
head_branch is a response field from workflow runs, while the documented query filter is branch. Use branch="${WORKER}/v${version}" so the lookup can only return runs pushed on that tag.
Proposed fix
tag="${WORKER}/v${version}"
run_id=$(gh api -X GET "repos/${GITHUB_REPOSITORY}/actions/workflows/release.yml/runs" \
- -f head_branch="$tag" --jq '.workflow_runs[0].id // empty')
+ -f branch="$tag" --jq '.workflow_runs[0].id // empty')📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| run_id="$RUN_ID_INPUT" | |
| if [[ -z "$run_id" ]]; then | |
| tag="${WORKER}/v${version}" | |
| run_id=$(gh api -X GET "repos/${GITHUB_REPOSITORY}/actions/workflows/release.yml/runs" \ | |
| -f head_branch="$tag" --jq '.workflow_runs[0].id // empty') | |
| [[ -n "$run_id" ]] || { | |
| echo "::error::No Release run found for tag ${tag}; pass release_run_id explicitly" | |
| exit 2 | |
| } | |
| echo "::notice::candidate evidence expected in Release run ${run_id}" | |
| run_id="$RUN_ID_INPUT" | |
| if [[ -z "$run_id" ]]; then | |
| tag="${WORKER}/v${version}" | |
| run_id=$(gh api -X GET "repos/${GITHUB_REPOSITORY}/actions/workflows/release.yml/runs" \ | |
| -f branch="$tag" --jq '.workflow_runs[0].id // empty') | |
| [[ -n "$run_id" ]] || { | |
| echo "::error::No Release run found for tag ${tag}; pass release_run_id explicitly" | |
| exit 2 | |
| } | |
| echo "::notice::candidate evidence expected in Release run ${run_id}" |
🤖 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/workflows/promote-worker.yml around lines 96 - 105, Update the
Release workflow lookup in the run_id resolution block to pass the tag through
the documented branch filter instead of head_branch. Keep the existing tag
construction, run selection, and missing-run handling unchanged, using
branch="${WORKER}/v${version}" in the gh api request.
1 participant
Summary
Two staged-release pipeline follow-ups to MOT-4299:
next, soversionis resolved from the Registry (resolve_version()fromregistry_release.py, stable-semver enforced) andrelease_run_idis located by querying Release runs forhead_branch=<worker>/vX.Y.Z(tag-push runs carry the tag there). Both inputs remain as optional overrides for the repair paths: retrying an interrupted promotion afternextmoved on, and dispatched Release re-runs whosehead_branchismain. All downstream gates are untouched — evidence identity,tag_shamatch, and the registry precondition thatnextstill points at the resolved version.harness_smokedetection fromrelease.yml. The setup output has had no consumer since 7f57418 gated candidates on the smoke only.The release SOP's "Promote to latest" section is updated to match.
Verification
yaml.safe_loadon both workflows;bash -non the new resolve step; heredoc Python compiles.harness@nextresolves to1.7.3, and the run lookup forharness/v1.7.3returns Release run30997666861(eventpush, success) — matching what would have been typed manually.grepconfirms no remainingharness_smokereferences in.github/ordocs/.Summary by CodeRabbit
New Features
Bug Fixes
Documentation