max / makeover-build

Release makeover-build through Bento kind = "library" plus the shared publish.rhai, same two-file split as makeover-geometry: the pointer goes in the daemon's topology, the how lives here with the code. Routes 0.1.0 through the preflight gate rather than a direct cargo publish, which is the whole reason the controller exists for an operation crates.io cannot undo.

Author: Max Johnson <me@maxj.phd> · 2026-07-28 23:03 UTC

Signed with PGP, not checked

Commit: fb8c04ff937927326b2cfac160467e0273af6bfb

Parent: 8c1f91d

2 files changed, +55 insertions, -0 deletions

A bento.toml +8

		@@ -1,0 +1,8 @@
1	+	# How Bento releases makeover-build. Lives here rather than in the daemon's config so it is
2	+	# versioned with the code it describes.
3	+
4	+	# A crate, not an app: one publish.rhai rather than a recipe per platform, and
5	+	# the target below names the host that uploads rather than a build matrix.
6	+	kind = "library"
7	+
8	+	targets = ["linux/x86_64"]

A dist/recipes/publish.rhai +47

		@@ -1,0 +1,47 @@
1	+	// Publish this crate to crates.io.
2	+	//
3	+	// A library has no per-platform artifact, so this is the whole release: one
4	+	// recipe, run on whichever host the manifest names.
5	+	//
6	+	// The preflight step is the point of routing this through Bento. crates.io
7	+	// versions can be yanked but never edited, so a wrong repository URL, a
8	+	// missing license, or a duplicate version is permanent the moment it uploads.
9	+	// pter 0.1.0 went out with a dead repository link and could only be corrected
10	+	// by releasing again.
11	+
12	+	let h = build_host();
13	+	let r = repo();
14	+	let v = version();
15	+
16	+	// No pull here. The runner's release preflight has already fetched and run
17	+	// `git checkout v<version>` on every host, then compared `rev-parse HEAD`
18	+	// across them so a release cannot be built from two different commits. That
19	+	// leaves the checkout on the tag, detached. Pulling would move it off the tag
20	+	// onto the branch tip, publishing something other than what was tagged — and on
21	+	// a detached HEAD it just fails, which is how this was found, while publishing
22	+	// makeover 2.1.0 as the first library to go through Bento.
23	+	//
24	+	// So this step asserts the pin instead of re-doing it: HEAD must be exactly a
25	+	// tag, or the release is not coming from where it claims.
26	+	step("checkout");
27	+	sh_ok(h, "cd " + r + " && git describe --exact-match --tags HEAD");
28	+
29	+	// Gate: nothing reaches crates.io from code that fails clippy or its tests. A
30	+	// published version can be yanked but never edited, so this is the last point
31	+	// at which a break is still cheap.
32	+	step("prebuild");
33	+	sh_ok(h, "cd " + r + " && cargo clippy --workspace --all-targets " + feature_flags() + " -- -D warnings");
34	+	sh_ok(h, "cd " + r + " && cargo test --workspace " + feature_flags());
35	+
36	+	step("verify");
37	+	// Credentials are checked here too, and deliberately not passed through Bento:
38	+	// the token stays in cargo's own 0600 store on the publishing host, where cargo
39	+	// finds it. Handing it to a shell command would put it in the process list for
40	+	// the length of the upload, and ops-exec renders env pairs into the shell line.
41	+	// Aborts the run with the specific problems if anything is wrong.
42	+	log(crate_preflight());
43	+	sh_ok(h, "cd " + r + " && cargo publish --dry-run " + feature_flags());
44	+
45	+	step("publish");
46	+	sh_ok(h, "cd " + r + " && cargo publish " + feature_flags());
47	+	log("published " + v + " to crates.io");