Gate ward release and publish workflows behind tests #943

New issue

Open

opened 2026-07-10 04:51:28 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 04:51:28 +00:00

Member

Request from Kai: put all release / publish / external-mutation jobs behind tests.

Current ward workflow shape:

.forgejo/workflows/test.yml runs go vet, go test, and golangci-lint on main/pull_request.
.forgejo/workflows/release.yml runs independently on main pushes. Its first release job checks out, bumps/tags, creates the Forgejo release, and only then downstream jobs publish binaries, KDL write/read assets, Homebrew tap updates, and Scoop manifest updates.
Release side effects are not structurally downstream of the test workflow. A main push can therefore create a tag/release or publish assets even if tests would fail or if the test workflow is delayed/broken.

Required change:

Gate every ward release/publish/external-mutation job behind tests in the same release workflow, or behind a robust Forgejo-supported status dependency if the implementation proves that is reliable.
Preferred shape: add a front test job to .forgejo/workflows/release.yml that runs the same authoritative commands as .forgejo/workflows/test.yml: go vet ./..., go test ./..., and golangci-lint run ./... in the same dev-base image.
Make the release job need that test job. Every downstream publish job should continue to need release, so the full graph becomes test -> release -> publish-binaries / publish-kdl-* / tap / scoop.
Keep .github/workflows/test.yml and .forgejo/workflows/test.yml mirror discipline intact. If shared workflow duplication becomes a concern, factor a script/ward verb rather than letting release and test drift.
For manual reruns, release must still re-run or verify the test gate before recreating/uploading assets. A manual release dispatch must not bypass tests by default.
Consider adding an explicit smoke for the binary release asset availability before any consumer bumps run, because recent dispatch failures tried to download a just-selected ward version whose asset 404ed.

Acceptance criteria:

Ward release tags, Forgejo/GitHub release assets, KDL tier assets, Homebrew tap bumps, and Scoop manifest bumps cannot run unless the ward test gate passed in that release workflow.
The test commands are not weaker than the existing test.yml workflow.
Release docs or comments explain that release side effects are deliberately downstream of tests because warded agents consume fresh releases for bootstrap.
Existing workflow mirror checks still pass.

Context:

This follows repeated warded/dispatch regressions and a recent bootstrap failure where a forwarded dispatch tried to download a newly selected ward release asset. The goal is true release safety, not a quick lint job.

Request from Kai: put all release / publish / external-mutation jobs behind tests. Current ward workflow shape: * `.forgejo/workflows/test.yml` runs `go vet`, `go test`, and `golangci-lint` on main/pull_request. * `.forgejo/workflows/release.yml` runs independently on main pushes. Its first `release` job checks out, bumps/tags, creates the Forgejo release, and only then downstream jobs publish binaries, KDL write/read assets, Homebrew tap updates, and Scoop manifest updates. * Release side effects are not structurally downstream of the test workflow. A main push can therefore create a tag/release or publish assets even if tests would fail or if the test workflow is delayed/broken. Required change: * Gate every ward release/publish/external-mutation job behind tests in the same release workflow, or behind a robust Forgejo-supported status dependency if the implementation proves that is reliable. * Preferred shape: add a front `test` job to `.forgejo/workflows/release.yml` that runs the same authoritative commands as `.forgejo/workflows/test.yml`: `go vet ./...`, `go test ./...`, and `golangci-lint run ./...` in the same dev-base image. * Make the release job need that `test` job. Every downstream publish job should continue to need `release`, so the full graph becomes `test -> release -> publish-binaries / publish-kdl-* / tap / scoop`. * Keep `.github/workflows/test.yml` and `.forgejo/workflows/test.yml` mirror discipline intact. If shared workflow duplication becomes a concern, factor a script/ward verb rather than letting release and test drift. * For manual reruns, release must still re-run or verify the test gate before recreating/uploading assets. A manual release dispatch must not bypass tests by default. * Consider adding an explicit smoke for the binary release asset availability before any consumer bumps run, because recent dispatch failures tried to download a just-selected ward version whose asset 404ed. Acceptance criteria: * Ward release tags, Forgejo/GitHub release assets, KDL tier assets, Homebrew tap bumps, and Scoop manifest bumps cannot run unless the ward test gate passed in that release workflow. * The test commands are not weaker than the existing `test.yml` workflow. * Release docs or comments explain that release side effects are deliberately downstream of tests because warded agents consume fresh releases for bootstrap. * Existing workflow mirror checks still pass. Context: This follows repeated warded/dispatch regressions and a recent bootstrap failure where a forwarded dispatch tried to download a newly selected ward release asset. The goal is true release safety, not a quick lint job.

coilyco-ops commented

2026-07-10 09:00:05 +00:00

Author

Member

Fresh evidence from the Forgejo performance / dispatch reliability sweep, 2026-07-10:

The release pipeline produced published releases with zero assets while dispatch was actively selecting latest release tags for container bootstrap:

v0.573.0 - published 2026-07-10T08:54:23Z, assets: 0
v0.572.0 - published 2026-07-10T08:54:09Z, assets: 0
v0.571.0 - published 2026-07-10T08:53:53Z, assets: 0
v0.570.0 - published 2026-07-10T08:38:17Z, later had the expected 9 assets including ward-linux-arm64

That caused repeated director dispatch failures against ward#971, agentic-os#419, and ward#977 until ward#935 landed a retry. This issue is still the structural release-side fix: release/publish workflows should not expose a usable latest release/tag surface before tests and required platform assets are ready.

Fresh evidence from the Forgejo performance / dispatch reliability sweep, 2026-07-10: The release pipeline produced published releases with zero assets while dispatch was actively selecting latest release tags for container bootstrap: * `v0.573.0` - published `2026-07-10T08:54:23Z`, `assets: 0` * `v0.572.0` - published `2026-07-10T08:54:09Z`, `assets: 0` * `v0.571.0` - published `2026-07-10T08:53:53Z`, `assets: 0` * `v0.570.0` - published `2026-07-10T08:38:17Z`, later had the expected 9 assets including `ward-linux-arm64` That caused repeated director dispatch failures against `ward#971`, `agentic-os#419`, and `ward#977` until `ward#935` landed a retry. This issue is still the structural release-side fix: release/publish workflows should not expose a usable latest release/tag surface before tests and required platform assets are ready.

coilyco-ops commented

2026-07-10 09:00:09 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-943 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T09:00:09Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#943 · branch issue-943 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-943 · ward v0.569.0 · dispatched 2026-07-10T09:00:09Z
Comment thread: 2 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T04:52:28Z), @coilyco-ops (2026-07-10T09:00:05Z)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.569.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-943` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T09:00:09Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#943` · branch `issue-943` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-943` · ward `v0.569.0` · dispatched `2026-07-10T09:00:09Z` - **Comment thread:** 2 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T04:52:28Z), @coilyco-ops (2026-07-10T09:00:05Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.569.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

consult

labels

2026-07-10 09:00:32 +00:00

~~coilyco-ops referenced this issue 2026-07-10 09:26:03 +00:00~~

Add a natural TUI surface for broker and dispatch logs #927