chore(ci): match bulletin-deploy's manual-release flow#123
Closed
UtkarshBhardwaj007 wants to merge 2 commits into
Closed
chore(ci): match bulletin-deploy's manual-release flow#123UtkarshBhardwaj007 wants to merge 2 commits into
UtkarshBhardwaj007 wants to merge 2 commits into
Conversation
The previous release workflow committed `chore: version packages` locally as `github-actions[bot]` and pushed straight to main. That path breaks under branch protection that requires (a) verified signatures, (b) required status checks, and (c) PR review for any change to main — so the workflow has been failing on every push for the last three releases (PRs #120 / #121 / #122). Switch to the canonical changesets/action two-mode flow: - On a push to main while pending changesets exist, the action opens or updates a "Version Packages" PR. The PR carries the version bump and the regenerated CHANGELOG, and goes through the normal protected-branch flow — same review, same checks, same signed commit policy as any human PR. No direct push to main. - Once that PR merges, the workflow re-runs and the action sees no pending changesets, so it invokes the new `scripts/release.sh`. The script tags the release, builds the four SEA binaries, and creates the GitHub Release via `gh release create`. Idempotent: every other push-to-main where no changesets exist is a fast no-op because the tag already exists. Trade-off: each release now requires merging one auto-PR. That doubles as a release approval gate — releases stop being a side-effect of any arbitrary changeset PR landing. Caveat for the org: this needs `Settings → Actions → General → Allow GitHub Actions to create and approve pull requests` enabled. If the paritytech org has it disabled, the action's PR open call will 403 and we'll need a GitHub App token instead. Calling that out in the PR body so we can flip the setting before merge if needed.
Contributor
|
Dev build ready — try this branch: |
Contributor
E2E Test Pass · ✅ PASSTag:
Sentry traces: view spans for this run |
Replaces the changesets/action approach from the previous commit on this branch. The org-level setting "Allow GitHub Actions to create and approve pull requests" is not under our control, and without it changesets/action's PR-mode 403s when trying to open the Version Packages PR. Mirror `paritytech/bulletin-deploy` exactly: no automation pushes to `main`. The maintainer drives the version bump as a normal PR and creates the GitHub Release manually. The workflow only fires on `release: created`, builds the four SEA binaries from the tagged commit, and `gh release upload`s them as Release assets. This bypasses every branch protection rule because the workflow no longer touches `main` — only the tagged commit (read-only) and the Release object (write via `gh`). No `--force` push, no signed-commit workaround, no bypass token. Trade-off vs the previous PR commit: each release is a few manual steps for the maintainer instead of "merge a PR with a changeset and watch it ship." Same trade-off bulletin-deploy already accepted — and the only one that works without org-level settings access. Updated CLAUDE.md "Repo conventions" so contributors know what to do with their changesets and how releases happen.
UtkarshBhardwaj007
changed the title
Member
Author
|
Closing — going with the simpler short-term path: temporarily relax the three blocking branch-protection rules (signed commits / status checks / push restriction), re-run the failed workflow on PR #122's run to ship the accumulated changesets, then re-enable the rules. No workflow change needed; the existing release.yml on main works once the rules don't block the bot's push. |
1 similar comment
Member
Author
|
Closing — going with the simpler short-term path: temporarily relax the three blocking branch-protection rules (signed commits / status checks / push restriction), re-run the failed workflow on PR #122's run to ship the accumulated changesets, then re-enable the rules. No workflow change needed; the existing release.yml on main works once the rules don't block the bot's push. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
The release workflow has failed on the last three pushes to
main(PRs #120, #121, #122). Branch protection onmainrequires:The old
release.ymlignored all three — it committed locally asgithub-actions[bot]and rangit push origin main. Failed runs:This PR mirrors the release flow that
paritytech/bulletin-deployalready runs successfully under the same protection rules.How the new flow works
No automation pushes to
main. Ever. The workflow only reads the tagged commit and writes to the Release object — both of which live entirely outside branch protection.Files changed
.github/workflows/release.yml— replacedpush: branches: [main]trigger withrelease: types: [created]. ~30 lines.CLAUDE.md— updated "Repo conventions" → release section to document the new manual flow.What happens after this PR merges
release: created).release.yml. Binaries get built and attached.Test plan
release.ymlsyntax validgh release uploadis the same call bulletin-deploy effectively uses (vianpm publishin their case — same idea: workflow writes to a Release/registry artefact, never tomain)Trade-offs