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.
* Improve wording and "fix example" (remove 3.13) on testing against pre-releases
3.13 was added in a mass tune up in 0b93645e9f , without
adjusting the wording. With 3.13 listed there too, example does not really make much
sense. So I decided to make it explicit in wording and remove 3.13, so whenever next
refactoring to add 3.14 to be added to every line where 3.13 is -- this would not
even come to attention
* Update to use 3.14 not 3.12 as an example for pre-release
* 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>
* Revert "Enhance cache-dependency-path handling to support files outside the w…"
This reverts commit 1264885983.
* pckage.json version update
---------
Co-authored-by: Haritha <73516759+HarithaVattikuti@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
* docs: fix outputs python-version example and description
Description was lacking words, example was misleading (id was set to cp310 which clearly was a reference to CPython 3.10, but the id is referring to the setup-python action!
* docs: copy-editing in advanced-usage.md
Signed-off-by: Stephen L. <lrq3000@gmail.com>
* docs: add example if statement in advanced-usage.md
Signed-off-by: Stephen L. <lrq3000@gmail.com>
* docs: implement changes suggested by @mahabaleshwars (deprecate pypy2.7, 3.7, 3.8, tweak example, remove wildcard *)
Signed-off-by: Stephen L. <LRQ3000@gmail.com>
---------
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <LRQ3000@gmail.com>
* initial commit for documentation changes related to rawapi
* documentation changes and added check for validating raw api
* documenation changes for pr
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>
