ci: run crate tests with cargo-nextest and Rust jobs on ev-runner-x-large

[matt-evervault]

Why

Two CI changes for the crate workflows:

1. Migrate the test step of the clippy_check_cli jobs from cargo test to cargo-nextest — a next-generation test runner with per-test process isolation, better output, and faster runs.
2. Move every job that invokes the Rust compiler off ubuntu-latest onto the self-hosted ev-runner-x-large runner.

How

nextest migration

• Install nextest via taiki-e/install-action@nextest and swap cargo test -p ev-cli -p ev-enclave → cargo nextest run -p ev-cli -p ev-enclave in both jobs that run the suite:
  • .github/workflows/lint-and-test-cli.yml
  • .github/workflows/release-cli-version-staging.yml
• Add .config/nextest.toml with a serial test group (max-threads = 1). This is the one non-mechanical part: nextest runs each test in its own process, so the two enclave-build tests annotated #[serial_test::serial] (test_choose_output_dir, test_reproducible_enclave_builds_with_pinned_version) are no longer serialized — serial_test's mutex is in-process only. Both write cert.pem/key.pem into, and build from, the crate working directory, so running them concurrently would race. The test group restores the previous one-at-a-time behaviour. Confirmed it resolves to exactly those two tests via cargo nextest show-config test-groups.

Runner change

Set runs-on: ev-runner-x-large on the three jobs that compile Rust:

Workflow	Job	Was	Now
lint-and-test-cli.yml	clippy_check_cli	ubuntu-latest	ev-runner-x-large
release-cli-version-staging.yml	clippy_check_cli	ubuntu-latest	ev-runner-x-large
build-and-publish.yml	compile-ubuntu	ubuntu-latest	ev-runner-x-large

compile-macos was left on macos-latest — it builds the x86_64-apple-darwin target and needs a macOS host, and ev-runner-x-large appears to be a Linux runner. If ev-runner-x-large is actually macOS-capable, say so and I'll switch it too. Jobs that don't compile Rust (get-version, upload-artifacts-to-s3, release-cli-version) stay on ubuntu-latest.

Verification

Ran both runners locally over the same scope:

Runner	Result
cargo test -p ev-cli -p ev-enclave	76 passed, same 5 failed
cargo nextest run -p ev-cli -p ev-enclave	76 passed, same 5 failed

The 5 failures are identical across both and purely environmental — the Docker-based enclave-build / synthetic-enclave tests, and the sandbox has no Docker daemon. They pass in CI (which provides Docker). This confirms the nextest migration is behaviour-preserving.

Notes

• These crates contain no doctests, so cargo nextest run (which does not run doctests) has the same coverage as cargo test here.
• Both clippy_check_cli jobs were migrated together for consistency. The #[serial_test::serial] source annotations were left untouched — harmless under nextest, and still applied by local cargo test runs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RQHtsSNmrd1N7QCVRhYXCv

[alexander-rw]

can we also add this in a precommit hook if we have one that runs tests? i worry about tests running locally being different to what runs in the cloud

[alexander-rw]

or is there any way for us to proxy cargo test to nextest in the background

[matt-evervault]

We can, I don't love precommit hooks for tests. I think they work better for things that run almost instantly, such as formatting. I don't believe we can replace what the default cargo test action does :( I think this will be fine, nextest is setup in most if not all of our rust repos, so if it did fail in CI but not locally, a developer could then run nextest locally and get the faster/prettier output; the other main difference is running tests in parallel.