https://github.com/pyca/cryptography/pull/15572#discussion_r3913508686
has the context for this: TL;DR our current `python-version` output
mirrors the "request" version exactly, which means that it's
insufficient for any downstream that needs to manage its own cache keys
(since caches shouldn't be shared across release candidates, but the `uv
python` request version doesn't include RC numbers).
The first commit here was my attempt to fix this by exposing the runtime
Python version, but this too is imprecise: the runtime version doesn't
indicate the interpreter variant (e.g. freethreading), which is also
important to capture in the cache identity.
My solution here is to expose `python-runtime-id`, which is just the
`key` of the active Python version from `uv python list
--output-format=json`.
---------
Signed-off-by: William Woodruff <william@yossarian.net>
## Summary
- disable `enable-cache: auto` for `pull_request_target`,
`workflow_run`, and `release` events
- disable automatic caching for tag pushes while leaving branch pushes
unchanged
- preserve explicit `enable-cache: true` as an override
- run a `workflow_run` integration fixture with `act` in pull request CI
and verify caching is disabled
- document the behavior and update the published bundles
## Testing
- `npm run all`
- `actionlint .github/workflows/test.yml
__tests__/workflows/workflow-run.yml`
- `uvx zizmor __tests__/workflows/workflow-run.yml`
Closes#984
Refs: pi-session 019fec42-9b26-714e-a359-830ac4401ecd
## 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 https://github.com/sagemath/sage/pull/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.
On Arch Linux based runners, the setup fails with because
`/etc/os-release` does not contain `VERSION_ID` or `VERSION_CODENAME`.
It does contain a `BUILD_ID` which is set to `rolling`:
```sh
$ cat /etc/os-release
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo
```
This PR makes `getLinuxOSNameVersion` return `arch-rolling`.
There is no update from arch that would change the returned value, so
the same cache will always be used. Is this an issue? I'm not sure. At
least it's better than crashing because `os-release` does not contain
the expected values :).
## Summary
Adds a new `quiet` input (default: `false`) that suppresses `info`-level
log output when set to `true`. Only warnings and errors are shown.
Contributes to: #868
## Summary
Add a new boolean input `download-from-astral-mirror` (default: `true`)
that controls whether uv is downloaded from the Astral mirror or
directly from GitHub Releases.
When set to `false`, the mirror rewrite is skipped entirely and the
download goes straight to GitHub Releases.
Closes: #870
This PR tries fetching the uv artifact from `releases.astral.sh` by
default, only in cases where the artifact would otherwise have come from
`https://github.com/astral-sh/uv/releases/download/`. The checksums are
supposed to be the same for the mirror, and can still come from
`raw.githubusercontent.com/astral-sh/versions`. If the download fails,
we fall back to the original URL.
This avoids hitting GitHub's Releases API which is prone to rate
limiting. As far as I can tell, together with
https://github.com/astral-sh/setup-uv/pull/802 this PR makes a github
token entirely unnecessary for this action.
Towards https://github.com/astral-sh/uv/issues/18503.
Add `riscv64gc` as a recognized architecture in the `Architecture` type
union and map Node.js's `riscv64` process.arch value to the `riscv64gc`
uv platform identifier.
This allows the action to correctly detect and download the appropriate
uv binary on RISC-V 64-bit systems (e.g., linux/riscv64 runners).
Debian unstable and testing don't have VERSION_ID in /etc/os-release.
This change falls back to VERSION_CODENAME when VERSION_ID is missing,
producing cache keys like 'debian-sid' for unstable.
Fixes#773
I was mildly annoyed seeing
```
Post job cleanup.
UV_CACHE_DIR is already set to /home/runner/work/_temp/setup-uv-cache
UV_PYTHON_INSTALL_DIR is already set to /home/runner/work/_temp/uv-python-dir
```
in my GHA log. 😄
This fixes that to
```
Post job cleanup.
UV_CACHE_DIR is already set to /home/runner/work/_temp/setup-uv-cache
UV_PYTHON_INSTALL_DIR is already set to /home/runner/work/_temp/uv-python-dir
```
as is good and proper.
## Summary
- Adds OS name and version (e.g., `ubuntu-22.04`, `macos-14`,
`windows-2022`) to cache keys to prevent binary incompatibility when
GitHub updates runner images
- Fixes issue where cached uv binaries compiled against older
glibc/library versions fail on newer runner OS versions
## Changes
- Added `getOSNameVersion()` function to `src/utils/platforms.ts` with
OS-specific detection for Linux (via `/etc/os-release`), macOS (Darwin
kernel version mapping), and Windows
- Updated cache key format to include OS version, bumped `CACHE_VERSION`
to `"2"`
- Added `cache-key` output to expose the generated cache key for
debugging
- Added `test-cache-key-os-version` job testing across multiple OS
versions
- Updated `docs/caching.md` with cache key documentation
Closes#703
Adds a new `resolution-strategy` input that allows users to choose
between installing the highest (default) or lowest compatible version
when resolving version ranges.
This pull request introduces support for caching Python installs in the
GitHub Action, allowing users to cache not only dependencies but also
the Python interpreter itself.
This works by setting the `UV_PYTHON_INSTALL_DIR` to a subdirectory of
the dependency cache path so that Python installs are directed there.
Fixes#135
---------
Co-authored-by: Kevin Stillhammer <kevin.stillhammer@gmail.com>
venv activation was implicit when python-version was supplied. This now
only happens when activate-environment is true. working-directory
controls where we work and thus also where the .venv will be created
Closes: #351Closes: #271Closes: #251Closes: #211
