fix(workflows): extract workflow_run fields via jq from $GITHUB_EVENT_PATH

[cmeans-claude-dev]

Summary

QA's proposed approach after PR #26's 'none' fallback also failed to fix the queue-time parse error. Diagnostic confirmed the workflow is still unregistered in GitHub's catalogue (name field on the API still reports the file path, not "PR Label Automation (CI)").

Strategy: eliminate the ${{ }} expression surface on workflow_run fields entirely. Read them from the event payload on disk via jq.

Change (+34 / −9, one file)

For both on-ci-pass and on-ci-fail:

• Remove RUN_ID and HEAD_BRANCH from step-level env: (the only remaining ${{ github.event.workflow_run.* }} sites outside job-level if:).

• At the top of each run: block, add:

  RUN_ID=$(jq -r '.workflow_run.id // empty' "$GITHUB_EVENT_PATH")
  HEAD_BRANCH=$(jq -r '.workflow_run.head_branch // empty' "$GITHUB_EVENT_PATH")

• Add a defensive early-exit if RUN_ID is empty — belt-and-suspenders for the existing if: guard.

Why this might succeed where || '' / || 'none' didn't

All three of my prior attempts modified step-level env expressions. GitHub's queue-time parser kept returning the same error at run: | in both jobs. The suspected cause shifted from "missing context" to "|| fallback" to "empty-string literal" — none of those fixes worked.

The jq path routes around the expression surface entirely:

• No ${{ }} in the workflow_run fields. Whatever GitHub's queue-time parser disliked about the env expressions can't fire here — there's no such expression.
• $GITHUB_EVENT_PATH is always set on GitHub-hosted runners, on every event type, per official docs. Canonical way to read the raw event.
• jq is pre-installed on all ubuntu-latest / macos-latest images. No install step.
• Same shell-injection protection as env:. jq -r writes raw bytes to stdout; command substitution captures them into a shell variable; every subsequent use is "$HEAD_BRANCH" quoted. Byte-equivalent safety to the prior env pattern.

Unchanged

• Job-level if: guards still reference github.event.workflow_run.* (identical to mcp-clipboard's working version). These use && and should short-circuit cleanly on non-workflow_run events.
• All downstream logic (PR lookup, label checks, label edits) is untouched.
• on-ci-pass and on-ci-fail happy-path behavior is identical to today's.

Decision rule

• If this works (manual dispatch succeeds, jobs skip, workflow registers): the root cause was the step-level env expression surface; document the gotcha and move on.
• If this still returns the same parse error: the root cause is in the job-level if: surface (or elsewhere entirely). Revert PRs fix(workflows): add workflow_dispatch to pr-labels-ci.yml to prime workflow_run listener #24, fix(workflows): guard pr-labels-ci.yml env against missing workflow_run context #25, fix(workflows): use 'none' instead of '' as null-coalesce fallback in pr-labels-ci.yml #26, and this one in a single cleanup PR, restore byte-parity with cmeans/mcp-clipboard, document the Dev Active toggle as the permanent workaround in CLAUDE.md. Stop spending time on the seeding path.

Test plan (QA)

• yaml.safe_load on the file — clean parse (verified locally)
• Confirm no ${{ github.event.workflow_run.* }} expressions remain outside job-level if: guards
• jq paths use // empty so missing keys resolve to empty string, not "null"
• Double-quoted usages of $RUN_ID and $HEAD_BRANCH preserved everywhere (no shell-injection regression)
• on-ci-pass and on-ci-fail happy-path behavior unchanged on real workflow_run events
• After merge: manually dispatch at https://github.com/cmeans/yt-dont-recommend/actions/workflows/pr-labels-ci.yml — report whether the queue error recurs or the run succeeds (both jobs should skip via the job-level if: on a workflow_dispatch event; if they don't skip, the defensive early-exit catches it)
• Post-dispatch diagnostic: gh api repos/cmeans/yt-dont-recommend/actions/workflows/pr-labels-ci.yml --jq '.name' — watch for "PR Label Automation (CI)"

Caveat

Same as PRs #24 / #25 / #26 — this PR itself will stick at Awaiting CI because the fix only activates post-merge-and-seed. Expect the Dev Active toggle once more.

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cmeans]

[QA] Review — zero findings, Ready for QA Signoff.

Verified in this session

Check	Result
YAML parse	Clean. on: carries workflow_dispatch + workflow_run.
No remaining step-level ${{ github.event.workflow_run.* }}	Confirmed via grep -n "github.event.workflow_run" .github/workflows/pr-labels-ci.yml — all 6 remaining hits are inside job-level if: guards (lines 44–46 and 117–119), which is what we want.
jq paths use // empty	Both RUN_ID and HEAD_BRANCH extractions use // empty → missing key produces zero bytes on stdout → $RUN_ID="".
Shell-injection safety preserved	$HEAD_BRANCH is always double-quoted (--head "$HEAD_BRANCH"); $RUN_ID is interpolated into a URL path only (GitHub-generated numeric ID, not contributor-controlled).
Happy-path behavior	jq -r '.workflow_run.id // empty' reads the same value that ${{ github.event.workflow_run.id }} would have produced. Byte-identical RUN_ID/HEAD_BRANCH values feed the exact same downstream script. Zero change on the path that promotes PRs.
pytest tests/	259/259 pass.
ruff check src/ tests/	Clean.

jq semantics sanity-check

Ran three cases against synthetic event files:

• Happy path ({"workflow_run":{"id":12345,"head_branch":"foo/bar"}}) → RUN_ID='12345', HEAD_BRANCH='foo/bar' ✓
• Missing context ({"other":"thing"}) → both empty strings ✓ (early-exit fires)
• Injection attempt (head_branch = "foo;rm -rf /;#") → HEAD_BRANCH='foo;rm -rf /;#' captured as a single literal value; quoted usage downstream means no shell interpretation ✓

Diagnostic finding worth flagging

While validating the fix I pulled the run history for mcp-clipboard's pr-labels-ci.yml too, to cross-check:

Repo	API name field	workflow_run runs	push/failure runs
cmeans/mcp-clipboard	.github/workflows/pr-labels-ci.yml (path)	8 (success + skipped)	2
cmeans/yt-dont-recommend	.github/workflows/pr-labels-ci.yml (path)	0	16

mcp-clipboard shows the exact same name == path symptom, but still dispatches workflow_run events normally. So name == path is not a reliable diagnostic for non-registration — it's just how the API reports workflows whose declared name: hasn't propagated yet. The real signal is workflow_run runs > 0, and that's what we're actually trying to unstick.

Practical consequence: after merging #27, the better post-merge check is "does a new workflow_run run (success or skipped) appear in the history after the next CI completes on a PR?" rather than "did the name field flip?" The name may or may not flip independently.

On the fix itself

This is the right structural change regardless of whether it fixes the registration issue. Moving contributor-influenced context from step-level env: (queue-time evaluation) to jq reads of $GITHUB_EVENT_PATH (step-time) is strictly safer and more forgiving, and the defensive early-exit is a reasonable belt-and-suspenders over the if: gate. If the registration still doesn't recover, the code we're left with is still better than where we started — the revert path is clean either way.

Verdict

Applying Ready for QA Signoff. Zero findings. Post-merge: try the manual dispatch as planned, but also watch the next PR's CI completion for a workflow_run entry in pr-labels-ci.yml's run history — that's the ground truth.