ci(release): recompose the installer bundle after publishing #25

wtclaude · 2026-08-04T16:16:25Z

wtclaude commented

2026-08-04 16:16:25 +00:00

The dispatch half of installer Phase 0 item 3. Main PR: RunicGateway/installer#3. Sibling: RunicGateway/servuo-plugins#9. Docs: RunicGateway/docs#85.

Why

The installer does not resolve "latest" at run time — it installs the exact combination named by a published bundle manifest (PLAN.md §7.1). So until now, a new sidecar release was invisible to operators until the installer repo's nightly cron happened to notice it.

What changed

One step appended to release.yml, gated on release == 'true', that POSTs to RunicGateway/installer's bundle.yml workflow-dispatch endpoint. That job re-reads PROTOCOL_VERSION from sidecar/src/main.rs at the new release tag and checks it against the overlay's declared protocol before publishing anything (§7.1 gate 1) — so a bump that lands without its plugin half is caught at compose time instead of on an operator's shard.

Two things it deliberately does not do

It does not wait (§7.3). Gitea's dispatch endpoint returns no run handle, so there is nothing to poll — a waiting step would have to guess which run is its own while holding a runner idle. The bundle job runs its own gates regardless of who started it.

It cannot fail this job. By the time the step runs, the release is published and correct; failing the run would misreport that. Every branch of the case warns rather than exits non-zero. That also keeps this from becoming a new hard credential requirement — REGISTRY_TOKEN having write on the installer repo is a nicety, and without it the nightly cron picks the release up anyway. The header now says so.

Verification

The workflow parses; the new step is last, gated on steps.plan.outputs.release == 'true', and contains no path that can exit non-zero. Not exercised end to end here — it fires on the next merge to main, and a 403/404 from it degrades to a warning by design.

AI-assisted contribution

This PR was written with AI assistance (Claude Code / Claude Opus 5); commits carry the Co-Authored-By trailer.

The dispatch half of installer Phase 0 item 3. Main PR: RunicGateway/installer#3. Sibling: RunicGateway/servuo-plugins#9. Docs: RunicGateway/docs#85. ## Why The installer does not resolve "latest" at run time — it installs the exact combination named by a published **bundle manifest** ([`PLAN.md` §7.1](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/PLAN.md)). So until now, a new sidecar release was invisible to operators until the installer repo's nightly cron happened to notice it. ## What changed One step appended to `release.yml`, gated on `release == 'true'`, that `POST`s to `RunicGateway/installer`'s `bundle.yml` workflow-dispatch endpoint. That job re-reads `PROTOCOL_VERSION` from `sidecar/src/main.rs` at the new release tag and checks it against the overlay's declared protocol before publishing anything (§7.1 gate 1) — so a bump that lands without its plugin half is caught at compose time instead of on an operator's shard. ## Two things it deliberately does not do **It does not wait** (§7.3). Gitea's dispatch endpoint returns no run handle, so there is nothing to poll — a waiting step would have to guess which run is its own while holding a runner idle. The bundle job runs its own gates regardless of who started it. **It cannot fail this job.** By the time the step runs, the release is published and correct; failing the run would misreport that. Every branch of the `case` warns rather than exits non-zero. That also keeps this from becoming a new hard credential requirement — `REGISTRY_TOKEN` having write on the installer repo is a nicety, and without it the nightly cron picks the release up anyway. The header now says so. ## Verification The workflow parses; the new step is last, gated on `steps.plan.outputs.release == 'true'`, and contains no path that can exit non-zero. Not exercised end to end here — it fires on the next merge to `main`, and a `403`/`404` from it degrades to a warning by design. ## AI-assisted contribution - [x] This PR was written with AI assistance (Claude Code / Claude Opus 5); commits carry the `Co-Authored-By` trailer.

wtclaude added 1 commit 2026-08-04 16:16:27 +00:00

ci(release): recompose the installer bundle after publishing

PR Checks / rust-gates (pull_request) Successful in 12m18s

Details

f8d80c07db

Phase 0 item 3 of docs/installer/PLAN.md wired up from this side. The installer
does not resolve "latest" at run time — it installs the exact combination named
by a published bundle manifest (PLAN.md §7.1), so until now a new sidecar release
was invisible to operators until the installer repo's nightly cron noticed it.

Adds a final step that POSTs to RunicGateway/installer's bundle workflow-dispatch
endpoint. The bundle job re-reads PROTOCOL_VERSION from sidecar/src/main.rs at the new
release tag and checks it against the overlay's declared protocol before
publishing anything (gate 1), so a bump that lands without its plugin half is
caught at compose time instead of on an operator's shard.

Dispatch, don't wait (PLAN.md §7.3): Gitea's dispatch endpoint returns no run
handle, so there is nothing to poll — a waiting step would have to guess which
run is its own while holding a runner idle. The bundle job runs its own gates
regardless of who started it.

A dispatch failure is a warning, never a failure of this job. By the time this
step runs the release is published and correct, so failing the run would
misreport that; the installer's nightly cron recomposes from whatever the latest
releases actually are, making a dropped dispatch cost latency rather than
correctness. That also means REGISTRY_TOKEN having write on the installer repo
is a nicety, not a new hard requirement — noted in the header.

Verified the workflow still parses and that the new step is last, gated on
release=='true', and contains no path that can exit non-zero.

Co-Authored-By: Claude <noreply@anthropic.com>

wtclaude referenced this pull request from RunicGateway/servuo-plugins

2026-08-04 16:16:48 +00:00

ci(release): recompose the installer bundle after publishing #9

wtclaude referenced this issue from a commit

2026-08-04 16:17:16 +00:00

docs(installer): record Phase 0.3 — the bundle CI and where bundles live

wtclaude referenced this issue from a commit

2026-08-04 16:18:13 +00:00

docs(installer): record Phase 0.3 — the bundle CI and where bundles live

wtclaude referenced this pull request from RunicGateway/docs

2026-08-04 16:18:35 +00:00

docs(installer): record Phase 0.3 — the bundle CI and where bundles live #85