Monorepo workflows

rusty workspace commands are designed for repositories with dozens or hundreds of crates. This guide covers practical CI and local developer flows.

Local pre-push

Before pushing a branch, see what your changes touch:

rusty workspace affected origin/main
rusty workspace affected origin/main --reverse
rusty test --affected origin/main          # reverse-deps (usual CI set)
rusty test --affected-direct origin/main   # path-touched packages only

Or print an explicit package list:

rusty workspace test-plan origin/main
# → rusty test -p api -p worker …

CI: test only what changed

# illustrative — adapt to your CI provider
- name: Test affected crates
  run: rusty test --affected origin/main

Pin packages with the printed plan when you need a reviewable argv:

- name: Test affected crates (explicit -p)
  run: |
    eval "$(rusty workspace test-plan origin/main | tail -n1)"

CI: cache layers

1. Restore $RUSTY_HOME/cache/ and $RUSTY_HOME/store/ from your cache backend.
2. rusty fetch (offline-friendly after store restore).
3. rusty layers plan --release — log hit rate for observability.
4. rusty build --release or the affected test plan.

Keep RUSTY_HOME stable across CI jobs on the same worker pool so layer keys hit.

Version drift reviews

Schedule or run on demand:

rusty workspace unify

When drift appears, bump lower-version Cargo.toml / rusty.json entries to the highest version in use across the workspace, then rusty lock and rusty fetch.

Dependents impact

Before changing a shared internal crate:

rusty workspace dependents my-internal-lib

Combine with affected --reverse to build the full blast radius for a given diff.

Native test runner

rusty test never calls cargo test. Scope options:

rusty test --workspace                 # all members
rusty test -p api -p worker            # subset
rusty test --affected origin/main      # git-affected + reverse dependents

Full capability matrix: Test runner.