docs: true up the tag scheme against what the pipeline publishes (318 step 9)
CI / lint (push) Successful in 3s
Build images / sign-extension (push) Successful in 4s
Build images / build-ml (push) Successful in 4s
CI / extension-version (push) Successful in 3s
Build images / build-agent (push) Successful in 4s
Build images / build-web (push) Successful in 5s
CI / frontend-build (push) Successful in 22s
extension / lint (push) Successful in 30s
CI / backend-lint-and-test (push) Successful in 48s
CI / integration (push) Successful in 3m57s
extension / lint (pull_request) Successful in 28s

A doc describing a tag scheme the pipeline stopped using is worse than no
doc — it is a confident wrong answer, and #3159 named it as the drift that
had just bitten rule 148.

build.yml (each edit ×3, once per build job):

* The derived-values block claimed three values including a `tag`
  subcommand that no longer exists, and said "on dev the date tag is
  computed nowhere else". There are two values and no date tag.
* The BASE-IMAGE FRESHNESS paragraph argued from a pin that no longer
  exists — "a date tag has to keep serving the bytes it served
  (fabledcurator:2026.7.17 still resolves to July's image)". Milestone 318
  removed the argument's premise rather than answering it: with no version
  tags there is no immutable name a refresh could contradict, and rule 145
  already allows a moving tag to be republished. Deleted the argument,
  kept a line saying why there is nothing to argue about (#3159's phrasing:
  the workflow becomes obviously correct instead of carefully correct).
* The repoint comment said ":c-<sha> and the date pin". There is no date pin.
* "its set is too narrow — the direction that serves stale bytes on a pin"
  now names the failure that actually exists: the reuse check hits and the
  channel serves a web image bundling the previous XPI (#3156).

README gains a "Versions and tags" section — the three tags, why there is
no fourth, and the fact that with no registry name carrying it, the
instance's own report is the only answer to "which build is this?". Also
fixes two stale claims: three workflows (four since release.yml) and "AMO
signing runs on main only", which has been false since milestone 271
step 6 signed on both channels.

ci-requirements.md was missing milestones 313 and 318 entirely: no
artifacts.sh, no label-keyed reuse, no FC_VERSION. Added those, plus the
#3156/#3202 membership test (can changing this file change the published
bytes — not is it copied in), and corrected packaging.sh's "two consumers"
to three now that artifacts.sh reads it.

docker-compose.yml needed nothing — it names `:dev` directly and never
offered a pin target.

Note #3127 and rule 145's relation notes are updated in Scribe.
This commit is contained in:
2026-08-29 00:09:52 -04:00
parent a3071a7549
commit d38585ed94
3 changed files with 159 additions and 86 deletions
+54 -59
View File
@@ -116,8 +116,9 @@ jobs:
# STILL. If web moves, its path set is too wide.
# * a push touching only docs moves nothing.
# * a push touching the extension moves the extension AND web, since
# web bakes in the XPI. If web does not move, its set is too narrow
# the direction that serves stale bytes on a pin.
# web bakes in the XPI. If web does not move, its set is too narrow:
# the reuse check hits, and the channel serves a web image bundling
# the PREVIOUS XPI while the freshly signed one is orphaned (#3156).
# * dev and main derive the same values for the same source.
- name: Shadow — derived artifact version (informational)
run: |
@@ -345,12 +346,11 @@ jobs:
fetch-depth: 0
# --- derived values, one line (milestone 313) ------------------------
# These stopped being shadow output at step 3: `tag` is published on
# main and `revision` decides whether the build below runs at all. This
# step prints all three anyway, because the load-bearing steps each
# print only the one they use, and on dev the date tag is computed
# nowhere else. When a build is skipped or a pin looks wrong, this is
# the line that says what the commit derived.
# These stopped being shadow output at step 3. `revision` decides
# whether the build below runs at all and `version` is what the image
# reports about itself; the load-bearing steps each print only the one
# they use, so this is the only place the pair appears together. When a
# build is skipped, this is the line that says what the commit derived.
#
# Still diagnostic, so it still must not fail the build — no `set -e`,
# and every derivation falls back to UNAVAILABLE. A broken echo must
@@ -361,8 +361,9 @@ jobs:
# STILL. If web moves, its path set is too wide.
# * a push touching only docs moves nothing.
# * a push touching the extension moves the extension AND web, since
# web bakes in the XPI. If web does not move, its set is too narrow
# the direction that serves stale bytes on a pin.
# web bakes in the XPI. If web does not move, its set is too narrow:
# the reuse check hits, and the channel serves a web image bundling
# the PREVIOUS XPI while the freshly signed one is orphaned (#3156).
# * dev and main derive the same values for the same source.
- name: Report the derived artifact version
run: |
@@ -463,15 +464,13 @@ jobs:
# that skips a build that was actually needed; the worst case is paying
# for a build we could have avoided.
#
# BASE-IMAGE FRESHNESS, decided rather than left implicit: an artifact
# whose source stops moving stops picking up base-image updates under
# its pinned tag. That is what a pin MEANS — a date tag has to keep
# serving the bytes it served (fabledcurator:2026.7.17 still
# resolves to July's image), or it is not a pin — and family rule
# 145 already says where the refresh goes instead: a rebuild with
# different contents publishes only the MOVING tag, never the immutable
# one. A scheduled channel-only refresh is tracked separately (#3154);
# it does not belong in the push path.
# BASE-IMAGE FRESHNESS: an artifact whose source stops moving stops
# picking up base-image updates. Milestone 318 removed the argument this
# used to need rather than answering it — with no version tags there is
# no immutable name a refresh could contradict, and rule 145 already
# allows a rebuild with different contents to republish a MOVING tag.
# So a refresh is just a build. A scheduled channel-only one is tracked
# separately (#3154); it does not belong in the push path.
- name: Is this content already published?
id: reuse
env:
@@ -624,8 +623,8 @@ jobs:
# Registry-side manifest copy: no layer transfer, no local daemon, no
# rebuild. Each -t becomes another reference to the SAME manifest the
# channel tag already holds, so :c-<sha> and the date pin are
# byte-identical to what is published rather than a lookalike rebuild.
# channel tag already holds, so :c-<sha> is byte-identical to what is
# published rather than a lookalike rebuild.
#
# Runs on EVERY reuse, which is what keeps family rule 146 true: a
# rolling channel refreshes itself, so skipping a build must never mean
@@ -691,12 +690,11 @@ jobs:
fetch-depth: 0
# --- derived values, one line (milestone 313) ------------------------
# These stopped being shadow output at step 3: `tag` is published on
# main and `revision` decides whether the build below runs at all. This
# step prints all three anyway, because the load-bearing steps each
# print only the one they use, and on dev the date tag is computed
# nowhere else. When a build is skipped or a pin looks wrong, this is
# the line that says what the commit derived.
# These stopped being shadow output at step 3. `revision` decides
# whether the build below runs at all and `version` is what the image
# reports about itself; the load-bearing steps each print only the one
# they use, so this is the only place the pair appears together. When a
# build is skipped, this is the line that says what the commit derived.
#
# Still diagnostic, so it still must not fail the build — no `set -e`,
# and every derivation falls back to UNAVAILABLE. A broken echo must
@@ -707,8 +705,9 @@ jobs:
# STILL. If web moves, its path set is too wide.
# * a push touching only docs moves nothing.
# * a push touching the extension moves the extension AND web, since
# web bakes in the XPI. If web does not move, its set is too narrow
# the direction that serves stale bytes on a pin.
# web bakes in the XPI. If web does not move, its set is too narrow:
# the reuse check hits, and the channel serves a web image bundling
# the PREVIOUS XPI while the freshly signed one is orphaned (#3156).
# * dev and main derive the same values for the same source.
- name: Report the derived artifact version
run: |
@@ -770,15 +769,13 @@ jobs:
# that skips a build that was actually needed; the worst case is paying
# for a build we could have avoided.
#
# BASE-IMAGE FRESHNESS, decided rather than left implicit: an artifact
# whose source stops moving stops picking up base-image updates under
# its pinned tag. That is what a pin MEANS — a date tag has to keep
# serving the bytes it served (fabledcurator-ml:2026.7.17 still
# resolves to July's image), or it is not a pin — and family rule
# 145 already says where the refresh goes instead: a rebuild with
# different contents publishes only the MOVING tag, never the immutable
# one. A scheduled channel-only refresh is tracked separately (#3154);
# it does not belong in the push path.
# BASE-IMAGE FRESHNESS: an artifact whose source stops moving stops
# picking up base-image updates. Milestone 318 removed the argument this
# used to need rather than answering it — with no version tags there is
# no immutable name a refresh could contradict, and rule 145 already
# allows a rebuild with different contents to republish a MOVING tag.
# So a refresh is just a build. A scheduled channel-only one is tracked
# separately (#3154); it does not belong in the push path.
- name: Is this content already published?
id: reuse
env:
@@ -845,8 +842,8 @@ jobs:
# Registry-side manifest copy: no layer transfer, no local daemon, no
# rebuild. Each -t becomes another reference to the SAME manifest the
# channel tag already holds, so :c-<sha> and the date pin are
# byte-identical to what is published rather than a lookalike rebuild.
# channel tag already holds, so :c-<sha> is byte-identical to what is
# published rather than a lookalike rebuild.
#
# Runs on EVERY reuse, which is what keeps family rule 146 true: a
# rolling channel refreshes itself, so skipping a build must never mean
@@ -915,12 +912,11 @@ jobs:
fetch-depth: 0
# --- derived values, one line (milestone 313) ------------------------
# These stopped being shadow output at step 3: `tag` is published on
# main and `revision` decides whether the build below runs at all. This
# step prints all three anyway, because the load-bearing steps each
# print only the one they use, and on dev the date tag is computed
# nowhere else. When a build is skipped or a pin looks wrong, this is
# the line that says what the commit derived.
# These stopped being shadow output at step 3. `revision` decides
# whether the build below runs at all and `version` is what the image
# reports about itself; the load-bearing steps each print only the one
# they use, so this is the only place the pair appears together. When a
# build is skipped, this is the line that says what the commit derived.
#
# Still diagnostic, so it still must not fail the build — no `set -e`,
# and every derivation falls back to UNAVAILABLE. A broken echo must
@@ -931,8 +927,9 @@ jobs:
# STILL. If web moves, its path set is too wide.
# * a push touching only docs moves nothing.
# * a push touching the extension moves the extension AND web, since
# web bakes in the XPI. If web does not move, its set is too narrow
# the direction that serves stale bytes on a pin.
# web bakes in the XPI. If web does not move, its set is too narrow:
# the reuse check hits, and the channel serves a web image bundling
# the PREVIOUS XPI while the freshly signed one is orphaned (#3156).
# * dev and main derive the same values for the same source.
- name: Report the derived artifact version
run: |
@@ -989,15 +986,13 @@ jobs:
# that skips a build that was actually needed; the worst case is paying
# for a build we could have avoided.
#
# BASE-IMAGE FRESHNESS, decided rather than left implicit: an artifact
# whose source stops moving stops picking up base-image updates under
# its pinned tag. That is what a pin MEANS — a date tag has to keep
# serving the bytes it served (fabledcurator-agent:2026.7.17 still
# resolves to July's image), or it is not a pin — and family rule
# 145 already says where the refresh goes instead: a rebuild with
# different contents publishes only the MOVING tag, never the immutable
# one. A scheduled channel-only refresh is tracked separately (#3154);
# it does not belong in the push path.
# BASE-IMAGE FRESHNESS: an artifact whose source stops moving stops
# picking up base-image updates. Milestone 318 removed the argument this
# used to need rather than answering it — with no version tags there is
# no immutable name a refresh could contradict, and rule 145 already
# allows a rebuild with different contents to republish a MOVING tag.
# So a refresh is just a build. A scheduled channel-only one is tracked
# separately (#3154); it does not belong in the push path.
- name: Is this content already published?
id: reuse
env:
@@ -1064,8 +1059,8 @@ jobs:
# Registry-side manifest copy: no layer transfer, no local daemon, no
# rebuild. Each -t becomes another reference to the SAME manifest the
# channel tag already holds, so :c-<sha> and the date pin are
# byte-identical to what is published rather than a lookalike rebuild.
# channel tag already holds, so :c-<sha> is byte-identical to what is
# published rather than a lookalike rebuild.
#
# Runs on EVERY reuse, which is what keeps family rule 146 true: a
# rolling channel refreshes itself, so skipping a build must never mean