Skip to content

Fix reusable release workflow rejecting callers that do not grant packages: write #17

Description

@swashbuck

Subject of the issue

The reusable release workflow declares packages: write on its release job. GitHub does not allow a called workflow's job to request more permissions than the caller grants, so any repo using the permissions block documented in the README is rejected before the job is scheduled. The run ends as a startup failure with no logs, which makes it look like a workflow syntax problem rather than a permissions one.

This affects every caller, not just those publishing to GitHub Packages. packages: write was added in #9 (fixes #7), and the README explains it as an extra permission only GitHub Packages callers need, stating that omitting it causes a 403 at publish time. In practice omitting it stops the run from starting at all.

adapt_framework has been silently unable to release since then. Its last successful release was 13 April 2026; every push to master since has failed at startup, for example https://github.com/adaptlearning/adapt_framework/actions/runs/32862936294. adapt_framework is a private package and never publishes to any registry, so it has no use for packages: write.

This also blocks adaptlearning/adapt_framework#3811, which proposes rolling the same four-permission caller template out across all Adapt repos. Every repo migrated with that template would stop releasing.

Steps to reproduce

  1. Add a caller workflow using the permissions block from the README: contents, issues, pull-requests and id-token, all write.
  2. Point the release job at adaptlearning/semantic-release-config/.github/workflows/release.yml@master.
  3. Push a commit to master.

Expected behaviour

The release job runs. Repos publishing to npmjs need only the four documented permissions. Repos publishing to GitHub Packages add packages: write themselves.

Actual behaviour

The run never starts. It is marked as a startup failure with no jobs and no logs, and GitHub reports only that the run "likely failed because of a workflow file issue".

Suggested Fix

Remove the job-level permissions block from the reusable workflow so the job inherits whatever the caller grants. That is already the model the README describes, where the caller's permissions act as the ceiling. It keeps npmjs callers working on the documented four, and GitHub Packages callers keep working by adding packages: write in their own caller.

Note that the block was originally added in b54bf20 to satisfy a code scanning alert about a workflow without a permissions block, so that alert may return and need dismissing for this file.


Posted via collaboration with Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions