chore: Cherry-picked changes from upstream - #109
Merged
Conversation
Contributor
Author
|
🚀 PR Updated! The PR has been updated with the latest cherry-picked commits. @step-security/maintained-actions-dev Please review and approve the changes. 📦 Target Release Version: 🛑 Workflow Files (Cannot be auto-applied by GitHub Actions):
❌ Conflicting Files:
|
Contributor
Author
🔍 Cherry-Pick Verification Report📦 Upstream Changes: 📋 File-by-File Analysis:
|
chore: update known checksums for 0.11.29
…d (#961) ## Summary `getLinuxOSNameVersion()` throws `Failed to determine Linux distribution. Could not read /etc/os-release or /usr/lib/os-release` on distributions whose os-release is readable but contains **no version field at all** — no `VERSION_ID`, no `VERSION_CODENAME`, no `BUILD_ID`. The error message is misleading in that case, and the action fails even though the distribution is perfectly identifiable. Void Linux is such a distribution. Its os-release is: ```sh $ cat /etc/os-release NAME="Void" ID="void" PRETTY_NAME="Void Linux" HOME_URL="https://voidlinux.org/" DOCUMENTATION_URL="https://docs.voidlinux.org/" LOGO="void-logo" ANSI_COLOR="0;38;2;71;128;97" DISTRIB_ID="void" ``` Unlike Arch (fixed by #912 via `BUILD_ID`) and debian:unstable (fixed via `VERSION_CODENAME`, #773), Void ships only `ID`, so both existing fallbacks miss it. This breaks any workflow using `container: ghcr.io/void-linux/void-glibc-full` with caching enabled — e.g. SageMath's CI started failing after bumping to v8: https://github.com/sagemath/sage/actions/runs/29456228986/job/87489892141 (worked around downstream in sagemath/sage#42547 by injecting a fake `BUILD_ID` into the container's os-release). This PR adds a last-resort fallback: if `ID` is present but no version field is, return the plain `ID` (`void`), following the same reasoning as #912 — a stable cache key for a rolling release is better than crashing. Distributions with a version field are unaffected, and files without even an `ID` still raise the existing error.
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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 astral-sh/setup-uv#745.
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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 astral-sh/setup-uv#745.
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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 astral-sh/setup-uv#745.
## Summary This changes the default for `prune-cache` from `true` to `false`, motivated by [#745](astral-sh/setup-uv#745). Users that want the existing behavior can continue to set `prune-cache: true` explicitly. Some history: I originally added [`uv cache prune --ci`](astral-sh/uv#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](actions/setup-python#822 (comment))). 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](astral-sh/setup-uv#745 (comment)) 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 astral-sh/setup-uv#745.
chore: update known checksums for 0.11.30
Raj-StepSecurity
force-pushed
the
auto-cherry-pick
branch
from
August 14, 2026 05:53
99a33de to
09c2e3a
Compare
Contributor
Author
🔍 Cherry-Pick Verification Report📦 Upstream Changes: 📋 File-by-File Analysis:
|
Contributor
Author
🔍 Cherry-Pick Verification Report📦 Upstream Changes: 📋 File-by-File Analysis:
|
|
please bring in package.json changes, at least bring the smol-toml upgrade it might cause changes in dist. |
amanstep
approved these changes
Aug 14, 2026
Contributor
Author
🔍 Cherry-Pick Verification Report📦 Upstream Changes: 📋 File-by-File Analysis:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cherry-picked changes from upstream.
astral-sh/setup-uv@v8.3.2...v9.0.0