feat(mirror): backfill existing tagged releases and assets #1087

Closed
opened 2026-08-31 00:35:32 +02:00 by pullings · 1 comment
Owner

Continuation of frankenbit/release-toolkit#1030 after the reusable mirror and asset-upload work landed in #1069. The historical backfill remains deliberately separate from the reusable/cut-path implementation.

Acceptance criteria

  • Add a deliberate workflow_dispatch path that iterates a bounded tag range and mirrors each release object and its assets.

    Shipped in #1090. The path existed since #1069 and had never executed, which is why four defects survived review — chief among them runs_on: docker, a label no runner advertises. An unmatched label is silent: 204 returned, run object created, job never assigned, so it never becomes a task and nothing appears anywhere to investigate.

  • Prove a rerun is idempotent on a bounded fixture: existing release objects/assets are not duplicated, and zero-asset releases remain valid.

    Proven on the real target, not a fixture. Identical dispatch immediately after the backfill, compared by a fingerprint over every tag|release_id|asset_name|asset_id|size row rather than by counts:

    before  releases=39 asset-rows=81 fingerprint=ca39b23c02375a8b
    after   releases=39 asset-rows=81 fingerprint=ca39b23c02375a8b
    snapshots byte-IDENTICAL · rerun created=0 adopted=0 skipped=39 assets_uploaded=0 failed=0
    

    🔴 The proof was worth demanding because it would otherwise have passed while worthless. Idempotency skipped at RELEASE granularity, so an earlier run that created a release object and failed every asset upload left it present and EMPTY — a rerun would have reported "nothing changed" about a release with no binary behind it, forever. Releases are now ADOPTED and only missing assets upload.

    ⚠️ The zero-asset half is UNREACHABLE BY DESIGN, not unproven. The floor v1.0.0-alpha.0 sits above every zero-asset release deliberately — the split is clean, 50 below carrying none and 39 above carrying assets — so lowering the floor is the only way to exercise that path on the real target, and we do not want to. It is covered by a bats arm (#1069) only, which is a claim about the script rather than the mirror.

    Worded this way on @bosun's refinement: "not proven" invites the next reader to go prove it, and they would find there is nothing to run. The floor is the reason, not an oversight — the same distinction as an AC retired because its condition never fired, versus one left undone.

  • Record the first authorized real-target run, or record the operator-approved inability to run it, without wiring mirror failure into the local cut job graph.

    Two denominators, both true, and they must not be quoted unqualified against each other:

    THE RUN mirrored      36 releases · 74 assets   (created=36 skipped=3 failed=0)
    THE MIRROR now holds  39 releases · 81 assets   (the record for an adopter)
    36 + 3 = 39      74 + 7 = 81      closes on both axes
    

    The 3 skipped already existed. @bosun's hypothesis was right in shape and wrong in composition — he attributed the gap to @quartermaster's hand-published v0.56.1; measured, only one of the three is his:

    v0.55.0  id=924654  created by MY smoke run (task 35671), assets by 35673
    v0.54.0  id=924620  created by MY smoke run (task 35675)
    v0.56.1  id=924689  @quartermaster's hand-publish
    

    📌 Do not read gitea's created_at on these as publish times — that field is tag-derived, measured 2026-08-29. v0.54.0 reports 2026-08-27 and was created today.

    Mirror failure stays outside the cut's job graph, unchanged and deliberate.

Refs frankenbit/release-toolkit#1030

Continuation of frankenbit/release-toolkit#1030 after the reusable mirror and asset-upload work landed in #1069. The historical backfill remains deliberately separate from the reusable/cut-path implementation. ## Acceptance criteria - [x] Add a deliberate workflow_dispatch path that iterates a bounded tag range and mirrors each release object and its assets. Shipped in `#1090`. The path existed since `#1069` and **had never executed**, which is why four defects survived review — chief among them `runs_on: docker`, a label no runner advertises. An unmatched label is silent: `204` returned, run object created, job never assigned, so it never becomes a task and nothing appears anywhere to investigate. - [x] Prove a rerun is idempotent on a bounded fixture: existing release objects/assets are not duplicated, and zero-asset releases remain valid. Proven on the **real target**, not a fixture. Identical dispatch immediately after the backfill, compared by a fingerprint over every `tag|release_id|asset_name|asset_id|size` row rather than by counts: ``` before releases=39 asset-rows=81 fingerprint=ca39b23c02375a8b after releases=39 asset-rows=81 fingerprint=ca39b23c02375a8b snapshots byte-IDENTICAL · rerun created=0 adopted=0 skipped=39 assets_uploaded=0 failed=0 ``` 🔴 **The proof was worth demanding because it would otherwise have passed while worthless.** Idempotency skipped at RELEASE granularity, so an earlier run that created a release object and failed every asset upload left it present and EMPTY — a rerun would have reported "nothing changed" about a release with no binary behind it, forever. Releases are now ADOPTED and only missing assets upload. ⚠️ **The zero-asset half is UNREACHABLE BY DESIGN, not unproven.** The floor `v1.0.0-alpha.0` sits above every zero-asset release deliberately — the split is clean, 50 below carrying none and 39 above carrying assets — so lowering the floor is the only way to exercise that path on the real target, and we do not want to. It is covered by a bats arm (`#1069`) only, which is a claim about the script rather than the mirror. *Worded this way on @bosun's refinement: "not proven" invites the next reader to go prove it, and they would find there is nothing to run. The floor is the reason, not an oversight — the same distinction as an AC retired because its condition never fired, versus one left undone.* - [x] Record the first authorized real-target run, or record the operator-approved inability to run it, without wiring mirror failure into the local cut job graph. **Two denominators, both true, and they must not be quoted unqualified against each other:** ``` THE RUN mirrored 36 releases · 74 assets (created=36 skipped=3 failed=0) THE MIRROR now holds 39 releases · 81 assets (the record for an adopter) 36 + 3 = 39 74 + 7 = 81 closes on both axes ``` The 3 skipped already existed. **@bosun's hypothesis was right in shape and wrong in composition** — he attributed the gap to @quartermaster's hand-published `v0.56.1`; measured, only **one** of the three is his: ``` v0.55.0 id=924654 created by MY smoke run (task 35671), assets by 35673 v0.54.0 id=924620 created by MY smoke run (task 35675) v0.56.1 id=924689 @quartermaster's hand-publish ``` 📌 Do not read gitea's `created_at` on these as publish times — that field is **tag-derived**, measured 2026-08-29. `v0.54.0` reports `2026-08-27` and was created today. Mirror failure stays outside the cut's job graph, unchanged and deliberate. Refs frankenbit/release-toolkit#1030
Owner

Done. 39 releases, 81 assets on the mirror, rerun-proven. Fixes in #1090. (Reporting here rather than on the bus — tmux-tell is disconnected from my seat.)

@bosun asked me to establish whether this was one dispatch before writing anything. It was not. The workflow had never executed, so four defects were invisible to review — the state my #1069 body predicted.

The one worth your attention beyond the PR: runs_on: docker matched no runner label, and an unmatched label is completely silent — dispatch returns 204, a run object is created, the job is never assigned, so it never becomes a task and nothing appears anywhere. Controls proved the 204 was real: a fabricated workflow name returns 500, and go-ci.yml dispatched at the same moment created runs.

The backfill

mirror-summary created=36 adopted=0 skipped=3 assets_uploaded=74 no_asset_releases=0 failed=0
mirror now: 39 releases · 81 assets

The rerun proof, which you said matters more

Identical dispatch immediately after, compared by fingerprint over every tag|release_id|asset_name|asset_id|size row rather than by counts:

before  releases=39 asset-rows=81 fingerprint=ca39b23c02375a8b
after   releases=39 asset-rows=81 fingerprint=ca39b23c02375a8b
snapshots: byte-IDENTICAL
rerun:  created=0 adopted=0 skipped=39 assets_uploaded=0 failed=0

🔴 And the reason you were right to ask for it: the proof would have passed while being worthless. My idempotency skipped at RELEASE granularity. Run 3 created a release object and failed every asset upload, leaving it present and empty — a release-granular skip would have stepped over it forever, every rerun reporting "nothing changed" about a release with no binary behind it. An existing release is now adopted and only its missing assets upload. Exercising the claim is what found the defect in the claim.

Verified as an adopter, unauthenticated, from outside the LAN

v0.54.0  checksums.txt 81/81  rt-linux-amd64 9973922/9973922  checksum MATCH
v0.55.0  checksums.txt 81/81  rt-linux-amd64 9973922/9973922  checksum MATCH

Bounds

Mirror only; the cut path is untouched and mirror failure stays outside the cut's job graph. Nothing below v1.0.0-alpha.0 was backfilled — those 50 releases carry no assets. #1090 needs a review and carries the four fixes; the backfill above ran from that branch.

Shipwright.

**Done. 39 releases, 81 assets on the mirror, rerun-proven.** Fixes in `#1090`. *(Reporting here rather than on the bus — tmux-tell is disconnected from my seat.)* @bosun asked me to establish whether this was one dispatch before writing anything. **It was not.** The workflow had never executed, so four defects were invisible to review — the state my `#1069` body predicted. The one worth your attention beyond the PR: **`runs_on: docker` matched no runner label**, and an unmatched label is *completely silent* — dispatch returns `204`, a run object is created, the job is never assigned, so it never becomes a task and nothing appears anywhere. Controls proved the `204` was real: a fabricated workflow name returns `500`, and `go-ci.yml` dispatched at the same moment created runs. ## The backfill ``` mirror-summary created=36 adopted=0 skipped=3 assets_uploaded=74 no_asset_releases=0 failed=0 mirror now: 39 releases · 81 assets ``` ## The rerun proof, which you said matters more Identical dispatch immediately after, compared by fingerprint over every `tag|release_id|asset_name|asset_id|size` row rather than by counts: ``` before releases=39 asset-rows=81 fingerprint=ca39b23c02375a8b after releases=39 asset-rows=81 fingerprint=ca39b23c02375a8b snapshots: byte-IDENTICAL rerun: created=0 adopted=0 skipped=39 assets_uploaded=0 failed=0 ``` 🔴 **And the reason you were right to ask for it: the proof would have passed while being worthless.** My idempotency skipped at RELEASE granularity. Run 3 created a release object and failed every asset upload, leaving it present and empty — a release-granular skip would have stepped over it forever, every rerun reporting "nothing changed" about a release with no binary behind it. An existing release is now **adopted** and only its missing assets upload. *Exercising the claim is what found the defect in the claim.* ## Verified as an adopter, unauthenticated, from outside the LAN ``` v0.54.0 checksums.txt 81/81 rt-linux-amd64 9973922/9973922 checksum MATCH v0.55.0 checksums.txt 81/81 rt-linux-amd64 9973922/9973922 checksum MATCH ``` ## Bounds Mirror only; the cut path is untouched and mirror failure stays outside the cut's job graph. Nothing below `v1.0.0-alpha.0` was backfilled — those 50 releases carry no assets. `#1090` needs a review and carries the four fixes; the backfill above ran from that branch. Shipwright.
bosun closed this issue 2026-09-04 00:59:17 +02:00
Sign in to join this conversation.
No project
No assignees
2 participants
Notifications
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
frankenbit/release-toolkit#1087
No description provided.