Repository navigation
release: one flow, from merge to published release - #1
Merged
Merged
Conversation
The first run took over 25 minutes and the release build was most of it, still going when clippy (2.5 min) and tests (8.7 min) had finished. Two reasons, both by design and both wrong for a pull request: - `[profile.release]` sets `lto = "thin"` and `codegen-units = 1`. One codegen unit means the compiler cannot split a crate into parallel units, and thin LTO then analyses the whole crate graph at link time. That is the correct trade for a binary people download; it is 13 minutes for a smoke check. - Three compiles of the same dependencies in one job: clippy needs them for metadata, tests need a debug build, and release needs a third, entirely separate set of artifacts. Nothing is shared between profiles. So CI keeps fmt, clippy and tests, and the release build moves to where it belongs: a release workflow on a tag, which can afford to be slow. The debug build that replaces it costs seconds after `cargo test` and still catches a binary that does not link. Also `--locked` (no silent lockfile or registry drift mid-run) and `save-if: main` so pull requests read the cache instead of each writing one.
Replaces the separate check-only workflow with a single pipeline: on every push to main the checks run, the next version is worked out from the conventional commit messages since the last tag, that version is built, and a GitHub release is created with the binary attached and notes grouped by commit type. Pull requests run the checks and nothing else. Decisions worth spelling out: - **Version from commit messages, not a bot PR.** Squash merging keeps the PR title as the commit subject, so `feat:`, `fix:` and `feat!:` are already the history. `.github/scripts/next-release.py` reads them and applies the rules: pre-1.0 a breaking change and a feature both bump the minor (0.x promises no compatibility, so 1.0.0 on week two is a trap), fixes bump the patch, and a merge that only contains chores or docs produces no release at all. - **The bump is committed with `[skip ci]`.** The tag has to agree with Cargo.toml, so the version is written in, committed and pushed; `[skip ci]` stops that push from starting the workflow again. - **The version is written before the build**, so the binary and the tag cannot disagree. - **Linux only for now.** macOS runners cost ten times the minutes on a private repository and Windows would need `config.rs` fixed first: it falls back to `$HOME/.config`, which is unset there, so state would land in the current directory. Adding a platform is one matrix line when those are sorted. - **`--locked` stays on the checks**, but the release build runs unlocked: the version bump rewrites the crate's own entry in Cargo.lock. Also renames the crate from `kubetitan-mvp` to `kubetitan`. The artifact is `kubetitan-linux-x86_64.tar.gz` containing a binary called `kubetitan`, and "mvp" in a released binary name is a promise nobody wants to keep. Verified by rehearsal, not by reading the YAML: nine version cases pass (`release-tests.sh`), the notes group correctly, and the packaging steps run against a stub binary producing the archive and its SHA256SUMS.
MihaiNueleanu
changed the title
Contributor
Author
|
Verification on the renamed crate, locally, with the same flags CI uses: So |
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
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.
One pipeline: merge to main → checks → version from conventional commits → release build → GitHub release with the binary attached and notes generated.
ci.yamlis deleted;release.yamlreplaces it. Pull requests run the checks only.How a release happens
check: fmt, clippy-D warnings, tests (--locked).release(main only): reads the current version fromCargo.toml, then.github/scripts/next-release.pylooks at the commit subjects since the lastv*tag and decides the bump.Cargo.tomlbefore the build, so binary and tag agree.cargo build --release, packaged askubetitan-linux-x86_64.tar.gzwithLICENSE,README.mdand aSHA256SUMS.chore(release): vX.Y.Z [skip ci](the[skip ci]is what stops the push restarting the workflow), thengh release createtags that commit and attaches the archives.Version rules (and why)
feat:, orfeat!:,fix!:while0.x0.1.0 → 0.2.0)fix:,perf:, anything unreleased0.1.0 → 0.1.1)chore:,docs:,ci:,test:Cargo.tomlPre-1.0, breaking and feature both bump the minor on purpose:
0.xpromises no compatibility, so burning 1.0.0 in week two just means arriving at 7.0.0 with no users.Verified by rehearsal, not by reading YAML
Features,Fixes,Chores).kubetitan,LICENSE,README.md;SHA256SUMSmatches.Scope note
Crate renamed
kubetitan-mvp→kubetitan, because the artifact would otherwise be a binary calledkubetitan-mvpand "mvp" is not a promise you want in a download.Linux only for now: macOS runners cost 10× minutes on a private repo, and Windows needs
config.rsfixed first (it falls back to$HOME/.config, unset there, so state would land in the working directory). Adding a platform is one matrix line once that is done.