Problem
Packages/src/project-runner-pin.json resolves which dispatcher release install.sh, install.ps1, and the Unity Install CLI button download (dispatcherReleaseTag + dispatcherArchiveManifest). Stamping that field is a manual step today: after a dispatcher release is published, someone must run go run ./cmd/stamp-dispatcher-pin --tag dispatcher-vX.Y.Z in cli/release-automation, mirror the file to .uloop/project-runner-pin.json, and open a PR.
During the 3.0.0 release this step was missed at first: dispatcher-v3.0.0 was published while the pin still pointed at dispatcher-v3.0.0-beta.31, so a fresh install.sh run installed a beta dispatcher (which then follows the beta self-update channel forever). It was caught by the post-release install check and fixed in #2461, but nothing in the pipeline would have flagged it.
Proposal
Automate the stamp as a post-publish workflow step that keeps the evidence gate intact:
- After
dispatcher-publish finishes and the release is published (attestations present), run stamp-dispatcher-pin --tag <released tag> in a workflow job. The tool already verifies the attestation before writing, so the gate stays evidence-based.
- Mirror the result to
.uloop/project-runner-pin.json (byte-identical, check-dispatcher-pin enforces this) and open a chore: PR with the two-file diff. Human review + merge remains the only manual action.
- Add a CI check (or a step in the same workflow) that fails when the newest published
dispatcher-v* stable release is newer than the pinned tag on main, so a skipped stamp is visible instead of silent.
Constraints to respect: minimumDispatcherVersion stays hand-maintained (do not auto-raise it); the pin evolves additively; pre-releases must not be stamped onto main (see docs/dispatcher-pin-release-order.md).
Acceptance
- Publishing a stable dispatcher release produces a pin-stamp PR without manual commands.
- A stale pin (stable dispatcher release newer than the pinned tag) fails CI on
main.
- Documentation in
docs/dispatcher-pin-release-order.md and docs/project-runner-pin.md reflects the automated flow.
Problem
Packages/src/project-runner-pin.jsonresolves which dispatcher releaseinstall.sh,install.ps1, and the Unity Install CLI button download (dispatcherReleaseTag+dispatcherArchiveManifest). Stamping that field is a manual step today: after a dispatcher release is published, someone must rungo run ./cmd/stamp-dispatcher-pin --tag dispatcher-vX.Y.Zincli/release-automation, mirror the file to.uloop/project-runner-pin.json, and open a PR.During the 3.0.0 release this step was missed at first:
dispatcher-v3.0.0was published while the pin still pointed atdispatcher-v3.0.0-beta.31, so a freshinstall.shrun installed a beta dispatcher (which then follows the beta self-update channel forever). It was caught by the post-release install check and fixed in #2461, but nothing in the pipeline would have flagged it.Proposal
Automate the stamp as a post-publish workflow step that keeps the evidence gate intact:
dispatcher-publishfinishes and the release is published (attestations present), runstamp-dispatcher-pin --tag <released tag>in a workflow job. The tool already verifies the attestation before writing, so the gate stays evidence-based..uloop/project-runner-pin.json(byte-identical,check-dispatcher-pinenforces this) and open achore:PR with the two-file diff. Human review + merge remains the only manual action.dispatcher-v*stable release is newer than the pinned tag onmain, so a skipped stamp is visible instead of silent.Constraints to respect:
minimumDispatcherVersionstays hand-maintained (do not auto-raise it); the pin evolves additively; pre-releases must not be stamped ontomain(seedocs/dispatcher-pin-release-order.md).Acceptance
main.docs/dispatcher-pin-release-order.mdanddocs/project-runner-pin.mdreflects the automated flow.