Fix Rust release workflow toolchain

[vinitkumar]

Summary by Sourcery

Pin Rust toolchain version in CI and release workflows and ensure Rust is explicitly installed before building wheels or running checks.

CI:

• Set a shared RUST_VERSION environment variable and install that specific toolchain in Rust CI jobs.
• Update Rust CI tests to run with default features enabled instead of disabling default features.

Documentation:

• Document that release and CI workflows install the pinned Rust toolchain before wheel builds and Rust checks.

[sourcery-ai]

Reviewer's Guide

Pins a specific Rust toolchain version in CI/release workflows and ensures all Rust builds/tests use that toolchain, while updating architecture docs to describe the behavior.

File-Level Changes

Change	Details	Files
Pin and install a specific Rust toolchain version across build and CI workflows.	Add RUST_VERSION env var set to 1.96.0 in Rust wheel build and CI workflows Install the pinned Rust toolchain using actions-rust-lang/setup-rust-toolchain before building wheels or running Rust checks Configure setup-rust-toolchain steps to use the RUST_VERSION env var as their toolchain input Update rust-ci unit test command to run full cargo test instead of cargo test --no-default-features Document in architecture.md that CI and release workflows install the pinned Rust toolchain before builds and checks	.github/workflows/build-rust-wheels.yml .github/workflows/rust-ci.yml lat.md/architecture.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (c9fb793) to head (ebbaff8).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##            master      #313   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            6         6           
  Lines          569       569           
=========================================
  Hits           569       569           

Flag	Coverage Δ
unittests	100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The Rust toolchain version is now hardcoded in multiple workflows (build-rust-wheels.yml and rust-ci.yml); consider centralizing this in a single place (e.g., a reusable workflow, environment variable, or repository variable) to avoid drift when updating versions.
• Switching cargo test --no-default-features to cargo test changes which feature set is exercised in CI; if you still need coverage for the minimal feature set, consider keeping a separate job or command that runs tests without default features alongside the default configuration.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The Rust toolchain version is now hardcoded in multiple workflows (`build-rust-wheels.yml` and `rust-ci.yml`); consider centralizing this in a single place (e.g., a reusable workflow, environment variable, or repository variable) to avoid drift when updating versions.
- Switching `cargo test --no-default-features` to `cargo test` changes which feature set is exercised in CI; if you still need coverage for the minimal feature set, consider keeping a separate job or command that runs tests without default features alongside the default configuration.

## Individual Comments

### Comment 1
<location path=".github/workflows/build-rust-wheels.yml" line_range="18" />
<code_context>
 env:
   PACKAGE_NAME: json2xml_rs
   PYTHON_VERSION: '3.12'
+  RUST_VERSION: '1.96.0'

 permissions:
</code_context>
<issue_to_address>
**suggestion:** Consider deriving the Rust version from a single source of truth (e.g., rust-toolchain.toml) instead of hardcoding it here.

Hardcoding `RUST_VERSION` here can drift from the version in `rust-toolchain*` or what developers use locally. If you already define the toolchain elsewhere, consider either relying on `setup-rust-toolchain`’s default (reading `rust-toolchain*`) or defining the version once (e.g., in a reusable workflow/env) and referencing it here to keep CI and local environments aligned.

Suggested implementation:

```
env:
  PACKAGE_NAME: json2xml_rs
  PYTHON_VERSION: '3.12'

```

```
      - name: Install Rust toolchain
        uses: actions-rust-lang/setup-rust-toolchain@46268bd060767258de96ed93c1251119784f2ab6 # v1

```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion: Consider deriving the Rust version from a single source of truth (e.g., rust-toolchain.toml) instead of hardcoding it here.

Hardcoding RUST_VERSION here can drift from the version in rust-toolchain* or what developers use locally. If you already define the toolchain elsewhere, consider either relying on setup-rust-toolchain’s default (reading rust-toolchain*) or defining the version once (e.g., in a reusable workflow/env) and referencing it here to keep CI and local environments aligned.

Suggested implementation:

env:
  PACKAGE_NAME: json2xml_rs
  PYTHON_VERSION: '3.12'

      - name: Install Rust toolchain
        uses: actions-rust-lang/setup-rust-toolchain@46268bd060767258de96ed93c1251119784f2ab6 # v1