publish-release reports success while the release workflow it calls never runs #1032

New issue

Closed

opened 2026-08-12 21:07:09 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-12 21:07:09 +00:00

Member

Observed

dev-base-publish.yml run 3270, dispatched with tier: full on release:

success   plan-draft                 0:00:07
success   publish-lang-* (all five)  ~0:00:44 each
success   publish-full               0:35:23
success   publish-release            0:00:00

Every job green. The full image draft published correctly. But :release did
not move, and the log archive shows the three jobs inside the called workflow
never executed:

plan-release-28247-attempt-1.MISSING
retag-full-28248-attempt-1.MISSING
release-28249-attempt-1.MISSING

publish-release is a uses: ./.forgejo/workflows/release.yml call. On the
dispatch path it was marked success in zero seconds without running the callee.

For contrast, the push-triggered publish earlier the same day ran them properly
and finished the caller last:

05:45:58  plan-release
05:46:10  retag-full
05:49:12  release
05:49:22  publish-release

Why it matters more than the missing promotion

A half-finished publish presented as a fully green run. Recovering it needed a
second dispatch against release.yml directly, which was only discoverable by
reading the log archive for .MISSING entries and then checking the registry.

Anyone trusting the job colour would conclude the image shipped. It had not.
:release sat on the previous digest while every job reported success.

Wanted

publish-release should fail, or at minimum not report success, when the
workflow it calls did not run. If Forgejo cannot support a reusable-workflow
call on the workflow_dispatch path, the honest shape is to detect that and
fail loudly rather than to pass silently.

A cheap backstop either way: assert after promotion that the release tag
resolves to the digest just built, and fail the run when it does not.

Repro

Dispatch dev-base-publish.yml on ref release with tier: full, then
compare the release tag timestamp in the package registry against the run.

## Observed `dev-base-publish.yml` run 3270, dispatched with `tier: full` on `release`: ``` success plan-draft 0:00:07 success publish-lang-* (all five) ~0:00:44 each success publish-full 0:35:23 success publish-release 0:00:00 ``` Every job green. The full image draft published correctly. But `:release` did not move, and the log archive shows the three jobs inside the called workflow never executed: ``` plan-release-28247-attempt-1.MISSING retag-full-28248-attempt-1.MISSING release-28249-attempt-1.MISSING ``` `publish-release` is a `uses: ./.forgejo/workflows/release.yml` call. On the dispatch path it was marked success in zero seconds without running the callee. For contrast, the push-triggered publish earlier the same day ran them properly and finished the caller last: ``` 05:45:58 plan-release 05:46:10 retag-full 05:49:12 release 05:49:22 publish-release ``` ## Why it matters more than the missing promotion A half-finished publish presented as a fully green run. Recovering it needed a second dispatch against `release.yml` directly, which was only discoverable by reading the log archive for `.MISSING` entries and then checking the registry. Anyone trusting the job colour would conclude the image shipped. It had not. `:release` sat on the previous digest while every job reported success. ## Wanted `publish-release` should fail, or at minimum not report success, when the workflow it calls did not run. If Forgejo cannot support a reusable-workflow call on the `workflow_dispatch` path, the honest shape is to detect that and fail loudly rather than to pass silently. A cheap backstop either way: assert after promotion that the `release` tag resolves to the digest just built, and fail the run when it does not. ## Repro Dispatch `dev-base-publish.yml` on ref `release` with `tier: full`, then compare the `release` tag timestamp in the package registry against the run.

coilyco-ops added the

labels

2026-08-17 02:35:45 +00:00

coilyco-ops referenced this issue

2026-08-22 20:54:50 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops added this to the Headless engineer lane: toolchain first milestone

2026-08-22 20:58:17 +00:00