Paul HittandClaude Opus 5.5
ac57651fd5
The messenger repositories move from gitlab.com/paulhitt to gitlab.com/extant2000. Old web and git URLs redirect; the relay's container image path does not, so docker-compose.yml names the new registry path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.1 KiB
Why this repository pins flamenet-e2e
.e2e-ref is the commit of flamenet-e2e
that the conformance and doc-pages jobs check against.
It exists because a merge in that repository could stop all work in this
one. Both jobs used to clone main at HEAD, deliberately, a relay tested
against a pinned old harness is tested against a pinned old spec, and that
argument still holds. What it missed is that a blocking job coupled to
another repository's HEAD hands that repository a switch labelled "stop
everything here", with nobody told it was thrown.
It was thrown three times in twelve hours (relay#56). Twice it was a stale generated page. The third was a deadlock with no way out from inside either repository:
flamenet-e2ebegan expecting the plaintext message routes to be gone.mainhere still had them, soconformancefailed on every pipeline, including the pipeline for the branch that removes them.- Nothing could go green until that branch merged. It could not merge because nothing could go green.
Breaking it took assembling one branch by hand that satisfied both jobs at once. A pin makes that situation impossible rather than survivable.
Taking an update
One MR, all three parts together:
- Put the new e2e commit in
.e2e-ref. Scripts/build-doc-pages.shand commit the regenerated pages.- Make whatever source change the new conformance suite expects.
Do not do 1 without 2 and 3. The point of the pin is that the bump and
the work it implies land as one reviewable change. Bumping alone just moves
the breakage to main, which is what this file exists to prevent.
Staying honest about drift
The pin is not permission to fall behind. conformance-head and
doc-pages-head run the same checks against e2e's actual HEAD on every
pipeline, and are allow_failure: true, so being behind is loud and
non-blocking. A red advisory job means an update is waiting, not that
anything is broken.
If you find yourself ignoring those two jobs, that is the signal to bump, not the signal to delete them.