-
Notifications
You must be signed in to change notification settings - Fork 66
Don't cancel other jobs from the 3.12 job failing #93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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. This also allows actions/setup-python to install a prerelease for 3.12 only, not for other releases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot! I think this is similarly implemented in GitPython (soon) and it's a neat way of achieving this.
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.
This updates smmap's CI configuration in ways that are in line with recent updates to gitdb's. In most cases there is no difference in the changes, and the reason for the updates is more to avoid confusing differences than from the value of the changes themselves. In one case, there is a major difference (fetch-depth). - gitpython-developers/gitdb#89 (same) - gitpython-developers/gitdb#90 (same) It's just the project, not dependencies, but otherwise the same. - gitpython-developers/gitdb#92 (opposite) This is the major difference. We don't need more than the tip of the branch in these tests. Keeping the default fetch-depth of 1 by not setting it explicitly avoids giving the impression that the tests here are doing something they are not (and also serves as a speed optimization). - gitpython-developers/gitdb#93 (same)
Uh oh!
There was an error while loading. Please reload this page.
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-errorfor the job just overrides the default matrixfail-fastbehavior, 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-pythonto 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-preleasesoverride totrueshould 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).