With `cache-python: true`, a Windows runner can report a cache hit while
extracting the cache incorrectly. When `@actions/cache`'s tar extracts
uv's minor-version junction before the patch directory it points to, it
creates a file symlink. Resolving that link later raises `[WinError 5]
Access is denied`.
This PR fixes things up after restoring the Python cache, recreating the
junction if resolving the link fails with access denied and its recorded
target is a matching, accessible CPython installation in the same
directory.
This is a temporary workaround until
https://github.com/actions/toolkit/issues/2562 gets resolved and
`@actions/cache` itself becomes resilient to these situations.
I tested this by restoring the same archive on two fresh `windows-2022`
runners. The original run passed because resolving the minor-version
link raised the expected WinError 5. With the patch, `uv sync --offline
--managed-python --no-python-downloads` created a virtual environment
whose `home` in `pyvenv.cfg` resolved to the cached CPython 3.10.22
installation. [Original
run](https://github.com/astral-sh/ruff/actions/runs/41469344610/job/125358623949#step:9:1)
· [Patched
run](https://github.com/astral-sh/ruff/actions/runs/41469344610/job/125358623835#step:10:1).
## Summary
The post step logs `uv cache saved with key: ...` (and `Python cache
saved with key: ...`) even when the save failed. The log in #769 shows
it right after `Warning: Failed to save: ...`:
```
Warning: Failed to save: "C:\Program failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2
uv cache saved with key: setup-uv-2-x86_64-pc-windows-msvc-windows-11-3.12.12-pruned-...
```
`@actions/cache`'s `saveCache` doesn't throw for these failures. It logs
them and returns `-1`, and `saveCacheToKey` ignored the return value.
This now checks for `-1` before logging, which is the same check the
`actions/cache` save step uses (`if (cacheId != -1) core.info("Cache
saved with key: ...")`). `@actions/cache` already logs the reason, so
nothing else is logged on failure, and the exit code stays the same.
This only changes the log line. It doesn't address the underlying
tar/gzip failure in #769. One limitation: with the legacy (v1) cache
service, an upload that fails after the cache was reserved still returns
the reserved id, so that one case is still reported as saved. That's on
the `@actions/cache` side and affects `actions/cache` the same way.
Related to #769
## Test plan
- Added `__tests__/cache/save-cache.test.ts`. The `-1` case fails before
the change and passes after it.
- `npm run all` on Ubuntu (WSL) with Node 24.19.0 / npm 11.17.0: build,
Biome (no fixes), packaging, and all 161 tests across 16 suites pass.
The regenerated `dist/save-cache/index.cjs` only differs in the changed
lines.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
## Summary
- Preserve class names in the save-cache bundle so `@actions/cache`
error-name comparisons distinguish validation errors, benign
cache-reservation races, and finalization errors correctly.
- Add regression coverage that exercises the bundled `ValidationError`,
`ReserveCacheError`, and `FinalizeCacheError` constructors.
Fixes#1028
## Verification
- `npm run all` passed on Ubuntu 24.04 with Node 24.19.0: build, Biome,
packaging, and all 159 tests across 15 suites.
- `git diff --check` passed.
The save-cache bundle increases by about 77 KB raw (14 KB gzip) to
preserve the required names.
Windows ARM64 jobs may need x64 Python independently of their Python
version pin. Add `python-arch` to export `UV_PYTHON_ARCH` for subsequent
steps and include the selected architecture in the uv and managed-Python
cache keys. The input takes precedence over an inherited environment
value, and unsupported uv versions fail before environment creation.
Requires a uv release with `UV_PYTHON_ARCH` support.
## Summary
This changes the default for `prune-cache` from `true` to `false`,
motivated by [#745](https://github.com/astral-sh/setup-uv/issues/745).
Users that want the existing behavior can continue to set `prune-cache:
true` explicitly.
Some history: I originally added [`uv cache prune
--ci`](https://github.com/astral-sh/uv/pull/5391) after looking at a
workload where the uv cache was ~2.2 GB, almost entirely due to the
enormous pre-built `torch` and `nvidia_cudnn_cu12` wheels ([original
analysis](https://github.com/actions/setup-python/issues/822#issuecomment-2248728264)).
Persisting and restoring thousands of extracted files through the GitHub
Actions cache could be slower than downloading the wheels again. In
contrast, wheels built from source can be very expensive to recreate.
The intent was to remove pre-built wheels while retaining locally-built
wheels.
`setup-uv` subsequently made pruning configurable, but defaulted
`prune-cache` to `true`; it also later enabled caching by default on
GitHub-hosted runners. As a result, the default configuration repeatedly
downloads pre-built wheels from PyPI even on a cache hit. That tradeoff
has become more important as uv adoption has grown: [the PyPI analysis
in
#745](https://github.com/astral-sh/setup-uv/issues/745#issuecomment-3867334064)
estimates that uv accounts for roughly half of reported CI downloads
from PyPI, and roughly 65-75% for `boto3`.
I ran the comparison across a few different workloads:
| Workload | PR | Packages | Cache: keep / prune / prune-ci | Warm
restore+sync: keep / prune / prune-ci | Downloads: prune / prune-ci |
|---|---:|---:|---:|---:|---:|
| Tiny | [#1](https://github.com/astral-sh/setup-uv-benchmarks/pull/1) |
19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 |
| Web | [#2](https://github.com/astral-sh/setup-uv-benchmarks/pull/2) |
65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 |
| Scientific |
[#3](https://github.com/astral-sh/setup-uv-benchmarks/pull/3) | 118 |
586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 |
| PySpark |
[#4](https://github.com/astral-sh/setup-uv-benchmarks/pull/4) | 19 |
1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 |
| CPU PyTorch |
[#5](https://github.com/astral-sh/setup-uv-benchmarks/pull/5) | 14 | 182
/ 182 / 1 MB | 3.0-6.0 / 3.6-4.0 / 5.7-6.4 s | 0 / 6 |
| CPU-PyTorch ML |
[#6](https://github.com/astral-sh/setup-uv-benchmarks/pull/6) | 137 |
346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 |
| CUDA PyTorch |
[#7](https://github.com/astral-sh/setup-uv-benchmarks/pull/7) | 201 |
2316 / 2315 / 16 MB | 30.2-67.9 / 31.0-63.6 / 33.3-36.7 s | 0 / 40 |
The CUDA workload intentionally reproduces the original `torch==2.1.1`
example. Keeping wheels again produces a ~2.3 GB Actions cache. Across
nine warm runs, restoring that cache ranged from slightly faster than
re-downloading to roughly twice as slow; pruning consistently
re-downloaded 40 distributions in ~33-37 seconds ([original
runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738),
[additional
runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)).
I also tried running `uv cache prune --force` without `--ci` across
every workload, to see if it provided a useful middle ground. It did not
meaningfully reduce any of the caches: plain prune took 11-21 ms and
left the extracted cache and file count unchanged, including PySpark. On
these fresh caches, there are no dangling entries to remove; without
`--ci`, the pre-built wheels and unpacked source/build artifacts are
retained. The per-workload runs are linked in the table above.
So the original motivation still holds for very large CUDA or
source-heavy workloads, but it is not representative of the common case.
For smaller workloads, keeping pre-built wheels is generally faster and
avoids repeated PyPI traffic. This changes the default accordingly,
while retaining `prune-cache: true` as an opt-in for workloads where the
smaller cache is worthwhile.
Closes https://github.com/astral-sh/setup-uv/issues/745.
## Summary
- URL-encode the Python version component before adding it to the cache
key
- URL-encode the user-provided cache suffix for the same reason
- Add cache key tests for Python ranges, comma-containing suffixes, and
unchanged simple inputs
Fixes#914
Refs: pi-session 019f3164-85e7-7817-bffd-501d89b3a1fd
## Tests
- npm run all
Zsolt DollensteinandGitHub
Danny WardandGitHub
Zanie BlueandGitHub
Charlie MarshandGitHub
Kevin StillhammerandGitHub