fix: update release-plz and skip publish verification for wasm32#1532
fix: update release-plz and skip publish verification for wasm32#1532r-near wants to merge 3 commits into
Conversation
The pinned v0.3.151 had two bugs that caused the release to fail: - gix slotmap overflow when verifying crates.io index (fixed in v0.3.156) - not recognizing already-published crates on re-run (fixed in v0.3.155) Move CARGO_BUILD_TARGET into .cargo/config.toml so cargo-binstall (used by newer action versions) doesn't try to install a wasm32 binary.
There was a problem hiding this comment.
Pull request overview
Updates the release workflow to unblock GitHub releases/tags creation for v5.26.1 by upgrading the release-plz GitHub Action and adjusting how the Cargo build target is set so the action can install its native binary successfully.
Changes:
- Switch
release-plz/actionfrom a pinned commit SHA to@0.5. - Move the wasm32 build target configuration from
CARGO_BUILD_TARGETenv to a generated.cargo/config.tomlduring the workflow run.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| - name: Run release-plz | ||
| uses: release-plz/action@5ab144c9d67d4346240190d0f95ed08668677928 | ||
| uses: release-plz/action@0.5 |
There was a problem hiding this comment.
release-plz/action@0.5 is a moving target (patch updates can change behavior) and also weakens supply-chain security compared to the previously pinned commit SHA. Consider pinning to an exact release (e.g., v0.5.x) or a commit SHA, and optionally keep a comment noting which version it corresponds to for easy upgrades.
| uses: release-plz/action@0.5 | |
| uses: release-plz/action@v0.5.0 |
| # but it ignores .cargo/config.toml, so this lets the action install release-plz | ||
| # natively while cargo still builds for wasm32. | ||
| - name: Set cargo build target | ||
| run: echo -e '[build]\ntarget = "wasm32-unknown-unknown"' >> .cargo/config.toml |
There was a problem hiding this comment.
This step appends to .cargo/config.toml with >>, which can create multiple [build] sections if the file is ever added to the repo or if another step writes to it, leading to confusing Cargo config resolution. Prefer writing the file deterministically (overwrite/create) and use printf/heredoc instead of echo -e for better shell portability.
| run: echo -e '[build]\ntarget = "wasm32-unknown-unknown"' >> .cargo/config.toml | |
| run: | | |
| mkdir -p .cargo | |
| cat > .cargo/config.toml <<'EOF' | |
| [build] | |
| target = "wasm32-unknown-unknown" | |
| EOF |
The composite action installs release-plz via cargo-binstall with --force, inheriting CARGO_BUILD_TARGET=wasm32-unknown-unknown from the step env. This causes it to try installing a wasm32 binary. Install release-plz and cargo-semver-checks in a separate step without the env var, then run release-plz commands directly with CARGO_BUILD_TARGET set only for the execution steps. Also fixes the dirty-tree issue where .cargo/config.toml created at runtime would cause release-pr to fail.
Skip the cargo publish verification build (which requires wasm32) via release-plz config. This removes the need for CARGO_BUILD_TARGET in the workflow, which was causing cargo-binstall to try installing a wasm32 binary of release-plz.
r-near
changed the title
Summary
@0.5(currently v0.3.157)publish_no_verify = truetorelease-plz.tomland removeCARGO_BUILD_TARGETfrom the workflowThe v5.26.1 release failed due to a gix slotmap bug (fixed in v0.3.156) and couldn't recover on re-run because it didn't recognize already-published crates (fixed in v0.3.155). Updating was blocked because
CARGO_BUILD_TARGET=wasm32-unknown-unknowncaused cargo-binstall to try installing a wasm32 binary of release-plz. Skipping the publish verification build via config removes the need for the env var entirely.