Add caching layer to bootstrap

[Shourya742]

This PR adds a caching layer to the bootstrap command execution context. It is still a work in progress but introduces the initial infrastructure for it.

r? @Kobzol

[Kobzol]

Awesome! I haven't checked the code yet, but once you get it working, it would be great to see some benchmarks. Ideally of "no-op" commands, like running x check rustc after no change has been made to the compiler.

[Kobzol]

It seems like you misunderstood what I meant and went in a different direction, sorry :) I tried to clarify in comments.

[Kobzol]

I forgot that std::process::Command now provides a way to return all the inner state regarding arguments, env. variables, program and workdir. In that case, we don't need to store the cache key at all, and we can just reconstruct it from the inner std Command right before executing the bootstrap command.

[Kobzol]

Seems like some cache hits are being encountered, that's good. Later it would be nice to also record the durations of individual commands and then print some statistics at the end, which commands took the longest to execute, how many cache hits/misses they had etc.

[Kobzol]

Code looks good now, but before we merge it, I think that we should go through existing commands and make sure that it won't be problematic to cache them. I'll go through bootstrap tomorrow and check.

It would also be useful to add a comment on top of BootstrapCommand that explains that by default, command executions are cached if they have the same workdir/program/args/envs.

[Shourya742]

Code looks good now, but before we merge it, I think that we should go through existing commands and make sure that it won't be problematic to cache them. I'll go through bootstrap tomorrow and check.

It would also be useful to add a comment on top of BootstrapCommand that explains that by default, command executions are cached if they have the same workdir/program/args/envs.

I will add that.. added here: a5df236

[Kobzol]

Just to be sure, use do_not_cache on the command created in the bare_cargo function, to make sure that we don't ever cache cargo.

Also, it's a big edge case, but calling as_command_mut in ExecutionContext::start disables the caching of the command. Since our API allows executing the same command twice (although we don't currently do it anywhere, AFAIK), it could be cached in the first execution, and then not cached in the other executions, which is confusing. So it would be better if the execution context didn't call the function and just accessed the inner command directly. At the same time, I noticed that we have both exec.rs and execution_context.rs, which is a bit duplicated, both the command and the execution context belong together. So I would suggest moving the execution context to the exec.rs file (and remove execution_context.rs), which will also allow the context to access the inner std command without going through the as_command_mut function.

[Kobzol]

Let's see.

@bors r+ rollup=never

[bors]

📌 Commit ec765c3 has been approved by Kobzol

It is now in the queue for this repository.

[bors]

☔ The latest upstream changes (presumably #143074) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

Nudging this forward a bit so this doesn't have to endure too much bitrot.
@bors p=1

[Kobzol]

@bors r+

[bors]

📌 Commit 591df6c has been approved by Kobzol

It is now in the queue for this repository.

[bors]

⌛ Testing commit 591df6c with merge d51b6f9...

[bors]

☀️ Test successful - checks-actions
Approved by: Kobzol
Pushing d51b6f9 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing df32e15 (parent) -> d51b6f9 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard d51b6f97122671c5de27cfc08cded235357e0d97 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-apple-1: 6529.1s -> 8062.9s (23.5%)
2. x86_64-apple-2: 4798.5s -> 4098.2s (-14.6%)
3. dist-apple-various: 6707.4s -> 7470.2s (11.4%)
4. mingw-check-1: 1742.2s -> 1549.3s (-11.1%)
5. x86_64-gnu-tools: 3686.3s -> 3293.9s (-10.6%)
6. x86_64-rust-for-linux: 2791.5s -> 2510.8s (-10.1%)
7. i686-gnu-2: 6134.3s -> 5527.6s (-9.9%)
8. x86_64-gnu-llvm-20-1: 3603.5s -> 3284.1s (-8.9%)
9. aarch64-gnu: 6806.6s -> 6205.7s (-8.8%)
10. x86_64-gnu-llvm-19-1: 3653.3s -> 3331.7s (-8.8%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.