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
* test for pypy new version notation
* formatting
* uncommented condition
* test
* added pypy to test matrix
* test
* test
* restored all tests
* removed logs, added multiarch support for toolcache
* reduced test matrix
* removed extra condition about arch
From February 2021, in order to provide feedback on pull requests, Code Scanning workflows must be configured with both `push` and `pull_request` triggers. This is because Code Scanning compares the results from a pull request against the results for the base branch to tell you only what has changed between the two.
Early in the beta period we supported displaying results on pull requests for workflows with only `push` triggers, but have discontinued support as this proved to be less robust.
See https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#scanning-pull-requests for more information on how best to configure your Code Scanning workflows.
* Add support of unstable Python versions
* Update README
* Get rid of stable boolean input
* Fix typo in the test.yml
* Update README
Co-authored-by: MaksimZhukov <v-mazhuk@microsoft.com>
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>