fix(ci): correct the protoc pin, and build the package in CI

[jlucaso1]

The v0.6.2 release failed at Install wasm-pack with protoc@35.1 for 'linux' is not supported.

protobuf publishes the same release under two version strings — v35.1 and 3.35.1 — and install-action indexes the second. I pinned the first. Checked the action's manifest at the pinned SHA rather than guessing again: 173 versions, the newest being 3.35.1.

The part worth fixing is why it could only fail there

ci.yml called wasm-pack build and bun run build:ts directly, skipping gen. So CI never ran the build the package actually ships, and anything in that path — codegen, protoc, a generator plugin — surfaced for the first time during a release, after the tag and GitHub release already exist. That is the most expensive place to find it: each attempt burns a version number, because the workflow lives inside the tag and cannot be fixed retroactively.

CI now runs bun run build, with the same pinned tools as the release. The next break of this kind fails on the pull request.

State, and what it costs

v0.6.1 and v0.6.2 both exist as tags and GitHub releases with nothing on npm — 0.6.0 is still latest. Neither can be rescued by dispatch: their workflows predate the fix they need.

Simplest path is to let this land, take the 0.6.3 release-please will propose, and delete the two orphan tags:

gh release delete v0.6.1 --repo oxidezap/whatsapp-rust-bridge --cleanup-tag
gh release delete v0.6.2 --repo oxidezap/whatsapp-rust-bridge --cleanup-tag

Reusing 0.6.2 would mean deleting its tag and hand-editing the manifest back so release-please proposes it again. Version numbers are cheap; that surgery is not.

Note this PR gets the new CI treatment itself — the build job here runs bun run build, so if the pin is still wrong it fails on this PR rather than on the next release.

---

Summary by cubic

Pins protoc to 3.35.1 and makes CI run the exact release build with the same toolchain and action versions. This fixes the failed release and ensures codegen/tooling breaks fail on PRs, not during publish.

• Bug Fixes
  • Corrected release pin from protoc@35.1 to protoc@3.35.1, and applied the same pin in CI alongside wasm-pack.
  • Switched CI to bun run build so gen runs and matches the release build.
  • Pinned CI toolchain and actions to match release: bun@1.3.14 via BUN_VERSION, taiki-e/install-action, and oven-sh/setup-bun to avoid drift.

^{Written for commit 11a783b. Summary will update on new commits.}

Summary by CodeRabbit

• Chores
  • Updated automated build and release workflows to use a consistent, pinned Protocol Buffers compiler version.
  • Aligned CI validation with the same build process used for releases, including code generation.
  • Improved consistency between verification and publishing checks.

[coderabbitai]

📝 Walkthrough

Walkthrough

The CI workflow now installs protoc 3.35.1 and uses bun run build. The release verification and publishing jobs also use protoc 3.35.1.

Changes

CI workflow updates

Layer / File(s)	Summary
Unified CI build flow .github/workflows/ci.yml	CI installs protoc 3.35.1 and replaces separate wasm-pack and TypeScript commands with bun run build.
Release protoc pin .github/workflows/release.yml	Release verification and publishing jobs update the protoc pin to 3.35.1.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• oxidezap/whatsapp-rust-bridge#4: Both changes update the release workflow’s protoc installation and version.

Poem

A rabbit hops through CI’s lane,
With protoc pinned just right again.
One build command runs the show,
Release checks use the same flow.
Carrots cheer the green deploy!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies both main changes: correcting the protoc pin and running the package build in CI.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🤖 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/ci.yml:
- Around line 86-90: Update the stale comments at the release workflow locations
around the relevant build steps to reflect that CI now runs `bun run build` via
the “Build the wasm package” step; remove references claiming CI directly
invokes `wasm-pack` and `build:ts` or skips `gen`, while preserving any
still-accurate release workflow guidance.
- Around line 86-90: Update the CI workflow’s Bun setup to use version 1.3.14
instead of latest, matching the version configured by the release workflow for
verification and publishing. Keep the existing build command unchanged.

🪄 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: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81d38d8b-1698-4ab4-a0fa-1b7ec290f319

📥 Commits

Reviewing files that changed from the base of the PR and between a8ab48b and 43b8a5b.

📒 Files selected for processing (2)

• .github/workflows/ci.yml
• .github/workflows/release.yml

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[jlucaso1]

All four applied in 11a783b. They land on the same weakness: the PR claimed parity between CI and the release and only delivered the build command.

Bun floated while the release pinned (P2). The sharpest of the four. CI ran bun-version: latest against the release's 1.3.14, so CI could pass on a build the release then fails — the exact drift this PR set out to remove. Both now read one BUN_VERSION: 1.3.14 env var, so they cannot separate again without someone noticing.

This reverses what I argued two rounds ago, when I kept latest in CI on the grounds that catching breakage against current bun is the point there. That held while CI ran a different, lighter build. It stopped holding the moment CI became the release rehearsal. If we still want early warning on new bun, it belongs in a separate scheduled job, not in the one job whose value is being identical.

install-action on the moving @v2 (P3). Same problem one level down: CI resolved the action from a tag while the release pins a SHA, so the two could read different manifests for the same protoc@3.35.1 — unpinned tooling drift, which is what this PR exists to eliminate. CI now pins 91ddec7… like the release.

Stale comments in release.yml (coderabbit + cubic). Both said CI skips gen by calling wasm-pack and build:ts directly, which stopped being true one commit earlier. Rewritten to say why the pins exist now: same versions as CI so a break lands on a pull request, and pinned at all because publish runs much later than verify behind the environment gate.