Repository navigation
chore: CI on main now fails when the dispatcher pin lags behind the newest stable release - #2474
Merged
Merged
Conversation
…er pin Fresh CLI installs resolve the dispatcher release named by the package pin, so between a stable dispatcher release and the pin stamp that follows it every new install keeps landing on the superseded release. Nothing detected that window; the 3.0.0 and 3.0.1 stamps were only noticed and opened by hand. The command lists the release repository's releases, keeps the published stable dispatcher-v<semver> tags, and fails when the pin records an older version than the newest of those. It fails closed: an unusable pinned tag or an API failure exits non-zero rather than passing on missing evidence. No stable dispatcher release at all is the initial state, not staleness, so that passes.
…e release The freshness command only helps if something runs it. Wire it into build-and-test.yml for every event except pull_request, so main goes red for as long as the pin trails the newest published stable dispatcher release and the lag cannot pass unnoticed until someone happens to look. Pull requests are excluded on purpose: while the automated pin-stamp pull request is open, every branch carries the same lagging pin, so failing there would redden all open work over a state only main can resolve.
Contributor
|
Warning Review limit reachedNext included review available in 6 minutes. View limit detailsLimit details: You’ve used all 4 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
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 |
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.
Part 2 of #2463 (follows #2473). Closes #2463.
Summary
mainnow fails while the dispatcher pin still records an older release than the newest published stabledispatcher-v*release, so a skipped pin stamp is visible instead of silentUser Impact
build-and-testrun onmainfails withcheck-dispatcher-pin-freshness: pin records dispatcher-vX but the newest stable dispatcher release is dispatcher-vY. Merge the automated pin-stamp pull request, or run stamp-dispatcher-pin --tag dispatcher-vY.The failure clears by merging the automated PR from chore: Stable dispatcher releases now open the pin-stamp pull request automatically #2473Changes
cli/release-automation/cmd/check-dispatcher-pin-freshness(new) backed byinternal/automation/dispatcher_pin_freshness.go: lists releases via the GitHub API (per_page=100, paged until a short page, fail-closed cap at 50 pages), keeps only non-draft, non-prereleasedispatcher-v<semver>tags without a pre-release identifier, takes the highest, and compares it todispatcherReleaseTaginPackages/src/project-runner-pin.json. Older pin → exit 1; equal or newer → pass; no stable release yet → pass; unreadable pin or API error → exit 1. Reuses the existing semver comparison (common/version), tag parsing, API headers, and token lookup — no new dependency.github/workflows/build-and-test.yml: new step "Check dispatcher pin freshness" withif: github.event_name != 'pull_request'. It is deliberately not run on pull requests: while the stamp PR is open, every other branch legitimately carries the lagging pin, and failing there would turn all open PRs red for a state onlymaincan fixdocs/dispatcher-pin-release-order.md,docs/project-runner-pin.md: document the gate and how to clear itVerification
cli/release-automation:gofmt -l .clean,go vet ./...,go test ./...pass (10 new tests: pagination, filtering of drafts / prereleases / other components / pre-release identifiers, older / equal / newer pin, empty listing, unreadable pin, API error);golangci-lint runwith both configs → 0 issuesscripts/check-go-cli.shexit 0;go run ./cmd/check-release-triggers --base origin/main --head HEAD→ "Release trigger guard passed.";go run ./cmd/check-file-length→ no file over 500 SLOC;actionlint .github/workflows/build-and-test.ymlcleanDispatcher pin freshness guard passed: pin records dispatcher-v3.0.1 and the newest stable dispatcher release is dispatcher-v3.0.1.exit 0Note
workflow_dispatchofbuild-and-test.ymlfrom a branch whose pin lags will also fail this step; that is the same signal as onmainand is intentionalhttps://claude.ai/code/session_01XbhSMKK4LFud57iAmowDz7