Align CI toolchain with declared MSRV (Rust 1.85.0)

[coderabbitai]

Problem

The workspace declares rust-version = "1.85.0" in Cargo.toml files, but CI uses a different nightly toolchain (nightly-2025-06-26 in rust-toolchain.toml). This creates a mismatch between the declared minimum supported Rust version and what CI actually tests against.

Required Actions

1. Update rust-toolchain.toml: Replace or extend the current nightly pinning to use stable 1.89.0 instead of nightly-2025-06-26
2. Add CI matrix entry: Include a build/test step that runs with the 1.89.0 toolchain (e.g., rustup +1.89.0 build or cross +1.89.0 build)
3. Modify workflows: Update .github/workflows/release.yml and other relevant workflows to include a step targeting +1.89.0 alongside the latest stable

Context

This ensures CI verifies the declared MSRV is actually supported and prevents drift between declared and tested toolchain versions.

References

• PR: Add guard for NINJA_ENV overrides #115
• Comment: Add guard for NINJA_ENV overrides #115 (comment)
• Issue: Align CI toolchain with declared MSRV (Rust 1.85.0) #119

[leynos]

@coderabbitai looking at the codebase, is this issue still relevant? If the issue has been fixed in the code, does the documentation reflect this?

If it is still relevant, please provide an assessment of the issue criticality (critical, high, medium or low), based on risk of the issue impacting the user and the anticipated blast radius.

Once a decision has been made, apply the appropriate label.

If the issue is documentation ONLY (i.e., no code changes needed), apply the documentation label in addition to the appropriate criticality label.

Please also provide an impact of the required changes.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

I'll examine the current codebase to determine if this MSRV alignment issue is still relevant.

---

🏁 Script executed:

#!/bin/bash

echo "=== Checking rust-toolchain.toml ==="
if [ -f "rust-toolchain.toml" ]; then
    cat rust-toolchain.toml
else
    echo "rust-toolchain.toml not found"
fi

echo -e "\n=== Checking for Cargo.toml files and rust-version declarations ==="
fd -t f "Cargo.toml" --exec grep -H "rust-version" {} \;

echo -e "\n=== Checking CI workflow files ==="
fd -t f -e yml -e yaml .github/workflows/ --exec echo "=== {} ===" \; --exec cat {} \;

Length of output: 1081

---

🏁 Script executed:

#!/bin/bash

echo "=== Checking CI workflow files ==="
fd . .github/workflows/ --exec echo "=== {} ===" \; --exec cat {} \;

Length of output: 10857

---

@leynos, I've analyzed the current codebase and this issue is still relevant.

Current State Analysis

The exact mismatch described in the issue persists:

Declared MSRV vs. Actual CI Toolchain:

• ./test_support/Cargo.toml and ./ninja_env/Cargo.toml: rust-version = "1.85.0"
• rust-toolchain.toml: channel = "nightly-2025-06-26"
• All CI workflows use the setup-rust action that respects rust-toolchain.toml, so they test against nightly

Release workflow uses cross +stable build, but this uses the latest stable, not the declared MSRV of 1.85.0.

Criticality Assessment: HIGH

Risk factors:

• Users expect code to work on Rust 1.85.0 based on Cargo.toml declarations
• CI only tests against nightly-2025-06-26, providing no guarantee of MSRV compatibility
• Potential for runtime failures on the declared MSRV that go undetected

Blast radius: Medium - affects anyone attempting to build with Rust 1.85.0

Impact of Required Changes

This requires code changes (not documentation-only):

1. rust-toolchain.toml: Update to use stable 1.85.0 or add matrix support
2. CI workflows: Add MSRV testing step alongside existing nightly tests
3. Release workflow: Include explicit MSRV verification

Estimated effort: Medium - involves CI configuration changes across multiple workflows.

---

🏁 Script executed:

#!/bin/bash
gh issue edit 119 --add-label "high"

Length of output: 81

---

The issue has been successfully labeled with high criticality. This mismatch between declared MSRV and CI toolchain represents a significant risk that should be addressed to ensure reliable MSRV support and prevent user confusion.