Repeated rebuilds every time I run "cargo test" on my crate

[andrewdavidmackenzie]

I notice that I get a lot of rebuilds of dependencies of my crate, that depend on ring.

In particular, an easily repeatable one is when I run "cargo test". It starts a rebuild of some dependencies starting with ring:

Compiling ring v0.17.14
   Compiling rustls v0.23.35
   Compiling rustls-webpki v0.103.8
   Compiling tokio-rustls v0.26.4
   Compiling iroh-quinn-proto v0.13.0
   Compiling hyper-rustls v0.27.7
   Compiling hickory-proto v0.25.2
   Compiling tokio-websockets v0.12.3
   Compiling rustls-platform-verifier v0.5.3
   Compiling reqwest v0.12.25
   Compiling iroh-quinn v0.14.0
   Compiling pkarr v5.0.0
   Compiling hickory-resolver v0.25.2
   Compiling iroh-relay v0.95.1
   Compiling iroh v0.95.1

These are the dependencies on ring:

cargo tree -i ring
ring v0.17.14
├── iroh-quinn-proto v0.13.0
│   ├── iroh v0.95.1
│   │   ├── pigglet v0.7.3 (/Users/amackenz/workspace/pigg/pigglet)
│   │   ├── piggui v0.7.3 (/Users/amackenz/workspace/pigg/piggui)
│   │   └── pignet v0.7.3 (/Users/amackenz/workspace/pigg/pignet)
│   │       └── piggui v0.7.3 (/Users/amackenz/workspace/pigg/piggui)
│   │       [dev-dependencies]
│   │       ├── pigglet v0.7.3 (/Users/amackenz/workspace/pigg/pigglet)
│   │       └── piggui v0.7.3 (/Users/amackenz/workspace/pigg/piggui)
│   ├── iroh-quinn v0.14.0
│   │   ├── iroh v0.95.1 (*)
│   │   └── iroh-relay v0.95.1
│   │       └── iroh v0.95.1 (*)
│   └── iroh-relay v0.95.1 (*)
├── rustls v0.23.35
│   ├── hickory-proto v0.25.2
│   │   └── hickory-resolver v0.25.2
│   │       ├── iroh v0.95.1 (*)
│   │       └── iroh-relay v0.95.1 (*)
│   ├── hickory-resolver v0.25.2 (*)
│   ├── hyper-rustls v0.27.7
│   │   └── reqwest v0.12.25
│   │       ├── iroh v0.95.1 (*)
│   │       ├── iroh-relay v0.95.1 (*)
│   │       └── pkarr v5.0.0
│   │           ├── iroh v0.95.1 (*)
│   │           └── iroh-relay v0.95.1 (*)
│   ├── iroh v0.95.1 (*)
│   ├── iroh-quinn v0.14.0 (*)
│   ├── iroh-quinn-proto v0.13.0 (*)
│   ├── iroh-relay v0.95.1 (*)
│   ├── reqwest v0.12.25 (*)
│   ├── rustls-platform-verifier v0.5.3
│   │   └── iroh v0.95.1 (*)
│   └── tokio-rustls v0.26.4
│       ├── hickory-proto v0.25.2 (*)
│       ├── hickory-resolver v0.25.2 (*)
│       ├── hyper-rustls v0.27.7 (*)
│       ├── iroh-relay v0.95.1 (*)
│       ├── reqwest v0.12.25 (*)
│       └── tokio-websockets v0.12.3
│           └── iroh-relay v0.95.1 (*)
├── rustls-webpki v0.103.8
│   ├── iroh v0.95.1 (*)
│   └── rustls v0.23.35 (*)
└── tokio-websockets v0.12.3 (*)

I took a quick look at ring's build.rs to see if I could see anything obvious.

One thing I noticed was that it seems to output the cargo instruction to rebuild if change for the "$OUTDIR" environment variable.

I didn't epect that and wonder if that is correct.

Other than that, what else could be triggering ring rebuild, when no other changes are made and I literally type "cargo test" twice in a row?

It doesn't happen with two invocations of "cargo build", but I do see rebuilds starting with ring without making changes to it's version or (AFAIK) other things that I would expect to trigger a rebuild.

[rejuvenile]

I also see this, when building with Bazel and rules_rust.

[rejuvenile]

[rejuvenile]

My cargo repro isolates this to incremental builds enabled by default, which might embed an mtime into the metadata, or somesuch. It does not occur in release mode. That said, my repro involves a cargo clean so it's not clear how common it is.

The Bazel repro. is similarly solved by --action_env=CARGO_INCREMENTAL=0. This case is more likely to be hit because Bazel's remote build cache can be purged automatically.

[vstepchik]

I believe this was fixed in #2454 but have not been released still.
I managed to workaround by adding this to Cargo.toml:

[patch.crates-io]
# use the ring from main until the bugfix is released (rung v0.17.15+)
ring = { git = "https://github.com/briansmith/ring.git", rev = "522afb658067bed0512a49f66bd4c07389b51ab3" }

@briansmith does anything prevent the release from being made?

[andrewdavidmackenzie]

Any plans for a release with this fix included?

[rejuvenile]

@briansmith Please let me know if/how I can help push a release with this fix.