Upgrade to `plan`/`run` broke action

[chrisgrounds]

The action seems to be installing the old version which uses test/affected.

Run loadingalias/cargo-rail-action@v1
Run set -euo pipefail
Attempting binary download: cargo-rail v0.10.0 for x86_64-unknown-linux-gnu
Downloaded cargo-rail-x86_64-unknown-linux-gnu.tar.gz
Extracting to /home/runner/.cargo/bin...
Binary installed to /home/runner/.cargo/bin/cargo-rail
cargo-rail 0.10.0
Installed cargo-rail v0.10.0 from binary
Run INPUT_SINCE=""
PR detected, using: origin/develop
Run case "$COMMAND" in
error: unrecognized subcommand 'affected'

Usage: cargo rail [OPTIONS] <COMMAND>

For more information, try '--help'.
Error: Process completed with exit code 2.

[loadingalias]

Hey, if you're using 'latest' for the GHA, which I assume is true based on the Issue... you have two options:

A) Update cargo-rail to v0.10.2 (a massive update w/ breaking changes, but they're genuinely worth it - unification improvements for undeclared features, massive perf/mem wins, and the main update was the deterministic change-detection logic w/ plan/run workflows replacing 'affected/test' workflows) then bump to v3.1.0 in the GHA.

See: https://github.com/loadingalias/cargo-rail/blob/main/docs/upgrade-to-v0.10.0.md
See: https://github.com/loadingalias/cargo-rail/blob/main/docs/how-to-use-cargo-rail-change-detection.md

B) Keep using the v2 GHA and cargo-rail v0.9.1

If you pass the https://github.com/loadingalias/cargo-rail/blob/main/docs/ to your LLM/Agent - it will sort it out, as well. This is a MUCH better version of cargo-rail and cargo-rail-action. It's deterministic in that you know what's being run and when... which allows us to cut build times, CICD minutes (I've shaved like 75% off of the Meilisearch team's CICD and am pushing a PR tomorrow). I'm just trying to illustrate - it's worth the update.

Let me know if I can help at all.

[loadingalias]

Hey, man. I wanted to add a brief note. I've added 'cargo rail run' as a power tool for teams, users, etc. working in smaller, simpler codebases. However, because cargo-rail isn't itself a test runner or task runner... it's not always the best option. In a large codebase, I find the best option is using something like...

Justfile/Makefile -> Scripts -> cargo rail plan w/ optional --all flag to skip change-detection -> your builds, tests, benches, etc. workflows.

I built this for a codebase that uses Nextest, but I also use Kani-Verifier, Miri, Sanitizers, Fuzzers, Stateright Model Checking, cargo-mutants, golden files/snapshots, etc. Trying to define this using cargo rail run isn't ideal. I'm thinking about the best way to handle it, but I wanted to share this with you as a tip.