Skip to content

Speed up CI: nextest + scope Cargo cache to deps only#1747

Open
nogates wants to merge 3 commits into
masterfrom
nogates/speed-up-ci-test-pipeline
Open

Speed up CI: nextest + scope Cargo cache to deps only#1747
nogates wants to merge 3 commits into
masterfrom
nogates/speed-up-ci-test-pipeline

Conversation

@nogates

@nogates nogates commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Two changes to reduce CI pipeline time:

  1. Switch to cargo nextest run — replaces cargo test for parallel test execution. Nextest downloads as a pre-compiled binary (~10s) and runs test binaries concurrently.

  2. Scope the Cargo cache to dependencies only — removes target/ from the cached paths and narrows it to ~/.cargo/registry/index, ~/.cargo/registry/cache, and ~/.cargo/git/db. This keeps the cache small and stable (only invalidated when Cargo.lock changes, not on every source commit), and avoids the overhead of saving/restoring multi-GB compiled artifacts on each run. The cache key is also unified across all workflows (previously the test workflow included the Rust version in the key, preventing sharing with other jobs).

Additional Notes

Trade-off: without target/ cached, compiled dep artifacts are not reused between runs, so each run recompiles deps from source. If this turns out to be too slow in practice, target/ can be added back.

Review checklist

  • This PR includes all newly recorded cassettes for any modified tests.

  • This PR does not rely on API client schema changes.

    • The CI should be fully passing.

Add hash-based test sharding: scenarios are assigned to a shard by
summing their name bytes modulo TEST_SHARD_TOTAL. Each shard runs on
its own runner in parallel, cutting the test wall-clock time roughly
in half without requiring any changes to feature files.

- tests/main.rs: read TEST_SHARD_TOTAL/TEST_SHARD_INDEX env vars and
  apply modulo filter in the scenario filter closure
- reusable-rust-test.yml: add shard-count + shard-indexes inputs,
  expand shard-index into the strategy matrix, pass env vars to Test step
- test.yml: configure shard-count=2 and shard-indexes=[0,1]

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@nogates nogates requested review from a team as code owners June 12, 2026 09:55
@datadog-official

datadog-official Bot commented Jun 12, 2026

Copy link
Copy Markdown

Pipelines

Fix all issues with BitsAI

⚠️ Warnings

🚦 2 Pipeline jobs failed

Ensure labels | changelog   View in Datadog   GitHub Actions

Run Tests | test (2)   View in Datadog   GitHub Actions

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: b13374d | Docs | Datadog PR Page | Give us feedback!

nogates and others added 2 commits June 12, 2026 12:12
4 shards gives ~25% of scenarios per runner (~1055 each out of 4219),
reducing test-execution time by ~4x in parallel.

Replaced byte-sum with FNV-1a (32-bit): better avalanche effect means
distribution stays even as the scenario count grows or names cluster.
Distribution with 4 shards: [1092, 1003, 1059, 1065] (±4%).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds a dedicated build job that compiles the test binary once and
uploads it as a GHA artifact. Four test shard jobs then download the
binary and run their slice of scenarios without any cargo/Rust toolchain
needed -- eliminating ~4-5 min of redundant compilation per shard.

License check also moves to the build job so it only runs once.

Cache key switches to Cargo.toml hash (Cargo.lock is gitignored).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant