ci(release): give the bindings a release trigger after a core release - #2663
Open
goldmedal wants to merge 1 commit into
Open
ci(release): give the bindings a release trigger after a core release#2663goldmedal wants to merge 1 commit into
goldmedal wants to merge 1 commit into
Conversation
goldmedal
force-pushed
the
ci/release-bindings-after-core-release
branch
from
August 11, 2026 09:34
52d3b23 to
1341b07
Compare
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThis change adds a reusable workflow that synchronizes Python and WASM binding lockfiles after a core release. It validates versions, checks lockfile changes, and creates a binding release pull request. Release configuration no longer tracks these lockfiles. ChangesBinding release synchronization
Estimated code review effort: 4 (Complex) | ~45 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release-bindings-after-core.yml:
- Around line 127-166: Update the “Open the binding release PR” workflow step to
use a PAT or GitHub App installation token for both the authenticated git push
and gh CLI operations, replacing github.token/GH_TOKEN with the configured
elevated credential while preserving the existing branch and PR logic.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: b825254c-1bd2-44e8-a795-a0226ad93247
📒 Files selected for processing (3)
.github/workflows/release-bindings-after-core.yml.github/workflows/release-please.ymlrelease-please-config.json
wren-core-py and wren-core-wasm depend on the Rust core by path alone, and release-please attributes commits to packages by file path. An engine change under core/wren-core is therefore attributed to wren-semantic-core and never to the bindings: no release PR is opened for them, and the core release commit is a chore commit release-please skips by design, so it cannot be the trigger either. The engine change reaches crates.io and never reaches PyPI or npm. Move the binding lockfile refresh out of the release commit — where release-please performed it through extra-files — into a workflow that runs after the core release. It relocks both bindings against the released crates and opens a PR whose fix commit touches both binding directories, which is exactly what release-please needs in order to open their release PRs. This reverses the direction of "ci(core): sync downstream lockfile during Rust releases" deliberately. Doing the sync inside the release commit keeps the tree tidy, but it also means the only commit that records the new engine version is one release-please skips — so the bindings can never release. No workflow builds the bindings with cargo --locked, so the lag between the release commit and the sync PR breaks no job, and the bindings' release tags are cut after the sync PR merges, so a published wheel still ships a synced lockfile. Verified against a simulated 0.3.1 -> 0.4.0 core release: the refresh step rewrites exactly the three linked crates in both lockfiles and nothing else, and the assertion step passes on the refreshed locks while failing on a stale one.
goldmedal
force-pushed
the
ci/release-bindings-after-core-release
branch
from
August 11, 2026 09:42
1341b07 to
84a20ef
Compare
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.
Follow-up to #2659, which unblocked one
wren-core-pyrelease by hand. This closes the gapso it does not need doing by hand again, and covers
wren-core-wasmtoo.Problem
wren-core-pyandwren-core-wasmdepend on the Rust core by path alone, andrelease-please attributes commits to packages by file path. An engine change under
core/wren-coreis attributed towren-semantic-coreand never to the bindings, so norelease PR is ever opened for them — and the core release commit is a
chore(main): release …commit release-please skips by design, so it cannot be the trigger either.
The result: an engine change reaches crates.io and never reaches PyPI or npm. The published
wren-core-pywheel is 0.7.3, built against the pre-0.3.x engine;wren-core-wasm0.4.1 is inthe same position.
Change
release-bindings-after-core.yml, called fromrelease-please.ymlwhen the core cratesrelease. It relocks both bindings against the released crates, asserts the lockfiles record
the released version, and opens a PR whose
fixcommit touches both binding directories —which is what release-please needs in order to open their release PRs. Modelled on the
existing
sync-wren-core-py-lock.yml(same checkout, token handling, branch reuse andmanual-dispatch fallback).
release-please-config.json: drop the bindingCargo.lockentries from the core crates'extra-files; that refresh is now the follow-up workflow's job.Not gated on
publish-wren-crates: a crates.io publish failure should not also keep the enginechange out of PyPI and npm.
This reverses a deliberate choice — why
#2484 moved the binding lockfile sync into the release commit. That keeps the tree tidy,
but it also means the only commit recording the new engine version is one release-please skips,
so the bindings can never release. The tidiness is worth less than a release path.
The lag it reintroduces is bounded and harmless: no workflow builds the bindings with
cargo --locked(core-py-ciandwasm-cirun plaincargo test/wasm-pack build), so alockfile one release behind breaks no job. And because the bindings' release tags are cut
after the sync PR merges, a published wheel or npm package still ships a synced lockfile.
Verification
Simulated a 0.3.1 → 0.4.0 core release locally (bumped the three linked crates the way the
release commit does, including the engine pin from #2659) and ran the workflow's own step
scripts, extracted from the YAML:
Locking 3 packagesin each binding —wren-semantic-core,wren-core-base,wren-manifest-macro— for a 3-line diff per lockfile and nothing else touched.::error::when onelockfile is left stale.
run:script syntax-checked (bash -n,ast.parse); both workflow files and therelease-please config parse.
Merge order
Rebased onto
mainafter #2659 landed; theextra-filesentry #2659 added (the engine pin incore/wren-core-py/Cargo.toml) is kept, and only the two binding lockfile entries are removed.The simulation above was re-run on the rebased tree, with the real pin in place, and produced
the same result.
#2659 also confirms the mechanism end to end: merging a
fixcommit undercore/wren-core-pyproduced release PR #2662 (chore(main): release wren-core-py 0.7.4). ThisPR makes that step happen on its own, for both bindings.
Summary by CodeRabbit