fix(workflows): guard pr-labels-ci.yml env against missing workflow_run context

[cmeans-claude-dev]

Summary

Follow-up to PR #24. Attempting to manually dispatch pr-labels-ci.yml on main after PR #24 merged failed with:

Failed to queue workflow run: Invalid Argument - failed to parse workflow: (Line: 55, Col: 14): An expression was expected, (Line: 111, Col: 14): An expression was expected

Root cause

Lines 55 and 111 are run: | — the error message points a line or two late. The actual problem is the step-level env: blocks above them:

env:
  GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  REPO: ${{ github.repository }}
  RUN_ID: ${{ github.event.workflow_run.id }}
  HEAD_BRANCH: ${{ github.event.workflow_run.head_branch }}

github.event.workflow_run is only populated for workflow_run events. For workflow_dispatch (and for the validation pushes GitHub runs on every commit touching workflow files), that path is absent. GitHub evaluates step-level env: expressions at queue time — before the job-level if: gate is checked — so the missing context aborts the whole queue operation.

This is almost certainly the explanation for the pre-#24 push startup-failures in this workflow's run history too: every commit that modified workflow files triggered a GitHub validation push, the env expressions couldn't resolve, the run failed at queue time, and the workflow was never registered in GitHub's catalog. That's why workflow_run dispatches never routed to it.

Fix

Add null-coalesce fallbacks on the two workflow_run references, in both jobs:

RUN_ID: ${{ github.event.workflow_run.id || '' }}
HEAD_BRANCH: ${{ github.event.workflow_run.head_branch || '' }}

Behavior matrix:

• workflow_run (CI success on PR branch). github.event.workflow_run.id resolves to a real number; the fallback is never exercised. Job-level if: passes; on-ci-pass promotes the PR to Ready for QA. Unchanged from today's happy path.
• workflow_run (CI failure). Same — real number resolves, fallback unused. on-ci-fail branch marks CI Failed. Unchanged.
• workflow_dispatch (manual seeding). github.event.workflow_run.id resolves to null; the fallback yields empty string; env vars are set to empty strings; job-level if: fails (null is not equal to 'success'); both jobs skip. Run completes as "successful skipped" — which is exactly what registers the workflow with GitHub's catalog.
• push (validation on commits that touch workflow files). Same as workflow_dispatch — null resolves cleanly, jobs skip. This should end the streak of startup-failure entries in the workflow's run history.

Post-merge plan

After merge, try the manual dispatch again:

• https://github.com/cmeans/yt-dont-recommend/actions/workflows/pr-labels-ci.yml
• Click Run workflow → select main → Run workflow

Expected: both jobs skip, run completes in ~5 seconds with status "success" (both jobs shown as "skipped"). After that, the workflow's sidebar name should start resolving to "PR Label Automation (CI)" instead of the raw file path, and workflow_run dispatches should finally route there.

Cascade

cmeans/mcp-clipboard has the same expressions without fallbacks. The bug is latent there because they've never dispatched manually, but the fallback is strictly more defensive (zero behavior change on the working path) and preserves the verbatim-from-mcp-clipboard contract. Recommend cascading as a follow-up PR.

Test plan (QA)

• yaml.safe_load on the file — clean parse
• Diff shows exactly two lines changed in each of the two jobs (4 total line changes): adding the null-coalesce fallback
• No behavior change on workflow_run happy path
• After merge + manual workflow_dispatch: run completes successfully (both jobs skipped), workflow gets a clean registration
• Next PR after registration: auto-promotes Awaiting CI → Ready for QA on CI success without the Dev Active toggle

Caveat

This PR will itself stick at Awaiting CI since it doesn't fix the already-stuck registration — only post-merge does that. Expect the Dev Active toggle dance one more time.

🤖 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]

LGTM

[cmeans]

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

Verified in this session

Check	Result
YAML parse of pr-labels-ci.yml	Clean; both jobs on-ci-pass and on-ci-fail resolve.
Diff shape	Exactly 4 lines changed: 2 per job, identical || '' fallback added to RUN_ID and HEAD_BRANCH. No other content touched.
workflow_run happy-path behavior	When github.event.workflow_run.id exists (i.e. CI-completion dispatches), it's truthy, so || '' never fires. RUN_ID and HEAD_BRANCH resolve to the real values, and both env vars are identical to today. Zero behavior change on the path that actually promotes PRs.
workflow_dispatch / push path	With workflow_run context absent, the .id / .head_branch lookups return null, || '' converts to empty strings, env vars set successfully, queue-time parse succeeds. Job-level if: conditions (which reference .conclusion == 'success' etc.) evaluate false against null and skip the job. Clean successful-skipped run.
pytest tests/	259/259 pass (non-code change).
ruff check src/ tests/	All checks passed!

Root cause — independently plausible

The Invalid Argument - failed to parse workflow: ... An expression was expected error pointing at run: \| lines is a recognized GitHub pattern for step-level env: expressions that resolve to null. GHA evaluates step-level env at queue time and the null value is rejected as an invalid env value (the error message reports the column of the next line, which is why it looked like the run: block itself was the problem). The \|\| '' fallback is the documented, zero-risk hardening pattern for this class of issue.

Dev's secondary claim — that this also explains the pre-#24 event=push conclusion=failure streak in this workflow's run history — is consistent: every commit touching workflow files triggers a GHA validation push, which would hit the same queue-time env resolution. If that's right, the fix should also end the startup-failure streak going forward. Directly observable post-merge.

Verdict

Applying Ready for QA Signoff. Zero findings.

Post-merge action (for you)

Same playbook as #24 called out:

1. Actions → PR Label Automation (CI) → Run workflow → main → Run workflow. Expect ~5s, both jobs skipped, status success.
2. Confirm actions/workflows reports name = "PR Label Automation (CI)" rather than the file path — registration proof.
3. Next PR should auto-promote Awaiting CI → Ready for QA on CI pass without the Dev Active toggle.

Worth also glancing at the workflow's run history afterwards to see if the push-event startup-failure streak actually stops.

Cascade

Extended the existing tracker — cmeans/mcp-clipboard#89 — to cover this \|\| '' fallback alongside the workflow_dispatch addition. Same commit can ship both to mcp-clipboard; they're the same underlying concern (make pr-labels-ci.yml safe to run on non-workflow_run events).