Fix publish-core failure after retry and retag wait fixes #581

New issue

Closed

opened 2026-07-15 10:10:27 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-15 10:10:27 +00:00

Member

Release publish is still blocked after #579 landed.

Current head:

main and release: aff69a6e8a66a449fbb54a6a85b4df7ea76aaa1e (fix(dev-base): resolve publish retry and retag wait (#579)).
Promote run 1416 succeeded and moved release to that head.

Failure evidence:

dev-base-publish.yml run 1417 on release failed.
plan-draft succeeded.
publish-core failed.
publish-lang-node, publish-lang-go, publish-lang-dotnet, publish-ops, publish-agent, and publish-full stayed blocked.
In job index 1 (publish-core), ./actions/publish-dev-base-tier failed after 16m13s.
The alert step also failed afterward.

This means the retry/resume and retag-wait plumbing landed, but the core image publish still cannot complete. The engineer should focus on the core tier path in ./actions/publish-dev-base-tier and the release-side dev-base-publish.yml wiring. If the raw Forgejo log helper is still unavailable, add a narrow workflow/script change that makes the core tier failure observable enough to act on, but do not broaden into generic diagnostic-message churn.

Acceptance:

A PR lands a targeted fix for the publish-core failure or captures a precise, release-actionable failure mode if external registry/storage state is the wall.
PR CI is green.
After merge, release can run dev-base-publish.yml past publish-core or the issue names the exact external blocker requiring operator action.

Related issues/PRs: #565, #572, #573, #578, #579.

Release publish is still blocked after #579 landed. Current head: * `main` and `release`: `aff69a6e8a66a449fbb54a6a85b4df7ea76aaa1e` (`fix(dev-base): resolve publish retry and retag wait (#579)`). * Promote run `1416` succeeded and moved `release` to that head. Failure evidence: * `dev-base-publish.yml` run `1417` on `release` failed. * `plan-draft` succeeded. * `publish-core` failed. * `publish-lang-node`, `publish-lang-go`, `publish-lang-dotnet`, `publish-ops`, `publish-agent`, and `publish-full` stayed blocked. * In job index 1 (`publish-core`), `./actions/publish-dev-base-tier` failed after 16m13s. * The alert step also failed afterward. This means the retry/resume and retag-wait plumbing landed, but the core image publish still cannot complete. The engineer should focus on the `core` tier path in `./actions/publish-dev-base-tier` and the release-side `dev-base-publish.yml` wiring. If the raw Forgejo log helper is still unavailable, add a narrow workflow/script change that makes the core tier failure observable enough to act on, but do not broaden into generic diagnostic-message churn. Acceptance: * A PR lands a targeted fix for the `publish-core` failure or captures a precise, release-actionable failure mode if external registry/storage state is the wall. * PR CI is green. * After merge, `release` can run `dev-base-publish.yml` past `publish-core` or the issue names the exact external blocker requiring operator action. Related issues/PRs: #565, #572, #573, #578, #579.

coilyco-ops commented

2026-07-15 10:10:50 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-agentic-os-581 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T10:10:49Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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/agentic-os#581 · branch issue-581 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-agentic-os-581 · ward v0.697.0 · dispatched 2026-07-15T10:10:43Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-agentic-os-581` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T10:10:49Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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/agentic-os#581` · branch `issue-581` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-agentic-os-581` · ward `v0.697.0` · dispatched `2026-07-15T10:10:43Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.697.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-15 10:16:45 +00:00

fix(dev-base): bound ward source clone in core publish #582

coilyco-ops commented

2026-07-15 10:25:26 +00:00

Author

Member

WARDED_WORKFLOW: #582

details

workflow: pull-request-and-merge; review summary: review gate intentionally skipped because temporary ward default pending brokered QA.

Retrospective: the fix stayed narrow. The core publish path now bounds the ward source clone, and PR CI materializes the missing ward defaults asset before building ward from source.

Confidence: high.

Surprise: ward main was missing cmd/ward/defaultsassets, so the CI job needed a source sync step before go build.

Follow-ups: merge PR #582 after the review gate is lifted.

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/pulls/582 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate intentionally skipped because temporary ward default pending brokered QA. Retrospective: the fix stayed narrow. The core publish path now bounds the ward source clone, and PR CI materializes the missing ward defaults asset before building ward from source. Confidence: high. Surprise: ward main was missing `cmd/ward/defaultsassets`, so the CI job needed a source sync step before `go build`. Follow-ups: merge PR #582 after the review gate is lifted. </details>

coilyco-ops closed this issue

2026-07-15 10:27:40 +00:00