This workflow file publishes new action releases to the immutable action package of the same name as this repo.
This is part of the Immutable Actions project which is not yet fully released to the public. First party actions like this one are part of our initial testing of this feature.
* 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
* initial commit for documentation changes related to rawapi
* documentation changes and added check for validating raw api
* documenation changes for pr
* 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`)
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).
The old matcher only worked if the error was raised with `raise Exception('single quotes')`.
This represents a miniscule fraction of errors; for instance, `l[37]` on a short list `l` can raise `IndexError`, and any call to a builtin C function is not going to trace back to a `raise` call.
Instead, this just matches the first line without fail that comes after the context line.
Note that this is still not foolproof; in Python 3.10, `SyntaxError`s are produced as
```
File "<stdin>", line 1
foo(x, z for z in range(10), t, w)
^^^^^^^^^^^^^^^^^^^^
SyntaxError: Generator expression must be parenthesized
```
This matcher will incorrectly pick up ` ^^^^^^^^^^^^^^^^^^^^` as the error message, but the previous behavior was to not pick up any error message at all.
As far as I can tell, this is impossible to handle correctly; the grammar of problem matchers is far too limiting.
* 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 versioning scheme is consistent with other
tools in the python ecosystem so it feels more natural
and allows better interaction with other tools.
fixes#346
`pypyX.Y.exe` executables are missing from PyPy archives on Windows before v7.3.9 (X.Y < 3.9)
`pypy2.7` symlinks are also missing from macOS/Linux PyPy archives before v7.3.9
relates to #346
* Rework python-pipenv-dependencies-caching test
* Update Pipfile.lock hash in the tests
* Rework python-pipenv-dependencies-caching-path test
* Set location for pipenv test
* Remove requests package from tests
* Test pipenv without caching
* Enable pipenv cache
