Closed EliahKagan closed 1 year ago
Thanks! Yes, I used the same pattern in https://github.com/gitpython-developers/GitPython/pull/1654, though (in my mind) not entirely for the same purpose.
Here in gitdb's workflow file, fail-fast
is not explicitly set, so it has its default value of true
, and the main purpose of experimental
here is to weaken that appropriately for 3.12 because it is a prerelease, by setting continue-on-error
to true
for it. While I was at it, I also used it to only permit setup-python
to install a prerelease for 3.12.
In contrast, GitPython's roughly corresponding workflow file explicitly sets fail-fast
to false
, so there is no need to set continue-on-error
, which I didn't do. Instead, I introduced experimental
there just for the purpose of limiting setup-python
to installing a prerelease for 3.12.
Because 3.12 is still a release candidate and if tests fail for it then one would always want to know if/how other versions also fail.
Note that a failure of the 3.12 job will still be treated as a failed check and will still cause the workflow to be considered to have failed, which we probably want. Setting
continue-on-error
for the job just overrides the default matrixfail-fast
behavior, so the 3.12 job won't cause other jobs from the matrix to be cancelled if it fails. (Other jobs will still cause cancellation.)I used a technique based on the one in the GitHub Actions documentation, but modified so all versions can be listed in one place and so the automatically generated job names remain short, as they were before.
This also allows
actions/setup-python
to install a prerelease for 3.12 only, and no longer for other releases. (This is less important, because only under very strange circumstances would only an old prerelease of a stable release be available to the CI runner. But treating 3.12 specially, as above, allows this to be done too, with no increase in complexity.)This may or may not be considered worthwhile, given that it should be undone sometime not long after the stable 3.12.0 comes out. However, I think the
allow-preleases
override totrue
should be undone at that time, so it seems to me that the burden is much the same either way (and the stakes very low, either way, if it is left in place too long).