This commit is contained in:
Stephen Karl Larroque 2023-12-06 13:36:21 +01:00 committed by GitHub
commit 5b57765ba8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -101,7 +101,7 @@ steps:
- run: python my_script.py
```
- **[x-ranges](https://github.com/npm/node-semver#x-ranges-12x-1x-12-)** to specify the latest stable version of Python (for specified major version):
- **[x-ranges](https://github.com/npm/node-semver#x-ranges-12x-1x-12-)** to specify the latest stable version of Python (for the specified major version):
```yaml
steps:
@ -144,7 +144,7 @@ jobs:
python-version: ${{ matrix.python-version }}
- run: python my_script.py
```
More details on PyPy syntax can be found in the [Available versions of PyPy](#pypy) section.
More details on the syntax for PyPy can be found in the [Available versions of PyPy](#pypy) section.
### Specifying multiple Python/PyPy version
The python-version input can get multiple python/pypy versions. The last specified version will be used as a default one.
@ -204,7 +204,7 @@ jobs:
### Matrix Testing
Using `setup-python` it's possible to use [matrix syntax](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix) to install several versions of Python or PyPy:
Using `setup-python` it's possible to use the [matrix syntax](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix) to install several versions of Python or PyPy:
```yaml
jobs:
@ -246,12 +246,13 @@ jobs:
with:
python-version: ${{ matrix.python-version }}
- name: Display Python version
if: ${{ python-version != 'pypy2.7' }} # in if statements, use single-quotes (not double-quotes) in expressions to test input `python-version`
run: python --version
```
## Using the `python-version-file` input
`setup-python` action can read Python or PyPy version from a version file. `python-version-file` input is used for specifying the path to the version file. If the file that was supplied to `python-version-file` input doesn't exist, the action will fail with error.
`setup-python` action can read the Python or PyPy version from a version file. `python-version-file` input is used to specify the path to the version file. If the file that was supplied to `python-version-file` input doesn't exist, the action will fail with an error.
>In case both `python-version` and `python-version-file` inputs are supplied, the `python-version-file` input will be ignored due to its lower priority.
@ -288,7 +289,7 @@ steps:
check-latest: true
- run: python my_script.py
```
> Setting `check-latest` to `true` has performance implications as downloading `Python or PyPy` versions is slower than using cached versions.
> Setting `check-latest` to `true` impacts performance as downloading `Python or PyPy` versions is slower than using cached versions.
## Caching packages
@ -381,7 +382,7 @@ steps:
### `python-version`
Using **python-version** output it's possible to get the installed by action Python or PyPy version. This output is useful when the input `python-version` is given as a range (e.g. 3.8.0 - 3.10.0 ), but down in a workflow you need to operate with the exact installed version (e.g. 3.10.1).
Using **python-version** output, it's possible to get the precise Python or PyPy version installed by the action. This output is useful when the input `python-version` is given as a range (e.g. 3.8.0 - 3.10.0, 3.x, * ), but down the line you need to operate (such as in an `if:` statement) with the exact installed version (e.g. 3.10.0).
```yaml
jobs:
@ -390,15 +391,15 @@ jobs:
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v4
id: cp310
id: setuppy
with:
python-version: "3.8.0 - 3.10.0"
- run: echo '${{ steps.cp310.outputs.python-version }}'
- run: echo '${{ steps.setuppy.outputs.python-version }}'
```
### `python-path`
**python-path** output is available with the absolute path of the Python or PyPy interpreter executable if you need it:
**python-path** output is available to get the absolute path of the Python or PyPy interpreter executable:
```yaml
jobs:
@ -447,7 +448,7 @@ The `update-environment` flag defaults to `true`.
With this setting, the action will add/update environment variables (e.g. `PATH`, `PKG_CONFIG_PATH`, `pythonLocation`) for Python or PyPy to just work out of the box.
If `update-environment` is set to `false`, the action will not add/update environment variables.
This can prove useful if you want the only side-effect to be to ensure Python or PyPy is installed and rely on the `python-path` output to run executable.
This can prove useful if you only want the side-effect to ensure that Python or PyPy is installed and rely on the `python-path` output to run the executable.
Such a requirement on side-effect could be because you don't want your composite action messing with your user's workflows.
```yaml
@ -467,7 +468,7 @@ Such a requirement on side-effect could be because you don't want your composite
- Preinstalled versions of Python in the tool cache on GitHub-hosted runners.
- For detailed information regarding the available versions of Python that are installed, see [Supported software](https://docs.github.com/en/actions/reference/specifications-for-github-hosted-runners#supported-software).
- For every minor version of Python, expect only the latest patch to be preinstalled.
- For every minor versions of Python, expect only the latest patch to be preinstalled.
- If `3.8.1` is installed for example, and `3.8.2` is released, expect `3.8.1` to be removed and replaced by `3.8.2` in the tool cache.
- If the exact patch version doesn't matter to you, specifying just the major and minor versions will get you the latest preinstalled patch version. In the previous example, the version spec `3.8` will use the `3.8.2` Python version found in the cache.
- Use `-dev` instead of a patch number (e.g., `3.12-dev`) to install the latest patch version release for a given minor version, *alpha and beta releases included*.
@ -532,11 +533,11 @@ If you have a supported self-hosted runner and you would like to use `setup-pyth
### Linux
By default runner downloads and installs tools into the folder set up by `RUNNER_TOOL_CACHE` environment variable. The environment variable called `AGENT_TOOLSDIRECTORY` can be set to change this location for Linux self-hosted runners:
By default, the runner downloads and installs tools into the folder set up by `RUNNER_TOOL_CACHE` environment variable. The environment variable called `AGENT_TOOLSDIRECTORY` can be set to change this location for Linux self-hosted runners:
- In the same shell that your runner is using, type `export AGENT_TOOLSDIRECTORY=/path/to/folder`.
- More permanent way of setting the environment variable is to create an `.env` file in the same directory as your runner and to add `AGENT_TOOLSDIRECTORY=/path/to/folder`. This ensures the variable is always set if your runner is configured as a service.
If you're using a non-default tool cache directory be sure that the user starting the runner has write permission to the new tool cache directory. To check the current user and group that the runner belongs type `ls -l` inside the runner's root directory.
If you're using a non-default tool cache directory be sure that the user starting the runner has write permission to the new tool cache directory. To check the current user and group that the runner belongs, type `ls -l` inside the runner's root directory.
The runner can be granted write access to any directory using a few techniques:
- The user starting the runner is the owner, and the owner has write permission.