chore: Manage dispatcher releases with Release Please#1462
Merged
Conversation
Add a dispatcher package to release-please-config.json (component dispatcher, prerelease beta, dispatcher-v<version> tags) with dispatcher-contract.json dispatcherVersion as a stamped extra-file, seed the manifest with the current 3.0.1-beta.11 so the tag sequence continues, and create dispatcher/CHANGELOG.md as the changelog anchor. The package release sync must skip the dispatcher package: dispatcher- publish owns the tag/draft/assets/publish flow, and a sync-created release would go public before its assets are uploaded. dispatcher- publish itself needs no changes because its resolve script already treats an existing asset-less release as upload-only work.
release-please now stamps dispatcherVersion, so requiring a manual bump in every dispatcher PR would fail all of them. The guard splits into two focused checks: - check-release-triggers fails when out-of-package release inputs (non-test common module sources, installer scripts) change without a companion change under each consuming package root, because release-please attributes commits by package root path only. - check-dispatcher-contract keeps the dispatcherContractVersion regression detection, including the legacy-path fallback for base refs that predate the directory split. scripts/stamp-release-inputs.sh writes shared-inputs-stamp.json under project-runner/ and dispatcher/ from a deterministic hash of the shared inputs, giving common and installer changes a one-command release trigger. Hashing covers path/content pairs so renames restamp too.
dispatcherVersion joined the release-please stamp list, and the Dispatcher Release Inputs section now describes the shared-release-input trigger rules and the stamp command instead of the retired manual bump requirement.
Contributor
|
Caution Review failedAn error occurred during the review process. Please try again later. 📝 WalkthroughWalkthroughThis PR adds release-trigger and dispatcher-contract guards, generates shared-input stamp files, configures dispatcher as a release-please package, and updates CI workflow and governance documentation. ChangesDispatcher release automation
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant check-release-triggers
participant check-dispatcher-contract
participant GitRepo
GitHubActions->>check-release-triggers: run on pull_request
check-release-triggers->>GitRepo: diff base..head
GitRepo-->>check-release-triggers: changed files
check-release-triggers->>check-release-triggers: match shared inputs and trigger roots
GitHubActions->>check-dispatcher-contract: run on pull_request
check-dispatcher-contract->>GitRepo: read dispatcher contract at base and head
GitRepo-->>check-dispatcher-contract: contract JSON
check-dispatcher-contract->>check-dispatcher-contract: compare dispatcherContractVersion values
Possibly related PRs
🚥 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 |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/build-and-test.yml (1)
68-76: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winTemplate-injection pattern replicated from existing steps.
--base "origin/${{ github.base_ref }}"expands the ref directly into the shell command at YAML-render time (flagged by zizmor). This mirrors the existing pattern at lines 54 and 61, so it's not a new risk class introduced here, but each additional occurrence widens the exposed surface. Consider passing the ref via anenv:var and referencing$BASE_REFinrun:to avoid template expansion into the shell command.🔒 Proposed fix using env indirection
- name: Check release triggers if: github.event_name == 'pull_request' working-directory: tools/release-automation - run: go run ./cmd/check-release-triggers --base "origin/${{ github.base_ref }}" --head HEAD + env: + BASE_REF: ${{ github.base_ref }} + run: go run ./cmd/check-release-triggers --base "origin/$BASE_REF" --head HEAD - name: Check dispatcher contract if: github.event_name == 'pull_request' working-directory: tools/release-automation - run: go run ./cmd/check-dispatcher-contract --base "origin/${{ github.base_ref }}" --head HEAD + env: + BASE_REF: ${{ github.base_ref }} + run: go run ./cmd/check-dispatcher-contract --base "origin/$BASE_REF" --head HEAD🤖 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/build-and-test.yml around lines 68 - 76, The release-automation workflow steps for Check release triggers and Check dispatcher contract currently inline github.base_ref directly in the run command, which repeats the template-injection pattern. Update these steps to pass the base ref through an env variable on the job/step and reference that variable in the go run arguments instead of expanding origin/${{ github.base_ref }} inside the shell command, matching the surrounding workflow style while avoiding YAML-to-shell interpolation.Source: Linters/SAST tools
🤖 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 `@tools/release-automation/internal/automation/dispatcher_contract_guard.go`:
- Around line 131-149: The semver check in ParseDispatcherContractValues is
currently using sharedversion.Compare with the same value twice, which can
incorrectly accept malformed dispatcherVersion values. Replace that check with a
direct semver validation helper in ParseDispatcherContractValues so the
dispatcherVersion field is validated for format before continuing, and keep the
existing error message path in dispatcherContractGuard for invalid values.
---
Nitpick comments:
In @.github/workflows/build-and-test.yml:
- Around line 68-76: The release-automation workflow steps for Check release
triggers and Check dispatcher contract currently inline github.base_ref directly
in the run command, which repeats the template-injection pattern. Update these
steps to pass the base ref through an env variable on the job/step and reference
that variable in the go run arguments instead of expanding origin/${{
github.base_ref }} inside the shell command, matching the surrounding workflow
style while avoiding YAML-to-shell interpolation.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b8c234f0-ec82-4afc-968d-25c4bd23aa64
📒 Files selected for processing (20)
.github/workflows/build-and-test.yml.release-please-manifest.jsonAGENTS.mddispatcher/CHANGELOG.mddispatcher/shared-inputs-stamp.jsonproject-runner/shared-inputs-stamp.jsonrelease-please-config.jsonscripts/stamp-release-inputs.shscripts/sync-release-please-package-releases.shscripts/test-release-please-config.shscripts/test-stamp-release-inputs.shscripts/test-sync-release-please-package-releases.shtools/release-automation/cmd/check-dispatcher-contract/main.gotools/release-automation/cmd/check-release-triggers/main.gotools/release-automation/internal/automation/dispatcher_contract_guard.gotools/release-automation/internal/automation/dispatcher_contract_guard_test.gotools/release-automation/internal/automation/dispatcher_version_bump_guard.gotools/release-automation/internal/automation/dispatcher_version_bump_guard_test.gotools/release-automation/internal/automation/release_trigger_guard.gotools/release-automation/internal/automation/release_trigger_guard_test.go
💤 Files with no reviewable changes (2)
- tools/release-automation/internal/automation/dispatcher_version_bump_guard.go
- tools/release-automation/internal/automation/dispatcher_version_bump_guard_test.go
CI gofumpt rejects a blank line between an err-returning assignment and its err check. The local source check missed these because the new test file was still untracked when it ran.
There was a problem hiding this comment.
2 issues found and verified against the latest diff
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Review feedback on the stamp-release-inputs test: the installer-only scenario changed only install.sh, so dropping install.ps1 from the dispatcher stamp inputs would regress unnoticed on Windows; a dedicated ps1-only case now guards that path. run_stamp also dumps its captured stdout/stderr on failure because the temp files vanish with the cleanup trap, which left CI failures undiagnosable.
release_tag_from_body only knew unity-package and uloop-project-runner, so a merged dispatcher release PR resolved to an empty tag, fell through the title fallback (branch-scoped titles carry no version), and stayed stuck on "autorelease: pending" forever. Map dispatcher summaries to dispatcher-v<version> so the repair step promotes them like the other components.
POSIX pipelines report only the last command's status, so a mid-list git hash-object failure previously let `git hash-object --stdin` hash the truncated manifest and write a plausible-looking but wrong stamp with exit 0. Route the manifest through a command substitution so any hash failure aborts the run before a stamp is written. The manifest format is unchanged, so existing stamp hashes stay stable (verified by restamping this checkout with no diff).
The guard only compares dispatcherContractVersion; the DispatcherVersion field was parsed and semver-validated but never consumed by the analyze, needs-action, or warning paths. The format check also duplicated TestDispatcherContractProvidesRuntimeVersion in the dispatcher module, which already pins the semver format of the same contract file on every PR. Keep only the dispatcherContractVersion extraction the guard uses.
The trigger rules are re-encoded as shell in stamp-release-inputs.sh. With two rules the cross-references and the stamp behavior tests keep the implementations aligned; record the agreed follow-up that a third rule should bring an equivalence test between the two encodings.
This was referenced Jul 3, 2026
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.
Summary
User Impact
dispatcherVersionbump, and acommon/change could reach the project runner release while silently missing the dispatcher release (or vice versa).dispatcher-v<version>with all assets exactly as before.common/and installer changes fail PR CI untilscripts/stamp-release-inputs.shmarks every affected release.Changes
release-please-config.jsongains a third packagedispatcher(componentdispatcher, prerelease beta,dispatcher-v<version>tags, stampsdispatcher-contract.json$.dispatcherVersion). The manifest is seeded at the current3.0.1-beta.11so the tag sequence continues, anddispatcher/CHANGELOG.mdanchors future changelogs.sync-release-please-package-releases.shskips the dispatcher package. dispatcher-publish keeps owning the tag/draft/assets/publish flow; a sync-created release would go public before its assets upload. dispatcher-publish itself needs no changes because its resolve script already treats an existing asset-less release as upload-only work.check-dispatcher-version-bumpis replaced by two focused guards:check-release-triggersfails when out-of-package release inputs (non-testcommon/**/*.go,common/go.mod,common/go.sum, installer scripts) change without a companion change under each consuming package root, andcheck-dispatcher-contractkeeps thedispatcherContractVersionregression detection.scripts/stamp-release-inputs.shwritesshared-inputs-stamp.jsonunderproject-runner/anddispatcher/from a deterministic hash of the shared inputs (path/content pairs, so renames restamp too).dispatcherVersionjoins the release-please-only stamp list.Verification
scripts/check-go-cli.sh(fmt, vet, lint, tests, builds across all four Go modules)scripts/test-release-please-config.sh,test-sync-release-please-package-releases.sh,test-stamp-release-inputs.sh,test-resolve-dispatcher-release-target.sh,test-resolve-native-cli-release-target.sh,test-native-cli-publish-workflow.shcheck-release-triggerswith the stamp-command hint, passes after runningscripts/stamp-release-inputs.sh, and the branch itself passes both new guards againstorigin/v3-beta.