| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Need to research more about how continue-on-error works, for now I think it's fine to remove the failing 3.12-dev from the matrix until python-greenlet/greenlet#323 is resolved. I also removed unsupported pypy3.7. |
Sorry, something went wrong.
|
Please see PR #264 to replace this. |
Sorry, something went wrong.
| # Skip 3.12-dev, pending https://github.com/python-greenlet/greenlet/issues/323 | ||
| python: [pypy3.8, pypy3.9, "3.7", "3.8", "3.9", "3.10", 3.11-dev] |
There was a problem hiding this comment.
If I'm understanding https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#handling-failures correctly, we can achieve what we want to with something like:
continue-on-error: ${{ matrix.failure-allowed }}
strategy:
fail-fast: false
matrix:
# Test all supported versions on Ubuntu:
os: [ubuntu-latest]
python: [pypy3.8, pypy3.9, "3.7", "3.8", "3.9", "3.10", 3.11-dev]
failure-allowed: [false]
include:
# Also test macOS and Windows:
- os: macos-latest
python: "3.10"
failure-allowed: false
- os: windows-latest
python: "3.10"
failure-allowed: false
# Also test in-development version (allowing failures):
- os: ubuntu-latest
python: "3.12-dev"
failure-allowed: true
Sorry, something went wrong.
There was a problem hiding this comment.
failure-allowed is a verb/phrase that we can change as we wish to communicate things via the variable name. The example from GitHub used experimental.
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks, I did try something along those lines, but wasn't successful.
Although I think #264 is a better approach? Then we'll at least see if the non-greenlet tests fail for 3.12. And when greenlet installs for 3.12, it'll start testing those too.
Sorry, something went wrong.
There was a problem hiding this comment.
Looking at your force-pushed events' diffs, I don't see continue-on-error: ${{ matrix.failure-allowed }} being added at any point at the job.<id> level; which might be why they didn't work?
Regardless, they're both valid approaches to solving the problem so it's not a big deal which one we go with. :)
Sorry, something went wrong.
There was a problem hiding this comment.
I also tried it in another branch:
test:
runs-on: ${{ matrix.os }}
name: ${{ matrix.os }} - ${{ matrix.python }}
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: false
matrix:
# Test all supported versions on Ubuntu:
os: [ubuntu-latest]
python: [pypy3.7, pypy3.8, pypy3.9, "3.7", "3.8", "3.9", "3.10", 3.11-dev]
experimental: [false]
include:
# Also test macOS and Windows:
- os: macos-latest
python: "3.10"
experimental: false
- os: windows-latest
python: "3.10"
experimental: false
# Allow 3.12-dev to fail pending https://github.com/python-greenlet/greenlet/issues/323
- os: ubuntu-latest
python: 3.12-dev
experimental: trueVery similar to your snippet:
But still failed a PR: hugovk#3
Sorry, something went wrong.
There was a problem hiding this comment.
Indeed! Thanks for clarifying! ^.^
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
At the moment the 3.12-dev builds are failing, causing every build to show as failed.
It's failing because Greenlet doesn't yet support 3.12. The tracking issue is at python-greenlet/greenlet#323 and there's a PR at python-greenlet/greenlet#327 but it's not ready yet.
In the meantime, we can mark 3.12-dev as "experimental", so whilst the individual job still fails, it doesn't mark the whole build as failed.
Docs: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error
Also bump GitHub Actions, allow building feature branches, and we can fold the PyPy config into the main list. workflow_dispatch adds a button to the UI to be able to trigger new builds, occasionally useful.
Shall we also remove pypy3.7? The newest PyPy only supports 3.8 and 3.9: