- scope mirror-token to the mirror host and send it verbatim
- route non-repo mirrors straight to the URL fetch instead of throwing
- authenticate the manifest fetch
- warn on slash branches, and on mirror with PyPy/GraalPy
- memoize mirror validation
- exercise the direct-URL path in the E2E job
Addresses https://github.com/actions/setup-python/pull/1302#issuecomment-5202618946
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
* Add RHEL support for manifest matching and OS detection
* update dist
* make cache keys distro-aware and key RHEL by major version
* Normalize RHEL OS detection and improve cache key consistency
* Refactor OS info retrieval to use getOSInfo and handle null cases for improved reliability
* Revert "Enhance cache-dependency-path handling to support files outside the w…"
This reverts commit 12648859835f68b273febdd9aab9972bbb624d8c.
* pckage.json version update
---------
Co-authored-by: Haritha <73516759+HarithaVattikuti@users.noreply.github.com>
* Enhance reading from .python-version
* Fix typos
* Fix lint
* Add built files
* Don't use EOL versions in `utils.test.ts`
* Fix Prettier
* Don't use unreleased versions in `utils.test.ts`
* Update versions in `utils.test.ts` again
* 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
* 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
* Add support for graalpy
* add graalpy test workflow
* format, lint and build
* symlink graalpy binaries names
* fix macos names for graalpy
* Don't attempt to update pip for graalpy
* Remove test schedule
* Extract common getBinaryDirectory function for PyPy and GraalPy
* Clean up and format
* Pass GitHub token to GraalPy queries
* Utilize pagination when querying GraalPy GitHub releases
* Build
* Fix lint errors
* Deal with possible multiple artifacts for a single releases
* Skip few GraalPy tests on windows - we don't have a windows release yet
* Fix GraalPy test on Mac OS
* Build
* Skip one more GraalPy test on windows
---------
Co-authored-by: Michael Simacek <michael.simacek@oracle.com>
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`)
* Use correct Poetry config when collecting Poetry projects
When collecting Poetry projects for caching, a '**/poetry.lock' glob is
used. However, in order to process the Poetry configuration, the
"poetry" command is run from the repo's root directory; this causes
Poetry to return an invalid configuration when there is a Poetry project
inside an inner directory.
Instead of running a single Poetry command, glob for the same pattern,
and run a Poetry command for every discovered project.
* Fix typo: saveSatetSpy -> saveStateSpy
* poetry: Support same virtualenv appearing in multiple projects
* Add nested Poetry projects test
* poetry: Set up environment for each project individually
* tests/cache-restore: Do not look for dependency files outside `data`
When the default dependency path is used for cache distributors, they
are looking for the dependency file in the project's root (including the
source code), which leads to tests taking a significant amount of time,
especially on Windows runners. We thus hit sporadic test failures.
Change the test cases such that dependency files are always searched for
inside of `__tests__/data`, ignoring the rest of the project.
* poetry: Simplify `virtualenvs.in-project` boolean check
* README: Explain that poetry might create multiple caches
* poetry: Run `poetry env use` only after cache is loaded
The virtualenv cache might contain invalid entries, such as virtualenvs
built in previous, buggy versions of this action. The `poetry env use`
command will recreate virtualenvs in case they are invalid, but it has
to be run only *after* the cache is loaded.
Refactor `CacheDistributor` a bit such that the validation (and possible
recreation) of virtualenvs happens only after the cache is loaded.
* poetry: Bump cache primary key
