## 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 :).
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
## 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
