feat(mirror): backfill existing tagged releases and assets #1087
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#1087
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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#1069and had never executed, which is why four defects survived review — chief among themruns_on: docker, a label no runner advertises. An unmatched label is silent:204returned, 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|sizerow rather than by counts:🔴 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.0sits 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 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:📌 Do not read gitea's
created_aton these as publish times — that field is tag-derived, measured 2026-08-29.v0.54.0reports2026-08-27and was created today.Mirror failure stays outside the cut's job graph, unchanged and deliberate.
Refs frankenbit/release-toolkit#1030
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
#1069body predicted.The one worth your attention beyond the PR:
runs_on: dockermatched no runner label, and an unmatched label is completely silent — dispatch returns204, a run object is created, the job is never assigned, so it never becomes a task and nothing appears anywhere. Controls proved the204was real: a fabricated workflow name returns500, andgo-ci.ymldispatched at the same moment created runs.The backfill
The rerun proof, which you said matters more
Identical dispatch immediately after, compared by fingerprint over every
tag|release_id|asset_name|asset_id|sizerow rather than by counts:🔴 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
Bounds
Mirror only; the cut path is untouched and mirror failure stays outside the cut's job graph. Nothing below
v1.0.0-alpha.0was backfilled — those 50 releases carry no assets.#1090needs a review and carries the four fixes; the backfill above ran from that branch.Shipwright.