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.
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>
`setup-uv` currently ignores the `sha256` supplied by the default
`astral-sh/versions` manifest when a selected artifact is newer than its
bundled checksum table, allowing that download to proceed without
validation. Use the manifest checksum as a fallback after explicit and
bundled checksums, and reject manifest entries that do not provide one.
This preserves the stronger pinned hashes for known releases while
verifying newer releases without requiring an action update. Part of
#1032.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Co-authored-by: William Woodruff <william@yossarian.net>
Co-authored-by: Kevin Stillhammer <kevin.stillhammer@gmail.com>
Transient timeout fetching manifests have increased significantly
recently, especially with private runners.
```
Fetching manifest data from https://raw.githubusercontent.com/astral-sh/versions/main/v1/uv.ndjson ...
Error: The operation was aborted due to timeout
```
Retry transient manifest network failures up to three times with a
progressive backoff (not exponential), keeping the total wait bounded
while making setup resilient to short network blips.
Co-authored-by: Raymond <arguile-@users.noreply.github.com>
## Summary
- reject path-like uv versions from `.tool-versions`
- reject path-like Python versions from `.tool-versions`
- document the restriction and cover Unix and Windows paths in tests
## Testing
- `npm ci --ignore-scripts`
- `npm run all`
Refs: pi-session 019ff4bb-8b7c-7c4b-8bdf-7c188dfa2e3f
## Summary
- add `latest-known` as an explicit version selector
- resolve it locally to the newest version in the bundled checksum table
- preserve existing default and `latest` behavior
- document custom-manifest checksum semantics and update published
bundles
## Testing
- `npm ci --ignore-scripts`
- `npm run all` (99 tests passed)
Closes#919
Refs: pi-session 019fed0e-6019-7504-911b-bd9955cbbd49
## 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.
## Summary
- strip PEP 508 environment markers before extracting uv versions from
dependency entries
- cover dependency-group pins with and without whitespace before the
marker
- cover requirements-style pins with markers
Fixes#920
## Validation
- npm ci --ignore-scripts
- npm run all
Refs: pi-session 019f316a-4108-7975-892f-ee5bf8abc7c3
## 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
