You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
github-shared.yml@v0.16.2 fails with startup_failure when called cross-repository #179
Follow-up to #175/#176 (labels check 403, fixed in v0.16.2). After bumping dupmachine/flightdeck-config's github.yml from github-shared.yml@v0.16.1 to @v0.16.2, every single run fails with startup_failure - a workflow-parse/dispatch-time failure with zero jobs created. This is distinct from the earlier 403: no check-run is posted at all (confirmed via gh api repos/{repo}/commits/{sha}/check-runs - the run simply doesn't appear), so it's invisible in the PR checks UI, not just failing loudly.
Result: startup_failure, reproduced across 7 consecutive attempts including fresh git commit --allow-empty dispatches (not just reruns of a stale attempt) spanning several minutes, ruling out propagation delay after the tag was cut. Example run: https://github.com/dupmachine/flightdeck-config/actions/runs/32830117795
Content variations tried, all fail identically:
with with: skip: [...]
without any with: block at all
different skip array contents
What changed between v0.16.1 (works) and v0.16.2 (fails)
The only diff in github-shared.yml itself is the job's permissions: block gaining issues: read (the #176 fix):
github-config-check:
runs-on: ubuntu-latestpermissions:
contents: readissues: read # <- new in v0.16.2
Isolating the cause
An isolated test workflow directly in dupmachine/flightdeck-config (not a reusable workflow call - just a plain job in that repo) with the exact same permission set succeeds fine:
So issues: read isn't blocked in this repo/org in general - the failure seems specific to a reusable workflow's job requesting issues: read (alongside contents: read) when called cross-repository. embedder-shared.yml's job (permissions: contents: read only) and lint-shared.yml's job (no permissions block) both work fine cross-repo at v0.16.2 - github-shared.yml is the only shared workflow with two explicit permission keys, and the only one failing.
Current workaround
Pinned github.yml back to github-shared.yml@v0.16.1 (with skip: '["labels", "autoMergeAllowed"]', since v0.16.1 still has the original #175 labels bug). Everything else in that repo is on v0.16.2 fine.
Resolved on the consumer side, not a baseline bug: the calling job needs its own explicit permissions: block matching what the reusable workflow's job requests, in addition to (not instead of) the reusable workflow's own declaration - for cross-repository uses: calls, GitHub apparently requires this explicit grant on the caller's job or the whole call fails at dispatch time (startup_failure, no check-run posted at all).
Might be worth a one-line note in this repo's own README/example for github.yml callers, since embedder-shared.yml/lint-shared.yml callers didn't need this (their reusable jobs only ever requested a single permission or none), so it wasn't obvious until a second scope got added.
Activity
ineedjet commentedon Aug 25, 2026
Resolved on the consumer side, not a baseline bug: the calling job needs its own explicit
permissions:block matching what the reusable workflow's job requests, in addition to (not instead of) the reusable workflow's own declaration - for cross-repositoryuses:calls, GitHub apparently requires this explicit grant on the caller's job or the whole call fails at dispatch time (startup_failure, no check-run posted at all).Fix in dupmachine/flightdeck-config#50:
Might be worth a one-line note in this repo's own README/example for
github.ymlcallers, sinceembedder-shared.yml/lint-shared.ymlcallers didn't need this (their reusable jobs only ever requested a single permission or none), so it wasn't obvious until a second scope got added.🤖 Generated with Claude Code