A fix to the publish scripts cannot trigger its own publish, so agentic-os:release still ships agent-compose 2.31.0 #1141

New issue

Open

opened 2026-08-19 04:49:17 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-19 04:49:17 +00:00

Member

dev-base-publish triggers on push to release filtered to docker/**. Every script the publish itself runs lives outside that path, so a fix to the publish machinery cannot trigger its own publish, and the broken image stays published until somebody notices and dispatches by hand.

Live right now, which is how I found it:

b7442d4 build(dev-base): agent-compose 2.32.0, for boundary-omit (#1139) changed docker/**, so dev-base-publish ran. Every language payload succeeded and publish-full failed after 21m2s, so plan-release, retag-full, release, and publish-release were skipped.
86829be fix(dev-base): plumb the rust pins into the full image build changed only actions/publish-dev-base/scripts/publish-image.sh. The path filter did not select it, so no publish ran, and release sits at that commit with the fix in the tree and unexercised.

The consequence is not local to this repo. agentic-os:release still carries agent-compose 2.31.0 while both main and release pin 2.32.0, so every consumer that runs agent-compose in that image is running the old binary against a tree that says otherwise. coilyco-gaming/sirens-echo#1018 is the first to hit it: its ci / image-build uses boundary-omit, which 2.31.0 does not know, and it will keep failing until the image republishes regardless of anything in that PR.

The gap is the filter, not the failure. A build failure is ordinary and the retry path is documented. What is not ordinary is that the repair for a publish failure is invisible to the trigger that would prove it, so the only signal is a downstream repo going red for a reason that looks like its own.

Options, none of them costed here:

Add the publish machinery to the path filter - actions/publish-dev-base/** alongside docker/**. Cheapest, and it makes a script fix self-verifying.
Trigger on any push to release and let the plan step decide there is nothing to do. Broader, more runs, no filter to keep in sync.
Leave the filter and make a skipped release job loud, so the state "payloads published, full image did not" is not silent.

Unblocking today is a workflow_dispatch of dev-base-publish on release with tier: full. I have not run it: it publishes a registry tag every consumer resolves, which is a live-system change this seat hands over rather than takes.

One thing I could not check: why publish-full failed. This instance answers 404 on /actions/runs/{id}/logs and /actions/jobs/{id}/logs, so I read no log. That 86829be is titled for the rust pins in the full image build is evidence about the author's diagnosis rather than about the log, and I am not claiming the fix is sufficient - only that it has never been exercised.

Refs coilyco-gaming/sirens-echo#1018, #1139

`dev-base-publish` triggers on `push` to `release` filtered to `docker/**`. Every script the publish itself runs lives outside that path, so **a fix to the publish machinery cannot trigger its own publish**, and the broken image stays published until somebody notices and dispatches by hand. Live right now, which is how I found it: * `b7442d4` *build(dev-base): agent-compose 2.32.0, for boundary-omit* (#1139) changed `docker/**`, so `dev-base-publish` ran. Every language payload succeeded and **`publish-full` failed after 21m2s**, so `plan-release`, `retag-full`, `release`, and `publish-release` were skipped. * `86829be` *fix(dev-base): plumb the rust pins into the full image build* changed only `actions/publish-dev-base/scripts/publish-image.sh`. **The path filter did not select it**, so no publish ran, and `release` sits at that commit with the fix in the tree and unexercised. The consequence is not local to this repo. `agentic-os:release` still carries **agent-compose 2.31.0** while both `main` and `release` pin 2.32.0, so every consumer that runs `agent-compose` in that image is running the old binary against a tree that says otherwise. `coilyco-gaming/sirens-echo#1018` is the first to hit it: its `ci / image-build` uses `boundary-omit`, which 2.31.0 does not know, and it will keep failing until the image republishes regardless of anything in that PR. **The gap is the filter, not the failure.** A build failure is ordinary and the retry path is documented. What is not ordinary is that the *repair* for a publish failure is invisible to the trigger that would prove it, so the only signal is a downstream repo going red for a reason that looks like its own. Options, none of them costed here: * Add the publish machinery to the path filter - `actions/publish-dev-base/**` alongside `docker/**`. Cheapest, and it makes a script fix self-verifying. * Trigger on any push to `release` and let the plan step decide there is nothing to do. Broader, more runs, no filter to keep in sync. * Leave the filter and make a skipped `release` job loud, so the state "payloads published, full image did not" is not silent. Unblocking today is a `workflow_dispatch` of `dev-base-publish` on `release` with `tier: full`. **I have not run it**: it publishes a registry tag every consumer resolves, which is a live-system change this seat hands over rather than takes. One thing I could not check: **why `publish-full` failed.** This instance answers 404 on `/actions/runs/{id}/logs` and `/actions/jobs/{id}/logs`, so I read no log. That `86829be` is titled for the rust pins in the full image build is evidence about the author's diagnosis rather than about the log, and I am not claiming the fix is sufficient - only that it has never been exercised. Refs `coilyco-gaming/sirens-echo#1018`, #1139

coilyco-ops referenced this issue

2026-08-21 20:12:12 +00:00

CI gate jobs stall while pulling the release image #1175

coilyco-ops added the

role/platform

priority

labels

2026-08-25 08:11:46 +00:00

coilyco-ops added the

autonomy

async-consult

label