fix: sync Cargo.toml version with changesets

[jpoehnelt]

Problem

Changesets bumps package.json but not Cargo.toml. When the tag is created, cargo-dist fails because the version in Cargo.toml doesn't match the tag.

Additionally, changeset tag silently skips private: true packages, so no git tag was ever created.

Fix

1. scripts/version-sync.sh — Custom version command that runs changeset version, then syncs the resulting version into Cargo.toml (via awk) and regenerates Cargo.lock
2. release-changesets.yml — Uses version: pnpm run version-sync so the changeset version PR includes Cargo.toml + Cargo.lock changes. Adds Rust toolchain for lockfile generation.
3. tag-release script — Replaces changeset tag with a custom script that creates and pushes a v{version} git tag. Now idempotent (won't fail if tag already exists).
4. Version sync — Bumps Cargo.toml from 0.1.0 → 0.1.1 to match current package.json.

Flow after this PR

push to main with .changeset/*.md files
  → changesets/action detects changesets
  → creates "Version Packages" PR (bumps package.json + Cargo.toml + CHANGELOG)
  → PR merges
  → changesets/action detects no changesets, runs publish (tag-release)
  → creates + pushes v{version} git tag
  → cargo-dist release.yml triggers on tag
  → builds binaries + publishes npm

[changeset-bot]

🦋 Changeset detected

Latest commit: 8f9d855

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@googleworkspace/cli	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue in the release workflow where changesets failed to update the Cargo.toml version, leading to inconsistencies and build failures during cargo-dist operations. It introduces a robust mechanism to ensure version synchronization between JavaScript and Rust package manifests and refines the tagging process for releases. These changes streamline the release pipeline, making it more reliable and automated for future updates.

Highlights

• Automated Version Synchronization: Introduced a new version-sync.sh script to automatically synchronize the Cargo.toml package version with package.json after changesets updates, and regenerate Cargo.lock.
• Idempotent Tagging: Modified the tag-release script to create v{version} git tags idempotently, preventing failures if a tag already exists and addressing issues where changeset tag skipped private packages.
• Dependency Updates: Updated numerous Rust dependencies in Cargo.lock to their latest patch or minor versions, including anyhow, syn, bitflags, futures-* crates, getrandom, js-sys, libc, tokio, and wasm-bindgen related packages.
• Initial Version Bump: Performed an initial version bump of the main gws package in Cargo.toml from 0.1.0 to 0.1.1 to align with the current package.json version.

Changelog

• Cargo.lock
  • Updated various Rust dependency versions and their corresponding checksums.
  • Removed the pin-utils dependency from futures-util.
  • Updated r-efi to include version 6.0.0 and adjusted references.
• Cargo.toml
  • Updated the main gws package version from 0.1.0 to 0.1.1.
• package.json
  • Added a new version-sync script entry to handle version synchronization.
  • Modified the tag-release script to be idempotent, allowing it to skip tag creation if the tag already exists.
• scripts/version-sync.sh
  • Added a new shell script to execute pnpm changeset version, read the new version from package.json, update Cargo.toml using awk, regenerate Cargo.lock, and stage the changes.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/release-changesets.yml

Activity

• The pull request introduces new scripts and modifies existing configuration to fix versioning and tagging issues.
• The author has provided a detailed problem description, fix breakdown, and a flow diagram for the new release process.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to synchronize the version between package.json and Cargo.toml, which is a great improvement for the release process. I've added a couple of suggestions to make the new scripts more robust and the CI logs clearer. One suggestion is to simplify the Cargo.lock generation command in version-sync.sh to improve error handling. The other is to refine the error message in the tag-release script in package.json to avoid confusion during CI failures.

[jpoehnelt]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a robust solution for synchronizing versions between package.json and Cargo.toml within a Changesets-based release workflow. The addition of version-sync.sh and tag-release.sh scripts is a great improvement for automating the release process and ensuring consistency. My review includes a couple of suggestions to further improve the robustness of these new scripts. Specifically, I recommend using annotated git tags for better release tracking and making the version-parsing logic in the sync script more flexible.

[gemini-code-assist]

For releases, it's a best practice to create annotated tags instead of lightweight tags. Annotated tags include metadata such as the tagger, date, and a message, which is valuable for release tracking.

Suggested change

	git tag "$TAG"
	git tag -a -m "Release $TAG" "$TAG"

[gemini-code-assist]

The awk pattern to find the version line is a bit strict as it assumes a single space around the = character. To make the script more robust against potential formatting changes in Cargo.toml, it's better to allow for any amount of whitespace around the equals sign.

Suggested change

	in_pkg && /^version = / { $0 = "version = \"" ver "\"" }
	in_pkg && /^version[ \t]*=[ \t]*/ { $0 = "version = \"" ver "\"" }