🐛 release.yml is registered with an unparsed definition — emits log-less failing push runs

[clubanderson]

Problem

GitHub has release.yml registered with an unparsed definition, even though the file declares a name on line 1 and is valid YAML. It is the only workflow in the repository in this state.

$ gh api repos/kubestellar/hive/actions/workflows
  Build and Push Docker Image   state=active  path=.github/workflows/docker.yml
  Release Line Guard            state=active  path=.github/workflows/release-line-guard.yml
  Release Lines Gate            state=active  path=.github/workflows/release-lines-gate.yml
  .github/workflows/release.yml state=active  path=.github/workflows/release.yml    <-- fallback name

Every healthy workflow reports its declared name:. release.yml reports its path, which is the fallback GitHub uses when it cannot resolve the definition. Meanwhile:

$ head -1 .github/workflows/release.yml
name: Tagged Release

and the file parses cleanly with yaml.safe_load.

Observable symptom

The repository is emitting push-event runs of release.yml that fail instantly with zero jobs and no logs, despite the workflow declaring only workflow_run:

18:39  push          name=".github/workflows/release.yml"  failure
18:38  push          name=".github/workflows/release.yml"  failure
18:36  push          name=".github/workflows/release.yml"  failure
18:36  workflow_run  name="Tagged Release"                 skipped
18:34  workflow_run  name="Tagged Release"                 skipped

The correlation is exact: runs carrying the fallback name are push-triggered and fail with no jobs; runs carrying Tagged Release are workflow_run and behave normally. GitHub's UI reports "This run likely failed because of a workflow file issue."

These appear whenever a branch touches release.yml — observed on PR branches for #5334, #5332, and #5329.

Why it matters

1. It manufactures false failures. A red, log-less run against release.yml is indistinguishable at a glance from a genuine release failure. It cost real triage time today, and it is very likely the source of the "log-less failed runs" that [ci-maintainer] Tagged Release 5th recurrence, new root cause evidence: required status context 'tide' never reports — release PR #5319 stuck BLOCKED/PENDING through full 120s retry window #5324 attributed to scratch-branch deletion.
2. It may not be cosmetic. A definition GitHub cannot fully resolve is a poor foundation for the one workflow that holds contents: write and cuts releases. Whether the push runs are the only consequence is unverified.

Not caused by the recent fix

The earliest instance is on the unmerged branch of #5334, before it landed, and further instances appear on #5332 and #5329. #5334 did not add a push trigger — release.yml declares workflow_run only, before and after.

What to investigate

1. Why the definition does not resolve. The file is valid YAML with a line-1 name:, so the cause is something GitHub's workflow parser rejects that a YAML parser accepts — a bad on: shape, an unresolvable expression, a duplicate key, or an encoding artifact. Compare against a healthy neighbour.
2. Whether re-registration clears it. Renaming the workflow file and renaming it back, or an empty commit touching it, may force a fresh parse. Worth trying before deeper work.
3. Whether any real behavior is affected, or only the run-name and the spurious push runs.

Verification

• gh api repos/kubestellar/hive/actions/workflows reports Tagged Release for release.yml.
• Touching release.yml on a branch produces no push-event run.
• No log-less zero-job failures appear for this workflow.

Related

• [ci-maintainer] Tagged Release 5th recurrence, new root cause evidence: required status context 'tide' never reports — release PR #5319 stuck BLOCKED/PENDING through full 120s retry window #5324 / 🔧 fix(release): merge on SHA evidence instead of the tide-blocked mergeStateStatus #5334 — the merge-step failure; this is a distinct problem found during that verification.
• 🐛 release never cuts: every run defers to its successor, which defers again #5318 — the deferral loop, still open.

[kubestellar-hive]

Thanks for filing this issue! To help us reproduce and investigate, could you please include the commit SHA of the build you're running?

You can find it by running:

git rev-parse --short HEAD

Or check the bottom of the console UI for the version string.

This issue will be on hold until a SHA is provided. Simply add a comment with the SHA and the hold will be automatically removed.

[clubanderson]

Escalating: this has fully disabled the release pipeline, and it is the actual blocker for v4.0.1

I filed this as an odd registration state producing spurious push runs. It is worse than that — the unparsed definition means GitHub is not reading the on: block at all, so the workflow_run trigger is not registered.

Evidence

Two docker builds on v4 completed successfully this evening:

18:44:51  31640cc4  completed/success
18:39:11  b31779e8  completed/success

release.yml declares:

on:
  workflow_run:
    workflows: ["Build and Push Docker Image"]
    types: [completed]

and docker.yml is registered under exactly that name:

name="Build and Push Docker Image"

Neither successful build fired a release run. The newest workflow_run release run remains 33425941712 at 18:36:20 — before either build completed. The trigger is simply not firing.

Why this matters more than the spurious push runs

This makes every other release fix unverifiable. #5334 corrected the merge step (#5324), but that code has never executed — no release run has started since it merged, so the SHA-based merge path is untested in production. The same applies to #5286 and every earlier fix in this chain.

It also explains a symptom I misattributed on #5318. I argued there that cancelled docker runs were starving the release. Cancelled builds are real and do cost release opportunities, but they are not sufficient: two builds did complete and still produced nothing. The trigger being unregistered is the whole explanation.

