chore(retire): remove the spent hello-lib tombstone, and let the directory prune #600

Merged

binjovi-bot merged 1 commit from chore/retire-hello-lib-tombstone into trunk 2026-09-10 20:34:50 +00:00

Conversation 0 Commits 1 Files changed 4 +107 -455

sean commented 2026-09-10 20:27:53 +00:00

Owner

Copy link

sean/hello-lib is gone. The Job's last run converged on its own:

ForgejoPushMirror/hello-lib already absent
ForgejoRepository/hello-lib already absent
sean/hello-lib already gone; nothing to destroy
sean/hello-lib is gone; hello-lib retirement complete

forgejorepository/hello-lib	NotFound
forgejopushmirror/hello-lib	NotFound
GET /repos/sean/hello-lib	404
repositories	44 → 43, sean/hello-lib the only difference

The git rm would have left three new orphans

Every tombstone says "AFTER IT RUNS this file is one git rm". This Kustomization shipped prune: false, which makes that promise false.

A tombstone is a Job plus the RBAC that fences it. The Job carries ttlSecondsAfterFinished and removes itself. The ServiceAccount, Role and RoleBinding have no TTL. Under prune: false a git rm stops Flux managing those three and deletes nothing — so the cure leaves behind exactly the disease it was written to treat: undeclared objects that no guard in this repository can see.

The stated reason for prune: false does not hold

prune: false — each Job is one-shot and its own delete on TTL must not be read as drift and re-applied forever.

Prune does not govern that. Prune governs what happens to an object removed from the tree. While the file is present Flux re-applies it every reconcile whatever prune says, so a Job that TTL deleted comes back either way. Removing the file is the only thing that stops the cycle — and 029c342c is the post-mortem of three tombstones that ran forever because nobody did.

So

• prune: true. Nothing in this directory is ever meant to outlive its run, which is what makes prune the safe setting here rather than the dangerous one. The blast radius is only what this Kustomization created.
• The tombstone is removed and the directory left empty. It stays registered because retirement recurs and the next tombstone lands here.

Guard

tests/hello-lib-retired.sh was a fence while the tombstone existed. It now holds the two things that outlive it:

1. Nothing declares hello-lib. No executable line in kubernetes/ may name it again — comments keep the history.
2. The spent tombstone is gone, and its directory prunes.

Four mutations confirmed red: prune turned off, the tombstone put back, the management grant restored, and the gitmirror re-listed. prune is checked as a value, not as the presence of the word.

https://claude.ai/code/session_01TdW5FSvRJW8CtGnpd29Xp8

`sean/hello-lib` is gone. The Job's last run converged on its own: ``` ForgejoPushMirror/hello-lib already absent ForgejoRepository/hello-lib already absent sean/hello-lib already gone; nothing to destroy sean/hello-lib is gone; hello-lib retirement complete ``` | | | |---|---| | `forgejorepository/hello-lib` | NotFound | | `forgejopushmirror/hello-lib` | NotFound | | `GET /repos/sean/hello-lib` | 404 | | repositories | 44 → 43, `sean/hello-lib` the only difference | ## The `git rm` would have left three new orphans Every tombstone says *"AFTER IT RUNS this file is one `git rm`"*. This Kustomization shipped `prune: false`, which makes that promise false. A tombstone is **a Job plus the RBAC that fences it**. The Job carries `ttlSecondsAfterFinished` and removes itself. The ServiceAccount, Role and RoleBinding have no TTL. Under `prune: false` a `git rm` stops Flux *managing* those three and deletes nothing — so the cure leaves behind exactly the disease it was written to treat: undeclared objects that no guard in this repository can see. ## The stated reason for `prune: false` does not hold > prune: false — each Job is one-shot and its own delete on TTL must not be read as drift and re-applied forever. Prune does not govern that. Prune governs what happens to an object **removed from the tree**. While the file is present Flux re-applies it every reconcile whatever prune says, so a Job that TTL deleted comes back either way. Removing the file is the only thing that stops the cycle — and `029c342c` is the post-mortem of three tombstones that ran forever because nobody did. ## So - `prune: true`. Nothing in this directory is ever meant to outlive its run, which is what makes prune the safe setting here rather than the dangerous one. The blast radius is only what this Kustomization created. - The tombstone is removed and the directory left **empty**. It stays registered because retirement recurs and the next tombstone lands here. ## Guard `tests/hello-lib-retired.sh` was a fence while the tombstone existed. It now holds the two things that outlive it: 1. **Nothing declares hello-lib.** No executable line in `kubernetes/` may name it again — comments keep the history. 2. **The spent tombstone is gone, and its directory prunes.** Four mutations confirmed red: prune turned off, the tombstone put back, the management grant restored, and the gitmirror re-listed. `prune` is checked as a *value*, not as the presence of the word. https://claude.ai/code/session_01TdW5FSvRJW8CtGnpd29Xp8

sean added 1 commit 2026-09-10 20:27:53 +00:00

chore(retire): remove the spent hello-lib tombstone, and let the directory prune ... 868582da6c

sean/hello-lib is gone. The Job's last run reported "sean/hello-lib is gone;
hello-lib retirement complete", and the end state is verified: both CRs NotFound,
GET /repos/sean/hello-lib answers 404, and the repository set went 44 -> 43 with
sean/hello-lib the only difference.

Every tombstone says "AFTER IT RUNS this file is one `git rm`". Doing that would
have left three new orphans, because this Kustomization shipped with
prune: false.

A tombstone is a Job plus the RBAC that fences it. The Job carries
ttlSecondsAfterFinished and removes itself. The ServiceAccount, Role and
RoleBinding have no TTL. Under prune: false a `git rm` stops Flux MANAGING them
and deletes nothing, so the cure would leave behind the same disease it was
written to treat -- undeclared objects that no guard in this repository can see.

The stated reason for prune: false does not hold either. It read "a Job's own
delete on TTL must not be read as drift and re-applied forever". Prune does not
govern that. Prune governs what happens to an object REMOVED FROM THE TREE. While
the file is present Flux re-applies it every reconcile whatever prune says, so a
Job that TTL deleted comes back either way. Removing the file is the only thing
that stops the cycle, and `029c342c` is the post-mortem of three tombstones that
ran forever because nobody did.

So: prune: true, the tombstone removed, and the directory left empty. It stays
registered because retirement recurs and the next tombstone lands here. Nothing
in it is ever meant to outlive its run, which is what makes prune the safe
setting here rather than the dangerous one. The blast radius is only what this
Kustomization created.

tests/hello-lib-retired.sh becomes the guard that outlives the fence. It holds
two things: nothing in kubernetes/ declares hello-lib again on any executable
line, and the spent tombstone is gone while its directory still prunes. Four
mutations confirmed red: prune turned off, the tombstone put back, the management
grant restored, and the gitmirror re-listed.

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

sean force-pushed chore/retire-hello-lib-tombstone from 868582da6c to 0d3a023ee5 2026-09-10 20:32:37 +00:00 Compare

binjovi-bot merged commit 0d3a023ee5 into trunk 2026-09-10 20:34:50 +00:00

binjovi-bot deleted branch chore/retire-hello-lib-tombstone 2026-09-10 20:34:51 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

sean/seanfarm!600

No description provided.