Users who need custom CPython builds (internal mirrors, GHES-hosted forks,
special build configurations, compliance builds, air-gapped runners) could not
previously point setup-python at anything other than actions/python-versions.
Adds two new inputs:
- `mirror`: base URL hosting versions-manifest.json and the Python
distributions it references. Defaults to the existing
https://raw.githubusercontent.com/actions/python-versions/main.
- `mirror-token`: optional token used to authenticate requests to the mirror.
If `mirror` is a raw.githubusercontent.com/{owner}/{repo}/{branch} URL, the
manifest is fetched via the GitHub REST API (authenticated rate limit applies);
otherwise the action falls back to a direct GET of {mirror}/versions-manifest.json.
Token interaction
-----------------
`token` is never forwarded to arbitrary hosts. Auth resolution is per-URL:
1. if mirror-token is set, use mirror-token
2. else if token is set AND the target host is github.com,
*.github.com, or *.githubusercontent.com, use token
3. else send no auth
Cases:
Default (no inputs set)
mirror = default raw.githubusercontent.com URL, mirror-token empty,
token = github.token.
→ manifest API call and tarball downloads use `token`.
Identical to prior behavior.
Custom raw.githubusercontent.com mirror (e.g. personal fork)
mirror-token empty, token = github.token.
→ manifest API call and tarball downloads use `token`
(target hosts are GitHub-owned).
Custom non-GitHub mirror, no mirror-token
mirror-token empty, token = github.token.
→ manifest fetched via direct URL (no auth attached),
tarball downloads use no auth.
`token` is NOT forwarded to the custom host — this is the
leak-prevention case.
Custom non-GitHub mirror with mirror-token
mirror-token set, token may be set.
→ manifest fetch and tarball downloads use `mirror-token`.
Custom GitHub mirror with both tokens set
mirror-token wins. Used for both the manifest API call and
tarball downloads.
* include freethread e2e testing and upgrade cache from 4.0.0 to 4.0.2
* include verify gil step and validated python version
* Rename files
* include ubuntu-arm runners for testing
* fix(ci): update all failing workflows
With `macos-latest` moving to `macos-14`, most workflows are currently failing.
Update them to be able to run on `macos-latest`
Don't test python 3.5 on ubuntu. It's been EOL for almost 4 years and there are now some certificate issues with pip.
* review: remove test with python 3.5, 3.6 & 3.7
* add latest versions to e2e-tests.yml
This allows to specify version like `3.11` or `pypy3.10` in workflows before those versions are released.
This lessen the burden for users of `setup-python` by not having to modify their workflow twice: once when a pre-release is available (e.g. `3.11-dev`) and once when the first stable release is published (e.g. `3.11`)
This option allows to specify if the action shall update environment variables (default) or not.
This allows to use the setup-python action in a composite action without side effect (except downloading/installing python if version is missing).
* add support for python-version-file
* Update action.yml
* update to v4, remove python-version default
* python-version overrides python-version-file, like setup-node
* checks '.python-version' by default if nothing else specified
* update tests, update to checkout@v3
* update build
* appease the linter
* remove old test for default python version
* revert readme changes
* update build
