Commit Graph

2 Commits

Author SHA1 Message Date
admin c6a567122e v0.316.4: build.sh refuses a push from a dirty or unpushed tree
gates / gates (push) Failing after 50s
An admission and its mechanism. Building 0.316.3 published another session's work: the shared
DooPlex clone held 31 uncommitted files, and the build directory's build.sh is a symlink into that
clone's WORKING COPY — which predated the FELHOM_REPO_DIR override, so the override was ignored and
the build copied the shared tree. The banner printed 'Commit: 0225255' and no 'Repo:' line; the
evidence was on screen and the image was already pushed. Nobody deployed it, which is luck, not a
control.

The clean-tree rule has been a sentence in a runbook all along. A rule without a mechanism is a
wish, so it is now two questions the build asks and refuses on: is every tracked file committed,
and is HEAD what origin/main has. A directory that is not a git checkout is refused too — a build
whose source cannot be identified is not reproducible.

Four new cases in the test (ten in total), each driving the real script; red-proved by deleting the
gate, which fails all four.

0.316.3 must never be deployed. It is not re-pushed or deleted: a version number is pushed once,
and that applies to a number I spoiled.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0117kRTSgs3rJWUFGxyoWN6Y
2026-10-15 21:09:38 +02:00
admin 9cc7ffcf3b A version number is pushed once, and every build addresses its CSS differently
gates / gates (push) Failing after 44s
MEASURED FIRST (audits/app-page-2026-10-15b/P0/VERDICT.md). The tab bar rendered unstyled through
the public address for one reason, and it was not the box: exactly one guest runs 0.315.0 and it
runs the registry's current digest (8887343011d6, identical to the registry's). The floor is still
0.314.0, so nothing else could have taken it.

What it was, in four measured facts:
  1. the stylesheet URL is /static/style.css?v={{.Version}} -> ?v=0.315.0 for all THREE different
     0.315.0 builds (e66d466, fe0228c, db52f5a), the first of which had no .app-tabs rules at all;
  2. the origin sends NO validator at all (ETag present = 0, Last-Modified present = 0), so a
     cached copy cannot be revalidated - it can only expire;
  3. Cloudflare caches that URL (cf-cache-status HIT, age climbing) and rewrites the browser TTL
     from the origin's 3600 to 14400 - four hours;
  4. the session's first request returned cf-cache-status EXPIRED, which only happens when the edge
     holds an entry that has aged out.

Origin, edge and box now agree byte-for-byte. The stale object itself is gone - that first probe
forced its revalidation - and the REPORT says so rather than claiming a HIT nobody can reproduce.

THE FIX IS IN TWO PARTS, NEITHER OF WHICH IS PURGING A CACHE:

build.sh refuses to push a version that already exists, before building, for --push and
--multiarch. A registry that cannot be asked is a refusal too: proving the tag is new is the point,
and "I could not ask" is not that proof. Local builds are untouched - reusing a version while
iterating is normal. scripts/test_build_push_once.sh drives the real build.sh with a fake docker on
PATH over six cases; red-proved twice (check deleted -> a present tag builds and pushes; an
unreachable registry treated as absent -> two cases fail).

assetTag() now hashes version + GitCommit + BuildTime, and EVERY shell's stylesheet link uses it
(seven of the nine asked for ?v={{.Version}}; only the two stranger-facing share pages already had
it). It stays opaque and 8 hex, because the share pages are reached by a capability URL and naming
the build to whoever holds one is a gift to somebody hunting a known fault. Cache-Control is
unchanged: the new address is the fix, not a shorter cache.

The parity harness normalises the asset tag on BOTH sides of the comparison, as it already does for
the per-session CSRF token, so all 148 fixtures stay byte-identical on disk and stop depending on
which build rendered them. The same normalisation is applied at the second comparison site in
i18n_wiring_test.go, which had the same assumption.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0117kRTSgs3rJWUFGxyoWN6Y
2026-10-15 20:08:01 +02:00