Loading
Draft: Pin chassis release builds to readable release tags
Summary
Stacked on !196 (merged) (targets its branch; retarget to main after !196 (merged) merges). Implements part A of #110, readable release pins.
!196 (merged) pins a release bench to the commit its release tag points at. This MR replaces that with the tag itself, so adopters see vX.Y.Z instead of a pseudo-version.
release:goreleaserrunsscripts/tag-chassis-go.shfirst. It tags the release commitchassis/go/vX.Y.Zthrough the GitLab API. A Go module in a subdirectory resolves a version only through a tag prefixed with its directory.- If the tag already exists, it must point at the same commit, or the script fails. A retry is idempotent.
- A release
benchrunsgo get .../chassis/go@vX.Y.Z, so adopters'go.modshowsvX.Y.Z. Rust getstag = "vX.Y.Z". BENCH_COMMITis removed from.goreleaser.yml.- GoReleaser gets
GORELEASER_CURRENT_TAG=$CI_COMMIT_TAGandGORELEASER_PREVIOUS_TAGfromgit describe --match 'v[0-9]*'. The chassis tag on the same commit is never its version or changelog boundary. - A workflow rule skips pipelines for
chassis/tag pushes. The release job only runs on tags matching^v\d+\.\d+\.\d+$, so chassis tags don't trigger a release. docs/processes/releasing.mdanddocs/design/chassis-libraries.mdare updated.
Testing
- Unit tests cover the tag-form Rust dependency and release source selection.
- Checked the tag script's lookup parsing against the existing
v0.2.2tag.
Not tested: tag creation and the tagged go get / cargo fetch. Only a real release can exercise them, or a throwaway pre-release tag such as v0.3.0-rc.1 plus chassis/go/v0.3.0-rc.1. The Go proxy would cache that one permanently.
Open question: when should this merge? Before the next release, or after one release has shipped with the commit pin from !196 (merged)?
Reviewer checklist
- Reviewed the changes.
- Change matches the described intent and stays in scope.
- Milestone and labels are applied.
- CI is green.
Related issue
Closes #110