The reusable elixir-release.yml workflow assumes it can push the generated release commit and tag directly to the default branch with github.token, and it performs that push after publishing to Hex.pm.
That breaks on repositories where main is protected and requires status checks. In that case the release commit is new and has not satisfied the required checks yet, so GitHub rejects the push. Because Hex publish happens first, the workflow can publish a package successfully and only then fail to push the release commit/tag, leaving GitHub and Hex out of sync.
Example failure:
Relevant workflow lines today:
- Publish to Hex:
mix hex.publish --yes
- Then push:
git push --atomic origin HEAD "refs/tags/$VERSION"
Why this needs fixing in the shared workflow:
contents: write on GITHUB_TOKEN is not enough to bypass branch protection.
- Protected branches with required checks are a normal configuration for release repos.
- The current step order makes the failure non-atomic from a release-management perspective.
Expected behavior:
- If the release commit/tag cannot be pushed, the workflow must not publish to Hex.
- The workflow should either:
- push the release commit/tag successfully before publishing to Hex, or
- support a protected-branch-safe strategy (for example a configurable push token / app token with bypass permissions, or a branch/PR-based mode).
Minimum fix:
- Move
Push changes and tags before Publish to Hex.pm.
- Fail fast on push rejection so Hex publish never runs in that case.
Nice follow-up:
- Add docs/input for protected branch repos explaining that default
github.token cannot push directly unless branch protection allows it.
- Consider an optional
push_token or release_branch/create_pr mode for repos that do not allow direct pushes to main.
This affected a real 2.1.0 release and required manual repair: recreate the release commit locally, fix the tag name, push via a human account/PR, and then create the GitHub release after Hex had already published.
The reusable
elixir-release.ymlworkflow assumes it can push the generated release commit and tag directly to the default branch withgithub.token, and it performs that push after publishing to Hex.pm.That breaks on repositories where
mainis protected and requires status checks. In that case the release commit is new and has not satisfied the required checks yet, so GitHub rejects the push. Because Hex publish happens first, the workflow can publish a package successfully and only then fail to push the release commit/tag, leaving GitHub and Hex out of sync.Example failure:
agentjido/jido_actionremote: error: GH006: Protected branch update failed for refs/heads/main.remote: - 3 of 3 required status checks are expected.Relevant workflow lines today:
mix hex.publish --yesgit push --atomic origin HEAD "refs/tags/$VERSION"Why this needs fixing in the shared workflow:
contents: writeonGITHUB_TOKENis not enough to bypass branch protection.Expected behavior:
Minimum fix:
Push changes and tagsbeforePublish to Hex.pm.Nice follow-up:
github.tokencannot push directly unless branch protection allows it.push_tokenorrelease_branch/create_prmode for repos that do not allow direct pushes tomain.This affected a real
2.1.0release and required manual repair: recreate the release commit locally, fix the tag name, push via a human account/PR, and then create the GitHub release after Hex had already published.