Don't cancel other jobs from the 3.12 job failing

[EliahKagan]

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 matrix fail-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 to true 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).

[Byron]

Thanks a lot! I think this is similarly implemented in GitPython (soon) and it's a neat way of achieving this.

[EliahKagan]

Thanks! Yes, I used the same pattern in gitpython-developers/GitPython#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.