Repository navigation
Pin uv to 0.13.7 in the workflow and guard it with required-version - #11
Merged
Merged
Conversation
astral-sh/setup-uv is pinned by commit, which pins the installer, not the tool: with no `version` input the action installs the latest uv. Adds `version: "0.13.7"` to 2 steps and `required-version = "==0.13.7"` to [tool.uv]` in `pyproject.toml, the same value in the same commit, so the two can only drift together.
This file contains hidden or 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
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.
astral-sh/setup-uvis pinned to a full commit SHA, but the pin covers the installer: the uv version it installs comes from theversioninput, and with noversionpassed the action resolvesrequired-versionfromuv.toml/pyproject.tomland, finding none, installs the latest uv. So this workflow reads as pinned while the tool it installs floats. That is the same shape as apandoc/actions/setuppin that installs the latest pandoc.This change makes the installed uv a declared value and puts a guard beside it:
.github/workflows/gates.ymlgates.github/workflows/gates.ymlgnn-conformanceversion: "0.13.7"is added to every such step. 0.13.7 is the current latest release and therefore what these steps install today — the change declares the version rather than moving it.required-version = "==0.13.7"is added in[tool.uv]inpyproject.toml. It is the same value in the same commit, deliberately: uv refuses to run when the running version does not satisfy the guard ("Required uv version ==X does not match the running version Y", exit 2), so aversion:that drifts from the guard turns the run red on the push that drifts it instead of silently installing a different tool. Bump the two together. Auvinvocation that disables project discovery (--no-project) is not covered by the guard.Verified before opening: the workflow parses as YAML and the manifest as TOML; the guard is enforced and satisfied by a project-aware command in the repository (
uv lock --checkexit 0 where auv.lockexists,uv pip listexit 0 where it does not); and a deliberately mismatched guard was confirmed to makeuv lock --checkexit 2, so the guard is demonstrated to fail rather than assumed to.Step order is load-bearing in this file. The two
uvx ruffsteps (gates.yml:31-32) run outside the guard's reach —uvxdoes not construct the project, sorequired-versionis not consulted (measured). What covers this repository isuv sync --frozenatgates.yml:27, the first project-aware command in the same job; if a future edit moves the lint steps above it, or moves that sync into another job, the lint half stops being guarded while still reading as pinned.