Current state

latest tag:    v4.0.0  (2026-08-27)
v4 tip:        7a0faa5c
release runs:  none since 18:36:20, despite 2 successful builds after it

Priority

This should be fixed before any further work on #5318's deferral logic — that logic cannot run at all while the workflow is in this state, so debugging it is debugging something unreachable.

Remediation to try in order:

1. An empty commit touching release.yml to force re-registration.
2. Rename the file and rename it back, which creates a fresh workflow record.
3. If neither clears it, the definition contains something GitHub's workflow parser rejects that a YAML parser accepts — bisect the file against a known-good neighbour.

A workflow whose on: block is silently ignored while the file looks valid in review is a bad failure mode for the one workflow holding contents: write.

[clubanderson]

Root cause found — the record, not the file. Fix in #5347.

Confirmed your diagnosis and narrowed it to an exact cause and boundary.

The file is provably innocent. Beyond what you already ruled out, I checked the one hypothesis that would have made those push runs legitimate: no revision of this workflow on any branch has ever declared a push: trigger. Checked v4, v5 (which carries an older 340-line copy), and 8352c900 — the branch #5334 was developed on, which produced the first spurious push run at 18:28:23. All three declare workflow_run only.

The boundary is exact. The workflow record's updated_at is 18:36:51 — the second PR #5334's merge commit 22649407 landed on v4. Sorting all 801 runs of workflow 343943599 across that moment:

18:36:20  workflow_run  bb52796e  skipped   name=Tagged Release
--------- 18:36:51: record updated_at ---------
18:36:51  push          22649407  failure   name=.github/workflows/release.yml
18:38:46  push          3bff6114  failure   name=.github/workflows/release.yml
18:39:09  push          b31779e8  failure   name=.github/workflows/release.yml

Before that instant, workflow_run runs fired continuously and reported the parsed name Tagged Release. After it, zero workflow_run runs and only path-named push runs. #5334's diff touches only comments and the merge step — no on:, permissions: or jobs: line — so nothing in the change can explain it.

One detail worth recording, because it sharpens what "unparsed" means here: the push runs fire one second before each commit's docker.yml run is created (18:44:50 vs 18:44:51, 18:59:03 vs 18:59:04, 19:07:22 vs 19:07:23). They are firing on the push to v4 itself, not on a build completing — which is exactly what a workflow with no readable on: block looks like when GitHub falls back to a default push trigger.

So the corruption is in GitHub's registration record, not in the tree. That cannot be repaired in place, which is why option 1 (an empty commit) was unlikely to clear it — the record is keyed to the path and re-reading the same path re-uses the same broken record.

Fix: option 2, the rename. #5347 renames the file to .github/workflows/tagged-release.yml, forcing GitHub to register a fresh workflow record. All references updated; the only functional one was src/scripts/test-release-push-retry.sh, which extracts the merge step by path. The rest are comments and docs. No trigger, permission, gate-wait, tag-refusal or merge-path logic changed, and the extraction test passes against the renamed file.

Your predicted secondary symptom resolves with it: the job-less push failures were the same broken record, which also means the part of #5324 attributing them to a scratch branch deleted mid-run should be revisited, as you noted.

Verification after merge is not "does the old record heal" — it will keep listing .github/workflows/release.yml until GitHub ages it out. It is that a new record appears for tagged-release.yml reporting Tagged Release, and that the next successful docker.yml build on v4 fires a workflow_run release run. I'll confirm both once it lands.

[clubanderson]

Reopening — the rename did NOT fix it

#5347 renamed release.yml → tagged-release.yml, which created a brand-new workflow record. That record is also unparsed:

$ gh api repos/kubestellar/hive/actions/workflows
  "Release Line Guard"                      .github/workflows/release-line-guard.yml
  "Release Lines Gate"                      .github/workflows/release-lines-gate.yml
  ".github/workflows/tagged-release.yml"    .github/workflows/tagged-release.yml   <-- still the fallback

The file declares name: Tagged Release on line 1 and parses cleanly with yaml.safe_load.

This is actually a useful result: it rules out stale registration entirely. A fresh record built from the same content lands in the same state, so the cause is IN THE FILE, not in GitHub's memory of the old one.

What is now ruled out

• Stale/sticky registration (the rename disproved it)
• Invalid YAML
• Missing or misplaced
• BOM, tabs, control characters, duplicate top-level keys
• Top-level structure — key order is ////, identical to the healthy

The remaining structural difference

has a 97-line comment block between (line 1) and (line 99). has at line 3. Every line in that block starts with , so a YAML parser skips it — but it is the one gross structural difference between the broken workflow and its healthy neighbours.

Worth testing directly: move the comment block below (or into a separate doc) so sits within the first few lines, and see whether the name resolves. That is a cheap, reversible experiment and would either identify the cause or eliminate the last structural hypothesis.

If that does not work, the next step is bisecting the file against a minimal known-good workflow — halve the content, re-register under a new filename, repeat.

Why this still matters

Nothing downstream of the trigger can run. Every release fix in the chain (#5286, #5334, #5347's merge-step work) remains unverified in production, and v4.0.1 has not cut since 2026-08-27. #5318 was auto-closed by #5347's merge as well; its backstop logic is equally unreachable while the workflow does not register.