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 :).
Rolls up the current open Dependabot npm updates:
- #848 esbuild from 0.27.5 to 0.28.0
- #847 undici from 8.0.0 to 8.3.0
- #846 ts-jest from 29.4.9 to 29.4.11
- #841 @biomejs/biome from 2.4.10 to 2.4.15, including the matching
biome.json schema URL update
Validation:
- npm run all
Rolls up the current open Dependabot npm updates:
- #848 esbuild from 0.27.4 to 0.27.5
- #847 undici from 7.24.2 to 8.0.0
- #846 ts-jest from 29.4.6 to 29.4.9
- #841 @biomejs/biome from 2.4.7 to 2.4.10, including the matching
biome.json schema URL update
- #834 smol-toml from 1.6.0 to 1.6.1
Validation:
- npm run all
## 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
## Summary
- add top-level uncaughtException and unhandledRejection handlers for
the setup entrypoint
- report unexpected failures through core.setFailed with stack/context
- regenerate the committed setup bundle
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.
## Summary
- replicate the currently open Dependabot dependency updates in a single
branch
- update `smol-toml` to `^1.6.0`
- update `@biomejs/biome` to `2.3.8`
- regenerate `package-lock.json` and bundled `dist` output
## Notes
- `main` already includes the open Octokit Dependabot bumps, so those
PRs required no additional net changes here
- the open `smol-toml` Dependabot PR currently resolves to `^1.6.0`,
which is what this branch mirrors
## Validation
- `npm run all`
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
