ludic/changes/release-ci.md
Orkuncakilkaya d41de1f7c9 ci(release): publish releases from a tag, not from a laptop
There was no release workflow. Artifacts were built by `x release --publish` on
whatever machine the maintainer was sitting at, from whatever happened to be in
bin/, with no checksums and nothing proving the tagged tree passed its tests.

Pushing a v* tag now publishes. The workflow builds the toolchain from the IR
seed, runs `x test`, `x test-tools` and `x bootstrap-cfree` against the tagged
tree, and only then creates the Forgejo release. It refuses to publish when the
tag and VERSION disagree, or when CHANGELOG.md has no section for that version.

`x publish [vX.Y.Z]` is the command behind it and runs locally too. It builds
dist/ — a source tarball from the tag, this host's toolchain, and a SHA256SUMS
covering both — and takes the release notes from that version's CHANGELOG
section, so notes and changelog cannot drift. It only adds assets the release
is missing, which is how a macOS build gets attached to a Linux-built release.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 01:48:01 +03:00

14 lines
877 B
Markdown

bump: minor
type: ci
Releases are published by CI from a tag instead of by hand from a laptop. The
new `release` workflow triggers on a `v*` tag, builds the toolchain from the IR
seed, runs `x test`, `x test-tools` and `x bootstrap-cfree` against the tagged
tree, and only then creates the Forgejo release. It refuses to publish when the
tag and `VERSION` disagree or `CHANGELOG.md` has no section for that version.
`x publish [vX.Y.Z]` is the command behind it and works locally too: it builds
`dist/` (a source tarball from the tag, this host's toolchain, and a
`SHA256SUMS` covering both — releases previously shipped no checksums) and takes
the release notes from that version's `CHANGELOG.md` section, so the notes and
the changelog cannot drift. Re-running it only adds assets the release is
missing, which is how a macOS build gets attached to a Linux-built release.