Commit Graph

9 Commits

Author SHA1 Message Date
Zanie Blue 4de559d70d
Increase the size of the Windows dev drives from 20GB -> 25GB (#15734)
We ran out of disk space in
https://github.com/astral-sh/uv/actions/runs/17551474262/job/49844770034?pr=15727

Closes https://github.com/astral-sh/uv/issues/15729
2025-09-08 13:21:38 +00:00
Jack O'Connor efc361223c move the test buckets dir into the canonicalized temp dir
Previously we were using the XDG data dir to avoid symlinks, but there's no
particular guarantee that that's not going to be a symlink too. Using the
canonicalized temp dir by default is also slightly nicer for a couple reasons:
It's sometimes faster (an in-memory tempfs on e.g. Arch), and it makes
overriding `$TMPDIR` or `%TMP%` sufficient to control where tests put temp
files, without needing to override `UV_INTERNAL__TEST_DIR` too.
2025-06-26 14:56:20 -07:00
Zanie Blue 75d4cd30d6
Use Depot for Windows `cargo test` (#14122)
Replaces https://github.com/astral-sh/uv/pull/12320

Switches to Depot for the large Windows runner we use for `cargo test`.

The runtime goes from 8m 20s -> 6m 44s (total) and 7m 18s -> 4m 41s
(test run) which are 20% and 35% speedups respectively.

A few things got marginally slower, like Python installs went from 11s
-> 38s, the Rust cache went from 15s -> 30s, and drive setup went from
7s -> 20s.
2025-06-18 09:55:09 -05:00
Zanie Blue 1ef47aa1d5
Only move the `.cargo` directory if it exists (#10938)
which it usually does... but on some runners it can be missing now?
2025-01-24 15:39:29 +00:00
Zanie Blue 6a5e5b33f2
Move `cargo` to the Dev Drive in Windows CI (#10656)
This successfully changed the nextest install to target the dev drive

```
info: cargo-nextest installed at /e/.cargo/bin/cargo-nextest.exe
```
2025-01-21 12:43:54 -06:00
Zanie Blue 896435faec
Use `D:` drive for Windows CI (#10180)
When using the standard Windows runners (as opposed to the _larger_
GitHub runners), an undocumented `D:` drive is available and performant.
We can save some money on by using this on a standard runner instead of
a larger runner with an ReFS drive. Switching to the `D:` drive was not
acceptable for `cargo test` >25m runtime.

Inspired by https://github.com/pypa/pip/pull/13129
See https://github.com/actions/runner-images/issues/8755

Timings (grain of salt — GitHub is super noisy):

- clippy: 2m 18s -> 2m 11s
- build binary: 2m 3s -> 2m 35s
- trampoline check (x86-64): 2m 32s -> 1m 50s (other architectures
similar)
- trampoline test (x86-64): 4m 12s -> 6m 7s
- trampoline test (i686): 6m 44s -> 5m 35s
2025-01-17 13:57:09 -06:00
Zanie Blue 75a1a47859
Improve performance of our test drive in Windows CI (#10651)
Previously, we couldn't use a DevDrive
(https://github.com/astral-sh/uv/pull/3522#issuecomment-2111448930)
because our Windows version was not sufficient.

Recently, I upgraded our larger runners to Windows 2025 preview
(https://github.com/astral-sh/uv/pull/10298) which I presume has support
for this.

I removed ReFS in
953c3535c3
which didn't seem to do anything to performance.

I also found some notes on "trusted" DevDrives and "disabling anti-virus
filtering" which I simply have to try.
2025-01-16 12:07:09 -06:00
Zanie Blue 47eeef5c09
Explicitly create the DevDrive tmpdir before use (#7644)
A suggested solution to #6940 — unfortunately only time will tell if it
works.
2024-09-23 12:59:22 -05:00
Amos Wenger 3e207da3bc
ci(windows): Introduce setup-dev-drive.ps1, maximize dev drive usage (#6858)
As suggested by @samypr100 on #6680:
https://github.com/astral-sh/uv/pull/6680#issuecomment-2313607984

## Summary

Instead of using `UV_INTERNAL__TEST_DIR`, it simply exports `TEMP` when
running Windows jobs.

## Test Plan

I'm going to run this manually under ProcMon on my Windows machine and
see where uv writes temp files, hopefully to the dev drive and not
`%(LOCAL)APPDATA%` or something.

I'm going to commit a dummy code change and look at build time changes
in CI.
2024-08-30 08:54:25 -04:00