max / alloy

Check the shop remote has refs before building from it For several days no image could build: shop was registered on makenot.work but had never been pushed, so the URL served zero refs and cargo answered `revspec '07fb4e70...' not found`, which reads as a bad SHA and sends you to check the revision. The revision was fine. The remote was empty, and an empty repo is not an error to git, so nothing downstream noticed. The push has since landed, so this is a guard rather than a fix. It counts refs, which is what separates a published repo from a merely named one, and costs one ls-remote against a step that otherwise runs for twenty minutes. It deliberately does not try to prove SHOP_REV itself is present. ls-remote lists ref tips, a deliberate pin normally sits below one, and makenot.work refuses unadvertised objects, so a direct fetch of a non-tip rev fails even when the commit is there. A non-tip rev is reported and left to cargo, which resolves it from history.

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

Author: Max Johnson <me@maxj.phd> · 2026-08-05 17:58 UTC

Signed with PGP, not checked

Commit: 992b599aae6c16187194ff8a7939a414c57571e8

Parent: 4f363dc

1 file changed, +36 insertions, -0 deletions

M Containerfile +36

			@@ -81,6 +81,42 @@
81	81		# instead of rebuilding a terminal that did not change. Moving it below the
82	82		# `COPY crates/` would defeat the dependency-cache split that follows.
83	83		ARG SHOP_REV=07fb4e70fb98f2965fd9e37e59fc221209ab837d
	84	+
	85	+	# Does the remote have anything to build from, before anything expensive runs.
	86	+	#
	87	+	# A guard against a state this image was actually in for several days. shop was
	88	+	# registered and listed on makenot.work but had never received a push, because
	89	+	# of the mnw-cli receive-pack deadlock, so the URL served zero refs and every
	90	+	# build died at this step. `cargo install` said `revspec '07fb4e70...' not
	91	+	# found`, which reads as a bad SHA and sends you to check the revision. The
	92	+	# revision was fine. The remote was empty. Fixed since: the push landed and the
	93	+	# remote carries main.
	94	+	#
	95	+	# An empty repo is not an error to git. `ls-remote` on one exits 0 and prints
	96	+	# nothing, which is why nothing downstream caught it, while a genuinely absent
	97	+	# repo fails loudly on its own. So counting refs is the check that separates
	98	+	# "published" from merely "named", and it is cheap enough to keep forever.
	99	+	#
	100	+	# What this does NOT prove is that ${SHOP_REV} is in the remote. Reachability of
	101	+	# an arbitrary commit is not a question the wire protocol answers: ls-remote
	102	+	# lists ref tips, a pin is allowed to point below one, and makenot.work refuses
	103	+	# unadvertised objects, so a direct fetch of a non-tip rev fails even when the
	104	+	# commit is present. The pin is normally an ancestor of main rather than its
	105	+	# tip, which is the ordinary state of a deliberate pin and not a fault. So a
	106	+	# non-tip rev is reported and left to cargo, which clones and resolves it from
	107	+	# history, rather than failed here on evidence that cannot support it.
	108	+	RUN set -eu; \
	109	+	url=https://makenot.work/git/max/shop.git; \
	110	+	refs=$(git ls-remote "$url" 2>/dev/null) \
	111	+	\|\| { echo "cannot reach $url to check SHOP_REV" >&2; exit 1; }; \
	112	+	[ -n "$refs" ] \
	113	+	\|\| { echo "$url serves zero refs, so no revision can resolve. shop is named on the server but nothing has been pushed to it. See GoingsOn alloy problem 49732815 for the last time this happened." >&2; exit 1; }; \
	114	+	if echo "$refs" \| grep -q "^${SHOP_REV}"; then \
	115	+	echo "SHOP_REV ${SHOP_REV} is a ref tip on the remote"; \
	116	+	else \
	117	+	echo "SHOP_REV ${SHOP_REV} is not a ref tip; it may still be reachable, leaving it to cargo"; \
	118	+	fi
	119	+
84	120		RUN cargo install \
85	121		--git https://makenot.work/git/max/shop.git \
86	122		--rev "${SHOP_REV}" \