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.
* Upgrade to node 24
Upgrade ot node
* licence manual updates
* pckage.json version update
* version update
* update package-lock.json
* upgrade `actions/checkout` to v5 and `actions/setup-python` to v6 in README.md
* upgrade `actions/checkout` to v5 and `actions/setup-python` to v6 in advanced-usage.md
Updated GitHub Actions to use newer versions of checkout and setup-python actions.
* node-version update in the workflows
---------
Co-authored-by: Aparna Jyothi <aparnajyothi-y@github.com>
Co-authored-by: priya-kinthali <147703874+priya-kinthali@users.noreply.github.com>
* Support free threaded Python versions like '3.13t'
Python wheels, pyenv, and a number of other tools use 't' in the Python
version number to identify free threaded builds. For example, '3.13t',
'3.14.0a1', '3.14t-dev'.
This PR supports that syntax in `actions/setup-python`, strips the "t",
and adds "-freethreading" to the architecture to select the correct
Python version.
See #771
* Add free threading to advanced usage documentation
* Fix desugaring of `3.13.1t` and add test case.
* Add freethreaded input and fix handling of prerelease versions
* Fix lint
* Add 't' suffix to python-version output
* Use distinct cache key for free threaded Python
* Remove support for syntax like '3.14.0a1'
* Clarify use of 't' suffix
* Improve error message when trying to use free threaded Python versions before 3.13
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`)
* Only use github.token on github.com
This expression evaluates to `''` if called from GHES hosted elsewhere
You can still provide your token on both github.com and GHES
* Enshure blank result of expression and not false
* Revert "Revert "Pass the `token` input through on GHES (#427)" (#437)"
This reverts commit cf86e08a31.
* fix typo
* Add back the doc on the tool cache for self-hosted
Co-authored-by: Brian Cristante <33549821+brcrista@users.noreply.github.com>
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
This pull-request improves `setup-python` action to add ability to download specific version of Python on flight if it is not available by default.
**Details:**
`setup-python` action will download and install specific Python version from GitHub releases ([actions/python-versions](https://github.com/actions/python-versions/releases)) in case the version is not found in the local cache. All versions of Python available for installation are published in [actions/python-versions](https://github.com/actions/python-versions) repository.
All available versions are listed in the [version-manifest.json](https://github.com/actions/python-versions/blob/master/versions-manifest.json) file.
**Installation time:**
- Ubuntu / macOS: 10-20 seconds
- Windows: ~ 1 minute (mostly related to fact that we use MSI installer for Python on Windows)
Co-authored-by: MaksimZhukov <v-mazhuk@microsoft.com>
Co-authored-by: Konrad Pabjan <konradpabjan@github.com>
Co-authored-by: Brian Cristante <33549821+brcrista@users.noreply.github.com>
