Summary
Fleet Sequential Merge (fleet-merge.yml) intermittently fails at the composite-action loading step with:
##[error]/home/runner/work/knowledgebase/knowledgebase/./.github/actions/fleet-orchestrator-token/action.yml (Line: 54, Col: 18): Unrecognized named-value: 'secrets'. Located at position 1 within expression: secrets.FLEET_APP_ID
##[error]...: Unrecognized named-value: 'secrets'. ...: secrets.FLEET_APP_PRIVATE_KEY
##[error]...: Unrecognized named-value: 'steps'. ...: steps.<id>.outputs.token || secrets.GITHUB_TOKEN
##[error]Failed to load .../.github/actions/fleet-orchestrator-token/action.yml
Evidence this is unrelated to PR #566
Confirmed by comparing multiple Fleet Sequential Merge runs against the same commit SHA (62ffe359a56ffd69bd492e2de61d82af4e9fbed0, PR #566's merge commit):
- Run
31956317723 (2026-08-16T15:39:40Z) — success
- Run
31926901171 (2026-08-16T04:33:03Z) — failure (this exact error)
- Runs
31958717612, 31958597151, 31958171539, 31957755178, 31956389542, 31956227582 — all failure on the identical commit
Since the failure occurs non-deterministically against an unchanged commit, it cannot be caused by #566's jq regex fix — it's a pre-existing, intermittent GitHub Actions runner/template-parsing issue when loading .github/actions/fleet-orchestrator-token/action.yml.
Root cause hypothesis
.github/actions/fleet-orchestrator-token/action.yml contains ${{ secrets.* }} and ${{ steps.* }} expressions inside description strings (comments/docs within the YAML, not executable run:/with: fields), e.g.:
inputs:
app-id:
description: |
FLEET_APP_ID secret value. Caller passes ${{ secrets.FLEET_APP_ID }}.
Composite actions cannot reference secrets.* directly (this is documented in the file's own header comment), and apparently the GitHub Actions runner's manifest template validator sometimes evaluates ${{ }} expressions found inside description: fields as if they were live expressions, producing Unrecognized named-value errors. This appears to be flaky/order-dependent (possibly a runner-version or template-validation-caching difference), since the same file loads fine on other runs.
Git history (git log --oneline -- .github/actions/fleet-orchestrator-token/action.yml) shows this exact class of error has been "fixed" numerous times before (e.g. 4bf84ec, c8bcb0e, 2efccbe, a2aaedd, b345843, c23a236, f4ad32a, f4bd3e0) without a permanent resolution — each fix appears to suppress it temporarily until it recurs.
Impact
Suggested fix direction
Rewrite all ${{ ... }} occurrences inside description: strings in .github/actions/fleet-orchestrator-token/action.yml to avoid the literal ${{ }} token entirely (e.g. use backticks/plain-English or bracket notation like secrets[FLEET_APP_ID] in prose, or split the expression across non-contiguous text so the runner's template scanner doesn't recognize it as an expression). Since previous attempts at this have regressed, add a regression test (tests/kb/test_*.py) that runs actionlint and/or the actual GitHub Actions workflow-manifest parser semantics against action.yml, or at minimum asserts no bare ${{ secrets. / ${{ steps. patterns exist inside description: blocks, so this doesn't silently reappear.
Summary
Fleet Sequential Merge(fleet-merge.yml) intermittently fails at the composite-action loading step with:Evidence this is unrelated to PR #566
Confirmed by comparing multiple
Fleet Sequential Mergeruns against the same commit SHA (62ffe359a56ffd69bd492e2de61d82af4e9fbed0, PR #566's merge commit):31956317723(2026-08-16T15:39:40Z) — success31926901171(2026-08-16T04:33:03Z) — failure (this exact error)31958717612,31958597151,31958171539,31957755178,31956389542,31956227582— all failure on the identical commitSince the failure occurs non-deterministically against an unchanged commit, it cannot be caused by #566's jq regex fix — it's a pre-existing, intermittent GitHub Actions runner/template-parsing issue when loading
.github/actions/fleet-orchestrator-token/action.yml.Root cause hypothesis
.github/actions/fleet-orchestrator-token/action.ymlcontains${{ secrets.* }}and${{ steps.* }}expressions inside description strings (comments/docs within the YAML, not executablerun:/with:fields), e.g.:Composite actions cannot reference
secrets.*directly (this is documented in the file's own header comment), and apparently the GitHub Actions runner's manifest template validator sometimes evaluates${{ }}expressions found insidedescription:fields as if they were live expressions, producingUnrecognized named-valueerrors. This appears to be flaky/order-dependent (possibly a runner-version or template-validation-caching difference), since the same file loads fine on other runs.Git history (
git log --oneline -- .github/actions/fleet-orchestrator-token/action.yml) shows this exact class of error has been "fixed" numerous times before (e.g.4bf84ec,c8bcb0e,2efccbe,a2aaedd,b345843,c23a236,f4ad32a,f4bd3e0) without a permanent resolution — each fix appears to suppress it temporarily until it recurs.Impact
merge-on-ci-passjob before it ever reaches the PR-selection/merge logic, so legitimate fleet PRs (e.g. ⚡ Bolt: Use generator for rglob validation to stream paths to executor #569, correctly detected by fix(fleet): widen fleet-merge.yml author filter to match PAT-based Jules PRs #566's fixed regex) are not auto-merged on affected runs, requiring manual intervention or a lucky re-run.Suggested fix direction
Rewrite all
${{ ... }}occurrences insidedescription:strings in.github/actions/fleet-orchestrator-token/action.ymlto avoid the literal${{ }}token entirely (e.g. use backticks/plain-English or bracket notation likesecrets[FLEET_APP_ID]in prose, or split the expression across non-contiguous text so the runner's template scanner doesn't recognize it as an expression). Since previous attempts at this have regressed, add a regression test (tests/kb/test_*.py) that runsactionlintand/or the actual GitHub Actions workflow-manifest parser semantics againstaction.yml, or at minimum asserts no bare${{ secrets./${{ steps.patterns exist insidedescription:blocks, so this doesn't silently reappear.