The release pipeline has failed on every main push for a week, so nothing has shipped since v2.19.0 #281
Labels
No labels
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-flight-deck/agent-compose#281
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Every
releaserun onmainis failing, and has been for at least the last ten pushes. The most recent successful release is v2.19.0, 2026-08-07.What I can show
Ten consecutive
releaseruns, newest first, allstatus=failure:Run 234 started
03:14:29Zand failed03:14:54Z— 25 seconds, which is short for a job that builds and tests, so it looks like a setup failure rather than a build one.Corroborating:
coilyco-flight-deck/agentic-ospinsAGENT_COMPOSE_VERSION=2.19.0atdocker/dev-base/full/Dockerfile:69, exactly where releases stopped.What I could not determine
The cause.
/api/v1/.../actions/runs/234and/actions/runs/234/logsboth returnresource does not exist, and the tasks endpoint exposes no per-job breakdown, so I could not read a single line of failure output. Everything above is from run metadata alone.One hypothesis I could not test, offered as a lead rather than a finding:
.forgejo/workflows/release.ymlruns the job insidecontainer: forgejo.coilysiren.me/coilyco-flight-deck/agentic-os:release. A pull failure there would produce a fast setup-time failure like this one, and it would be circular — agent-compose's release runs inside an image that ships agent-compose. Someone with runner log access should check that before chasing the workflow body.Why it matters beyond the version number
The pipeline is the delivery path for everything downstream.
agentic-os:releaseships the binary;coilyco-gaming/sirens-echocomposes bundles with it at image build. So a change landing onmainhere reaches no consumer until this is fixed.Concretely blocked right now: #280's seat-identity override landed on
mainas71b112b, and cannot reachsirens-echo— which needs it to stop introducing Olaf in front of the Sirens Discord. Nothing in that chain is broken except this.A week of green-looking merges that shipped nothing is also the reporting half of this.
mainlooks healthy from the commit log.Pulled the full run history rather than the first page, and it gives a bisect boundary nine minutes wide.
Every run before
1e5c409cis a normal mix of success and failure. Every run from53be5372onward is a failure, without exception — that is 33 consecutive failing runs across a week, not an intermittent break.v2.19.0published at03:50:17Z, and1e5c409csucceeded at03:59:40Zafter it. So the last green run is after the last release, which rules out the release step itself having been mid-break.That narrows it to whatever changed between those two commits, or to something environmental that happened in that nine-minute window. The commit range is the cheaper thing to check first.
Still no logs — the runs and logs API endpoints both return
resource does not exist, so I cannot confirm any of this against actual failure output. The boundary is from run metadata alone.One correction to my hypothesis above, since the history contradicts part of it: I guessed a pull failure on
container: agentic-os:release. That image has presumably been pulled successfully by other repositories' workflows all week, so a plain unavailable-image story does not fit on its own. Treat the commit range as the stronger lead.