Skip to content

fix(ci): grant contents:write to build-native reusable workflow call#632

Open
FritzHeider wants to merge 1 commit into
ruvnet:mainfrom
FritzHeider:fix/release-yml-reusable-workflow-permissions
Open

fix(ci): grant contents:write to build-native reusable workflow call#632
FritzHeider wants to merge 1 commit into
ruvnet:mainfrom
FritzHeider:fix/release-yml-reusable-workflow-permissions

Conversation

@FritzHeider

Copy link
Copy Markdown

Summary

  • release.yml calls build-native.yml as a reusable workflow (uses:) without a permissions: block.
  • build-native.yml's commit-binaries job statically declares permissions: contents: write.
  • GitHub validates every declared job's permissions in a called workflow at parse time, regardless of runtime if: conditions, and rejects the whole run before scheduling any jobs if the caller doesn't grant it.
  • This has made every Release Pipeline run fail with startup_failure (0 jobs, 0 check-runs) since at least 2026-04-20, confirmed via the run page's own annotation:

    The nested job 'commit-binaries' is requesting 'contents: write', but is only allowed 'contents: read'.

  • Fix: add permissions: contents: write to the build-native job in release.yml.

Test plan

  • YAML re-parses cleanly (python3 -c "import yaml; yaml.safe_load(open('.github/workflows/release.yml'))")
  • Confirmed publish-all.yml (which does not call build-native.yml reusably) succeeds on the same tag pushes where release.yml fails — isolates the cause to this reusable-workflow call
  • Maintainer: trigger a workflow_dispatch (dry_run) on release.yml post-merge to confirm it clears startup_failure

release.yml calls build-native.yml via `uses:` without a permissions
block. Its nested commit-binaries job statically declares
`permissions: contents: write`, and GitHub validates every declared
job's permissions in a called workflow at parse time -- regardless of
runtime `if:` conditions -- rejecting the whole run before scheduling
any jobs if the caller doesn't grant it. This has made every
Release Pipeline run fail with startup_failure (0 jobs, 0 check-runs)
since the repo's default Actions token permission was tightened.

Co-Authored-By: claude-flow <ruv@ruv.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant