Use check-latest for setup-python action
#33
Merged
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.
Proposed change
This enables the
check-latestoption for the Python setup action. If a general Python version like3.13is specified,setup-pythonwill make sure the latest patch version is used, even if it's not cached in the GitHub runner.This avoids issues we had in the past where different jobs of the CI workflow used different minor Python versions, leading to cache misses and CI failure.
Note
This is essentially the same behavior as us always pinning the latest Python patch releases, except that this automatically uses the latest patch release when only
x.yis specified. In most cases, it's in the GH runner cache, so the install time should be instant. However, that's not always the case. If not cached, the Python install takes about 10 to 20 seconds.It might actually be better if we don't pin to specific patch versions anymore, as it might be more likely for the latest patch releases to be present in GH runner cache, but not some older patch version we pinned and forgot to update.
This is something we may want to update in a future PR. Both in the shared workflows and all other projects.
(And downstream projects should really stop overriding
CACHE_VERSION...)Further changes
The specific Python version is also added to the pre-commit cache key, as the pre-commit dependencies can differ depending on the Python version used.
allow-prereleaseswas also missing in the pre-commit step. It's unlikely thatPYTHON_VERSION_DEFAULTis a pre-release Python version, but possible, so this prevents only the pre-commit step from failing in that case.Additional information
Also see: