Per-artifact commit-derived versions: pinnable date tags, and no rebuild when nothing changed #238
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: bvandeusen/FabledCurator#238
Reference in New Issue
Block a user
Milestone 313, steps 1–4. Every published artifact now carries a version derived from the commit its own shipped files last changed in — so an image whose source did not move keeps its version, keeps its bytes, and does not rebuild.
What lands
Step 1 (
cf06c81) — one definition per artifact of what it ships.scripts/artifacts.shholds four path sets and derivespaths/revision/version/tagfrom them.tests/test_artifact_paths.pyparses each Dockerfile'sCOPYlines and asserts the sets match, in both directions: too narrow serves stale bytes on a pin (the dangerous one), too wide rebuilds for a change it does not ship.Step 2 (
0c43fa3) — shadow mode, plusfetch-depth: 0on build-ml and build-agent. A depth-1 clone derives a wrong-but-plausible value rather than failing, which is exactly the landmine this milestone exists to remove.Step 3 (
7a20c55) — the pinnable tag. Main builds publish:YYYY.M.Dper artifact. Day precision is deliberate: same-day work is not worth pinning, so a second build the same day replaces the first rather than accumulating a tag nobody would roll back to. Safe only because skip decisions key on the revision, never on this.Step 4 (
609bc82) — reuse instead of rebuild. Each job asks the registry for<image>:r-<revision>; on a hit it skips the build and repoints the channel and date tags at the existing manifest withimagetools create.Fix (
fb2c4d5, #3156).packaging.shwas excluded from the version it derives. Harmless while every push rebuilt web — under step 4 it becomes silent: a new version gets signed by AMO while build-web reuses the image carrying the old XPI. Found while checking the ground under step 5, which is precisely a packaging.sh change.Decisions worth reviewing
weband onlyweb, because web is the only image taking a build-arg (FC_CHANNEL, baked in and reported by/api/extension/manifest). ml and agent take none, which is what lets a merge reuse dev's build instead of rebuilding the agent's CUDA image for bytes that already exist. A test reads the Dockerfiles and fails if that list drifts either way.r-<rev>would point an immutable tag at fresh bytes — rule 145's exact prohibition.Verified on dev
Runs 4704–4709 green. The
fb2c4d5push moved web and the extension but not ml or agent, exercising both paths at once:What this merge itself verifies
The main path has not run yet — it is code-reviewed but unexercised. This merge is its first exercise, and the specific things to watch on the resulting build:
r-<rev>-maindoes not exist yet.:main,:latest,:c-<sha>and the date pin together, from one manifest.Merged with a plain merge commit per rule 153 — squash or rebase would rewrite
%ctand break every derived version in this PR.Every build job now logs the tag, version and revision its artifact would get. Nothing reads them; no `set -e`, and each derivation falls back to UNAVAILABLE, so a broken script cannot fail a build. Same discipline as milestone 271 step 2, which is what made that cutover safe to do in one commit. Also fixes a landmine the plan named but had not checked: build-ml and build-agent were checking out at depth 1. Both now use fetch-depth: 0. That mattered more than it looks. A depth-1 clone sees one commit, so `git log HEAD -- <shipped paths>` either returns that commit's timestamp — plausible, and wrong — or returns nothing. For build-ml on this push it would have returned today's date, because HEAD touches backend/, and nothing downstream would have questioned it. For build-agent it would have returned nothing at all, since no single commit here touches agent/, and artifacts.sh exits non-zero rather than guessing. One direction is silent and one is loud; only the loud one was ever going to get noticed. What to read from the shadow lines over the next few pushes, in order of how badly each would bite: * a push touching the extension must move BOTH the extension and web, because build-web bakes the XPI in. If web does not move, its path set is too narrow and a pinned web image will serve an extension it does not name. * a push touching only agent/ must leave web and ml still. If they move, their sets are too wide and they will rebuild for changes they do not ship. * a docs-only push must move nothing. * dev and main must derive the same values for the same source. Step 3 only lets these values name a tag once those hold.Each main build now also publishes <image>:YYYY.M.D — the date of the commit that artifact's shipped files last changed in. Purely additive; :main, :latest, :c-<sha> and the dev path are untouched, so reverting this commit reverts the behaviour. main push -> :main, :latest, :c-<sha>, :2026.8.27 dev push -> :dev Per artifact, so an image whose files did not change keeps the tag it already had. On this commit the agent reads 2026.7.17 while web and ml read 2026.8.27 — six weeks apart, from one push. Step 4 turns that into not rebuilding it. Day precision, and a second main build the same day replaces the first. Operator's call, and the reasoning is theirs: same-day work is not something worth pinning. A rollback goes to a day, not to the fourth merge of a Tuesday afternoon. It also makes retention mean "the last N days" rather than "the last N pushes". CALVER is computed inside the main branch rather than at the top of the step, and hard-fails when empty. There is no `set -e` here, so an unconditional assignment that failed would have left it empty and published the tag `fabledcurator:` — an invalid name, from a step that still reported success. It is also simply unused on the dev and tag paths. Fixed a stale comment while in this block rather than leaving it for step 7: it claimed release tags carry "no `.N` per family release-posture rule". Rule 148 was amended on 2026-08-24 to REQUIRE the suffix, after the ban caused a same-day tag to be retargeted and a release deleted to make room (note 2813). FC's own tags already carry suffixes; only the comment was asserting the superseded rule. Verified before pushing: the derivation holds across 200 commits of real history — a derived revision always touches its own path set, the version never decreases along any parent->child edge, and web tracks all three extension-only commits in the log. That last one is the direction that would serve stale bytes on a pin.