ci: automate releases with release-please - #479
Merged
Conversation
Replaces the manual release process (hand-bumped package.json versions, manually created tags/releases, workflow_dispatch publishing) with release-please: - release-please.yml maintains a release PR on every push to main, generating CHANGELOG.md from the conventional commit history already enforced by lint-pr-title.yml - Merging the release PR creates the tag and GitHub release - publish-bindings.yml now also triggers on release publication, checking out the release tag so the npm package matches the tagged commit exactly (workflow_dispatch kept as fallback) - Manifest bootstrapped at 0.1.2-rc.10 (latest version on npm) so the first release PR proposes 0.1.2-rc.11 - Prerelease versioning keeps the rc train (rc.N -> rc.N+1); flip "prerelease": false to graduate to a stable release - build.zig.zon version now tracked via the generic updater annotation instead of drifting at 0.0.0 See RELEASING.md for the full process. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The v0.1.2-rc.10 tag points to a commit that is not on main, so release-please cannot anchor the first changelog range and would walk the entire history. bootstrap-sha pins the first release PR to collect commits since the v0.1.2-rc.9 release commit (the last release cut from main); it is ignored once release-please creates its first release. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
bootstrap-sha is only consulted when no prior release is found, but release-please finds v0.1.2-rc.10 via the manifest and then fails to locate its off-main SHA on the branch, walking the entire history. last-release-sha overrides the detected release SHA directly. It is never ignored automatically, so it must be removed after the first release-please release is merged (documented in RELEASING.md). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
workflow_dispatch on arbitrary refs is how v0.1.2-rc.10 got published from an off-main commit; keeping it as a fallback makes the reviewed release-PR gate optional. Publishing now happens exclusively on release publication, with two fail-fast guards: - release-please refuses to run without RELEASE_PLEASE_TOKEN (the default GITHUB_TOKEN cannot trigger the publish workflow, so a missing token would create releases that silently never reach npm) - publish-bindings refuses to publish if the release tag does not match package.json, blocking hand-created releases from arbitrary commits Failed publish runs are retried with `gh run rerun`, which re-executes against the same tag. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ement Publishing previously chained off the release event, which requires a non-default token (GITHUB_TOKEN events do not trigger workflows). Run publish as a job in the same workflow run instead, gated on the release-please release_created output — the same pattern js-libp2p-quic uses. No secrets required. - The workflow file keeps the publish-bindings.yml name so the npm trusted publisher config keeps matching - The publish job runs on the release PR merge commit, which is exactly the tagged commit; hand-created GitHub releases trigger nothing - The tag/version guard is obsolete under same-run gating and is removed - Remaining default-token limitation: CI does not auto-run on release PRs; close/reopen the PR to trigger it (documented in RELEASING.md) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The workflow is self-evident from the config and workflow files; the one-time bootstrap cleanup (last-release-sha) is tracked on the PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Release PR CI runs are created automatically; they may be held in action_required state pending one-click approval, not missing entirely (verified against ssz and js-libp2p-quic release PR run history). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Rationale lives in the PR description. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The first release-please release will be the stable v0.1.2, published to the npm latest dist-tag. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
wemeetagain
commented
Jul 10, 2026
wemeetagain
commented
Jul 10, 2026
Co-authored-by: Cayman <caymannava@gmail.com>
22 tasks
This was referenced Jul 15, 2026
spiral-ladder
previously approved these changes
Jul 15, 2026
spiral-ladder
previously approved these changes
Jul 16, 2026
nazarhussain
self-requested a review
July 16, 2026 11:14
nazarhussain
left a comment
nazarhussain
left a comment
Contributor
There was a problem hiding this comment.
One finding worth mentioning.
One cosmetic caveat (not a correctness problem): the 0.1.2 side branch carried one real commit beyond the merge-base — e4f6cad "bindings(pubkeys): add reset api". That exact commit never landed on main, but the same functionality arrived on main via b8ec273 "feat(bindings): align BeaconStateView with IBeaconStateView (#347)", which sits inside the scan range. So the 0.1.3 changelog will list #347 even though part of its content (the pubkeys reset API) already shipped in 0.1.2.
6 tasks
matthewkeil
previously approved these changes
Jul 16, 2026
Member
|
@wemeetagain and @nazarhussain I updated this a bit to help reduce publish failures. Added a build step to the CI to make sure that cross-compliation works as expected before we merge a PR. This will prevent that failing the publish step when the release PR is merged. |
matthewkeil
previously approved these changes
Jul 16, 2026
nazarhussain
previously approved these changes
Jul 17, 2026
wemeetagain
dismissed stale reviews from nazarhussain and matthewkeil
via
July 23, 2026 20:39
a163cfb
matthewkeil
previously approved these changes
Jul 29, 2026
matthewkeil
approved these changes
Jul 29, 2026
spiral-ladder
approved these changes
Jul 29, 2026
github-project-automation
Bot
moved this from In Review
to Done
in Lodestar Team Coordination
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
5 participants
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.
Motivation
Our release process is manual and opaque: versions are hand-bumped in
package.jsonvia PR, tags and GitHub releases are created by hand, and publishing is a manualworkflow_dispatchrunnable on any ref. This has led to drift — right nowv0.1.2-rc.10is on npm and GitHub releases, but its tag points to a commit that isn't onmain, andmain'spackage.jsonstill says0.1.2-rc.9(see #477 / #478).Resolves #505