release: publish-kdl-tiers (write) + bump-tap-formula cancelled under matrix fan-out (ward#343 follow-up) #345

New issue

Closed

opened 2026-06-25 18:49:49 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-06-25 18:49:49 +00:00

Owner

Context

ward#343 generalized publish-kdl-write into the publish-kdl-tiers matrix over {read, write, admin}. On its first release (v0.178.0, run#465) the two new tiers — publish-kdl-tiers (read) and (admin) — built and uploaded all four assets cleanly. But publish-kdl-tiers (write) and bump-tap-formula came back cancelled (not failed), so v0.178.0 shipped without the two ward-kdl-write-linux-<arch> assets and the tap formula did not bump.

Why this is a follow-up, not a ward#343 bug

The three tier legs are byte-identical templated jobs; read+admin passing while write cancelled (and a local build of the write tier succeeding) rules out a fault in the job body. cancelled across the two last-scheduled downstream jobs, while their siblings passed, reads as runner contention: ward#343 widened the downstream fan-out from 3 jobs (publish-binaries, write, bump-tap) to 5 (publish-binaries, read, write, admin, bump-tap), which may outrun the runner pool. Run#466 was only the GitHub mirror workflow, so nothing superseded run#465.

Why nothing broken shipped (but it should still be fixed)

bump-tap-formula is idempotent and backfilling and the tap never advanced to the partial release, so brew users were never served a writeless v0.178.0; the next full release backfills both the write assets and the tap pointer. Still, the broker downloads ward-kdl-write from the release ward shipped from (docs/broker.md), so a release that lands ward assets but drops write is a latent gap.

Proposed fix (pick one)

Confirm the Forgejo runner pool's concurrency vs. the 5 downstream jobs; raise capacity if that's the cap.
Add strategy.max-parallel to publish-kdl-tiers (or a concurrency: group) so the tier legs queue rather than contend, leaving headroom for publish-binaries + bump-tap-formula.
Verify a subsequent release produces all six tier assets + a tap bump to confirm the flake was transient.

Acceptance: a push to main reliably produces six ward-kdl-<tier>-linux-<arch> assets and bumps the tap, with no cancelled downstream jobs.

## Context ward#343 generalized `publish-kdl-write` into the `publish-kdl-tiers` matrix over `{read, write, admin}`. On its first release (v0.178.0, run#465) the two new tiers — `publish-kdl-tiers (read)` and `(admin)` — built and uploaded all four assets cleanly. But `publish-kdl-tiers (write)` and `bump-tap-formula` came back **cancelled** (not failed), so v0.178.0 shipped without the two `ward-kdl-write-linux-<arch>` assets and the tap formula did not bump. ## Why this is a follow-up, not a ward#343 bug The three tier legs are byte-identical templated jobs; read+admin passing while write *cancelled* (and a local build of the write tier succeeding) rules out a fault in the job body. `cancelled` across the two *last-scheduled* downstream jobs, while their siblings passed, reads as **runner contention**: ward#343 widened the downstream fan-out from 3 jobs (publish-binaries, write, bump-tap) to 5 (publish-binaries, read, write, admin, bump-tap), which may outrun the runner pool. Run#466 was only the GitHub mirror workflow, so nothing superseded run#465. ## Why nothing broken shipped (but it should still be fixed) `bump-tap-formula` is idempotent and backfilling and the tap never advanced to the partial release, so `brew` users were never served a writeless v0.178.0; the next full release backfills both the write assets and the tap pointer. Still, the broker downloads `ward-kdl-write` from the release `ward` shipped from (docs/broker.md), so a release that lands `ward` assets but drops `write` is a latent gap. ## Proposed fix (pick one) - Confirm the Forgejo runner pool's concurrency vs. the 5 downstream jobs; raise capacity if that's the cap. - Add `strategy.max-parallel` to `publish-kdl-tiers` (or a `concurrency:` group) so the tier legs queue rather than contend, leaving headroom for `publish-binaries` + `bump-tap-formula`. - Verify a subsequent release produces all six tier assets + a tap bump to confirm the flake was transient. Acceptance: a push to main reliably produces six `ward-kdl-<tier>-linux-<arch>` assets and bumps the tap, with no cancelled downstream jobs.

coilysiren added the

interactive

labels

2026-07-01 04:29:36 +00:00

coilyco-ops commented

2026-07-01 23:57:05 +00:00

Member

Re-scoped during launch triage: the publish-kdl-tiers half dies with #455 (tier CLIs leave the public artifacts). The bump-tap-formula-cancelled-under-matrix-fan-out half still matters for the release path and interacts with #454's release-CI work. Demoted P2->P3; fold the surviving half into #454's implementation if convenient. Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

coilyco-ops added

and removed

labels

2026-07-01 23:57:06 +00:00

coilyco-ops referenced this issue

2026-07-01 23:58:55 +00:00

Publish the full release binary matrix to GitHub releases, checksummed and CI-built from the same tags #454

coilysiren commented

2026-07-06 18:59:35 +00:00

Author

Owner

Re-spec: premise drifted. Tier assets no longer ship to the public release page (release.yml now publishes to the internal package registry per ward#501/#455), voiding the six-release-page-assets bug. The surviving bump-tap-formula contention was redirected into #454; re-frame against the new publish topology. Re-triage 2026-07-06.

coilysiren closed this issue

2026-07-06 20:30:35 +00:00