chore(binjovi): retire three spent tombstones and the gun one of them held

sean commented

2026-09-10 10:34:37 +00:00

Owner

All three tombstones did their work and then failed forever, reading absence as an error. Every target is NotFound and each Job has zero successes. The class tombstone was also a loaded gun: it waits for the Deployment to name binjovi-buildkit-cache-128k and then deletes binjovi-buildkit-cache, which is the live 100 GiB cache, already on zfs-nvme-128k under its original name. The rename never happened, so the only thing between a live cache and deletion was a condition the tree no longer declares. The cache guard now refuses that rename too. Guards move with the files rather than vanishing. Six controls confirmed red; full tests/check.sh passes. https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

sean added 1 commit

2026-09-10 10:34:37 +00:00

chore(binjovi): retire three spent tombstones and the gun one of them held

binjovi/ci Binjovi failed the frozen plan

Details

04d6a9c534

All three tombstones did their work and then failed forever, because they
read absence as an error instead of success. Every target is gone from the
cluster, and each Job has zero successes:

  binjovi-buildkit-release-cache-v2-retire-v2   4 failures
  buildkit-cache-class-retire                   3 failures
  olly-protection-retire-v1                     4 failures

The v2 tombstone waits on workflows/binjovi-buildkit-admission and
binjovi-builds/binjovi-buildkit-release, and on their -cache-v2 claims. All
four are NotFound, so `curl --fail` gives `curl: (22)` and the Job fails.
The Olly tombstone has the same shape: it removed the stale branch and tag
protections, and no ForgejoBranchProtection or ForgejoTagProtection for Olly
remains. Its own header said "AFTER IT RUNS this file is one `git rm`".

THE CLASS TOMBSTONE WAS ALSO A LOADED GUN. It waits for the Deployment to
name binjovi-buildkit-cache-128k, and then DELETES binjovi-buildkit-cache.
That second name is the live 100 GiB cache, Bound and already on
zfs-nvme-128k under its original name, because the rename the tombstone was
written for never happened. The tree declares no -128k claim at
buildkit.yaml:223, and two of its three Deployments no longer exist. So the
only thing between a live cache and deletion was a condition the tree no
longer declares. The cache guard now also refuses that rename, so the
premise this deletion rests on cannot change quietly.

WHAT MOVES WITH THEM. binjovi.sh compares the resource list exactly, so a
returning entry fails there. binjovi-buildkit-cache-retirement.sh adopts the
absence of both buildkit files and the refusal of the rename.
binjovi-branch-protections.sh refutes the Olly entry and file. The dedicated
v2 guard goes, and so does its caller in check.sh. A comment in
pipelines-retirement/buildkit-tombstone.yaml cited a file this commit
deletes, so it now cites the tombstone that remains.

NOT `refute -e PATH`. refute wraps grep, so `refute -e PATH` runs
`grep -e PATH` with no file and reads stdin. Written that way first, it hung
a test run for 32 minutes on a blocked read, and with stdin closed it would
have passed while reading nothing -- the vacuous pass refute.sh exists to
prevent. `test ! -e` is the fleet idiom and is used here.

Six controls confirm the new assertions fail: each file restored, the class
entry rendered again, the claim renamed, and the Olly file restored. The full
tests/check.sh passes.

Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

sean referenced this pull request

2026-09-10 11:05:08 +00:00

chore(binjovi): retire three spent tombstones and the gun one of them held #552

sean closed this pull request

2026-09-10 11:11:18 +00:00

binjovi/ci Binjovi failed the frozen plan

Details

Pull request closed

Please reopen this pull request to perform a merge.

Rows
Columns

chore(binjovi): retire three spent tombstones and the gun one of them held #549

Pull request closed