workflows: Fix duplicate 3.11 job while still listing all versions together #249
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This gives all Python versions to setup-python as strings rather than as numbers. That was already being done, and must be done, for 3.10, which otherwise would become 3.1, but it was also already being done for 3.11, suggesting no strong preference for minimal quoting.
EliahKagan
force-pushed
the
logic-for-experimental
branch
from
e08f095
to
0c81b14
Compare
EliahKagan
changed the title
This fixes the following two problems: - GitHub Actions generated two separate jobs for Python 3.11 because the "python-version" and "experimental" lists in the CI matrix generated a job for it with experimental=false, and then the "include" list that augments the CI matrix generated a separate job for it with experimental=true. - The list of jobs is somewhat difficult to understand in the GitHub Actions interface, because the "python-version" and "experimental" keys are show in different orders, due to the different orders the workflow file listed them.
This lists all Python versions in the same list, given as the value of the python-version key for the matrix, as was done in the past. However, it still avoids producing two separate experimental and non-experimental jobs for the same version that is intended to be experimental, by listing both general and overridden "experimental" keys in "include", and *not* listing "experimental" outside "include". This gives the workflow readability benefit of the old code, while still fixing the problem that a separate non-experimental job was also generated.
EliahKagan
force-pushed
the
logic-for-experimental
branch
from
0c81b14
to
bd5a34f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #248
This stops a separate
experimental=falsetest job from being created alongside the intendedexperimental=truejob for the latest version, by moving all introduction of theexperimentalkey into theincludelist. (This is possible solution 3 in #248.)This could be done slightly more compactly by simply omitting the latest version from the initial list, but I think that would make it significantly less clear, in reading the workflow, what versions are being tested. It could be done even more compactly by removing the "experimental" logic altogether, since 3.11 no longer requires it, but I don't think that's the best approach because such logic is likely to be wanted for 3.12 soon. I've explored these considerations in more detail in #248.
The approach used here has the additional benefit--or at least I consider it a benefit--that, because the
experimentalkey is added only in theincludelist, it is not made part of the job names shown in the GitHub Actions web interface.I've also quoted all X.Y version numbers; although this only needs to be done for 3.10 and already was, it was also done for 3.11, suggesting no strong preference for minimal quoting. I think putting them all in the same style makes it easier to see what's going on. I did it originally to help myself avoid making a mistake when making the other changes, and I think it may make sense to keep it in. Of course, I'd be pleased to remove that change if it is not wanted, as well as to make any other requested changes to this PR.