max / makenotwork

Correct the require_all_targets comment: it does not gate a deploy The comment claimed neither pom instance ships without the other. It does not. `require_all_targets` is consulted by `publish`, and a service never publishes, so the flag is inert for pom. The 0.4.1 release demonstrated it: x86_64 installed on the Hetzner box and restarted it while the aarch64 build was still failing its test gate, so production ran 0.4.1 against astra's 0.4.0 until the retry landed. Harmless for a pair of monitors, and exactly what the comment promised would not happen. Wiring it into deploy is not a one-line change: the gate asks that every OTHER target already be green, which for sequential deploys means the first could never go. A real both-or-neither needs a barrier between build and deploy across the matrix.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-07-31 00:01 UTC

Signed with PGP, not checked

Commit: 2c67c7292e4f6dcda08b0007e536c7d8148db20c

Parent: 2b730c5

1 file changed, +11 insertions, -3 deletions

M pom/bento.toml +11 -3

			@@ -23,9 +23,17 @@
23	23		# makes a bare `v0.4.1` ambiguous the day it is created rather than eventually.
24	24		tag_format = "pom-v{version}"
25	25
26		-	# Neither instance ships without the other. pom watches production, and an
27		-	# aarch64 build that quietly failed while x86_64 shipped leaves half the mesh on
28		-	# an old binary with nothing saying so.
	26	+	# NOT the both-or-neither gate it looks like. `require_all_targets` is consulted
	27	+	# by `publish`, and a service never publishes -- it deploys. So this flag does
	28	+	# nothing here today, and the 0.4.1 release proved it: x86_64 installed on the
	29	+	# Hetzner box and restarted it while the aarch64 build was still failing its test
	30	+	# gate, leaving the mesh split across two versions until the retry landed.
	31	+	#
	32	+	# Left on because it is the right intent and costs nothing, but do not read it as
	33	+	# a guarantee. Wiring it into deploy is not a one-line change either: the gate
	34	+	# asks that every OTHER target already be green, which for sequential deploys
	35	+	# means the first one could never go. A real both-or-neither needs a barrier
	36	+	# between build and deploy across the matrix. Tracked as an infra problem.
29	37		require_all_targets = true
30	38
31	39		# Where each target lands. The recipe never names a machine -- it calls