Standardise astral-sh/setup-uv on v7 (#203) - #222
Conversation
|
Claude finished @realmarcin's task in 2m 18s —— View job Review: approved ✅
Verified against the repo rather than the description. All call sites converged, none missed. grep for The v3→v7 jump is safe for these specific call sites, and not by luck. The breaking change that usually bites on this bump is v6 no longer activating the environment — it only applies when The self-test claim in the description holds. No 🔴, no 🟡. Two optional notes: 🔵 🔵 I could not verify the v8/v9 floating-tag claim — this review environment has no network access, so I'm taking the tag listing and release notes in the description on trust. It doesn't change the verdict: staying at v7 is the conservative choice either way, and CI proves it works. The related point that all of these are mutable major tags rather than SHA pins is unchanged by this PR and you already flag it as a separate deliberate decision. Advisory only: No --- · branch |
There was a problem hiding this comment.
🟢 Ready to approve
The changes are a mechanical, repo-wide version alignment with no workflow-structure changes and no remaining mixed setup-uv major versions detected.
This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.
Pull request overview
This PR standardizes usage of the GitHub Action astral-sh/setup-uv across the repository’s CI workflows by aligning all remaining call sites to the same major version (v7), eliminating drift between workflows.
Changes:
- Bump
astral-sh/setup-uvfrom@v3to@v7in core CI workflows. - Bump
astral-sh/setup-uvfrom@v5to@v7inlabel-correspondence.yaml. - Leaves already-
@v7workflows (curation-history.yaml,claude-code-review.yml) unchanged, resulting in consistent@v7usage across all workflows.
File summaries
| File | Description |
|---|---|
| .github/workflows/validate-strict.yaml | Update setup-uv to @v7 for strict validation job consistency. |
| .github/workflows/qc.yaml | Update setup-uv to @v7 to match the standardized toolchain setup. |
| .github/workflows/pytest.yaml | Update setup-uv to @v7 for consistent uv installation and caching behavior. |
| .github/workflows/pr-sanity.yaml | Update setup-uv to @v7 so the always-on PR checks use the same uv setup. |
| .github/workflows/label-correspondence.yaml | Update setup-uv to @v7 while keeping the existing version: "latest" input. |
Review details
- Files reviewed: 5/5 changed files
- Comments generated: 0
- Review effort level: Lite
We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.
![culturebot-reviewer[bot]](https://avatars.githubusercontent.com/u/233210009?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verified against the repo rather than the description.
All call sites converged, none missed. grep for setup-uv across the tree returns exactly seven hits, all @v7: the five changed here plus curation-history.yaml and claude-code-review.yml. Nothing outside .github/workflows/ references the action.
The v3→v7 jump is safe for these specific call sites, and not by luck. The breaking change that usually bites on this bump is v6 no longer activating the environment — it only applies when python-version is passed to setup-uv. No call site does. Every one installs via uv python install 3.12 + uv sync and invokes through uv run/just, so nothing depends on VIRTUAL_ENV being set by the action.
The self-test claim in the description holds. qc.yaml, pytest.yaml, validate-strict.yaml and label-correspondence.yaml each list their own path in their paths: filter, and pr-sanity.yaml is deliberately unfiltered — so all five do run on this PR. All five are green, plus vendored-sync. That is real evidence, not an argument.
No 🔴, no 🟡. Two optional notes:
🔵 label-correspondence.yaml:48 still carries version: "latest", which the other six call sites don't set. After this PR the action tag is uniform but the uv version isn't — that one job can pick up a new uv release ahead of the others on the same commit. Pre-existing, not introduced here, but it's the one thing left non-standard by a standardisation PR. Dropping it would finish the job.
🔵 I could not verify the v8/v9 floating-tag claim — this review environment has no network access, so I'm taking the tag listing and release notes in the description on trust. It doesn't change the verdict: staying at v7 is the conservative choice either way, and CI proves it works. The related point that all of these are mutable major tags rather than SHA pins is unchanged by this PR and you already flag it as a separate deliberate decision.
Advisory only: NEXT_TASKS.md:30 and :466 still list #203 as open. That file is reconciled in batches (its header already predates this PR), so this is for the next reconcile, not for this branch.
No data/traits/** changes, so no history/ record is expected.
|
Claude finished @realmarcin's task in 1m 28s —— View job Re-review after
|
There was a problem hiding this comment.
Re-reviewed the delta since my earlier approval. The only new change is dropping version: "latest" from label-correspondence.yaml, which is what I asked for.
The removal is a genuine no-op today, and an improvement tomorrow. I checked why rather than assuming: there is no [tool.uv] table in pyproject.toml, no uv.toml, and no .uv-version file, so setup-uv v7 has nothing to resolve a version from and falls back to installing the latest uv — exactly what the explicit input was asking for. Behaviour on this commit is unchanged. The difference is forward-looking: if anyone later adds a required-version pin, the six other call sites will honour it and this one no longer overrides it.
All seven call sites are now byte-identical in intent. astral-sh/setup-uv@v7 with enable-cache: true, everywhere except curation-history.yaml:50, which passes no with: block at all and so runs uncached. Pre-existing, unrelated to the version question this PR set out to settle, and not worth holding the branch for — noting it only because it is the last remaining asymmetry.
No 🔴, no 🟡.
One honesty note on evidence: pr-sanity, qc, pytest, validate-strict and vendored-sync are green on 47b44b1d, but label-correspondence — the single workflow this commit actually touches — is still running as I write. I am approving on the resolution argument above rather than on its result; if it comes back red, that argument was wrong and this needs another look.
No data/traits/** changes, so no history/ record is expected.
Seven workflows were spread across three majors — v3 x4, v5, v7 x2 — which got worse rather than better since #203 was filed, because #210 added claude-code-review.yml on v7. Nothing pinned v3 deliberately; #201 chose it by copying qc.yaml, the majority at the time. v7 is the right target, and not merely because it is newest. It is the newest major *tag* that exists: v8 removed the update-major-minor-tags workflow, so v8 and v9 ship releases but publish no `vN` ref. Anything above v7 would have to be pinned to a full version or a SHA, which is a different decision from this one. Checked before bumping rather than after: - Every call site passes only `enable-cache: true`, plus `version: "latest"` on label-correspondence. Both inputs are present in v7's action.yml (23 inputs; enable-cache defaults to `auto`, version to empty). - v7 + `enable-cache: true` is already exercised in this repo — claude-code-review.yml has run it green repeatedly today — so the combination is not theoretical. - v9 changes the `prune-cache` default to false; v7 still defaults it true. Not a concern here, but it is the kind of thing that makes a later jump to a SHA pin worth doing deliberately. All seven workflows still parse and keep their on:/jobs: keys. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pinning the action tag standardised which setup-uv runs, but label-correspondence.yaml was the only call site also passing version: "latest" — so that one job could pick up a new uv release ahead of the other six on the same commit. A standardisation PR leaving exactly one job non-standard is the wrong place to stop. Nothing pins a uv version (no [tool.uv] required-version, no .uv-version), so with the input gone all seven resolve uv identically. Remaining asymmetry, deliberately untouched: curation-history.yaml passes no `with:` at all and so gets no enable-cache. That is a caching choice rather than a version one, and outside what #203 is about. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
47b44b1 to
3d63886
Compare
|
Claude finished @realmarcin's task in 2m 7s —— View job Re-review after
|
There was a problem hiding this comment.
Re-review after the force-push to 3d638864.
The push carried no content change. ad500941 is unchanged and the tip was re-created — same tree. git diff origin/main...HEAD is byte-for-byte what I approved at 47b44b1d: four @v3→@v7, one @v5→@v7, and the version: "latest" drop in label-correspondence.yaml. Merge base is still 54da2f99, so nothing new from main came in either. Nothing to re-litigate; I re-verified the substance rather than assuming.
The evidence gap from my last pass is now closed. I approved 47b44b1d on a resolution argument because label-correspondence — the only workflow that commit touched — was still running. On 3d638864 it is green, along with qc, pytest, validate-strict, pr-sanity and vendored-sync. The argument held: no [tool.uv] in pyproject.toml, no uv.toml, no .uv-version, so dropping the explicit latest resolves to the same uv. That is now a result, not a prediction.
Still seven call sites, still uniform. All astral-sh/setup-uv@v7. The v6 environment-activation break does not apply anywhere here: label-correspondence.yaml:41 gets Python from actions/setup-python@v5, not from setup-uv, and every recipe it calls (justfile:423, :428) goes through uv run, so nothing depends on the action exporting VIRTUAL_ENV.
No 🔴, no 🟡. curation-history.yaml:50 still passes no with: block and so runs uncached — pre-existing, orthogonal to the version question, and I would not hold the branch for it.
No data/traits/** changes, so no history/ record is expected. NEXT_TASKS.md:30 and :469 still list #203 as open — for the next batch reconcile, not for this branch.
Closes #203.
Seven workflows were spread across three majors, and it had drifted further since the issue was filed — #210 added
claude-code-review.ymlon v7, so the count went from v3×4/v5/v7 to v3×4/v5/v7×2.pr-sanity.yamlpytest.yamlqc.yamlvalidate-strict.yamllabel-correspondence.yamlcuration-history.yamlclaude-code-review.ymlNothing pinned v3 deliberately — as #203 notes, #201 picked it by copying
qc.yaml, the majority convention at the time.Why v7 and not v9
v7 is not just the newest thing that works; it is the newest major tag that exists:
v8's release notes say "Remove update-major-minor-tags workflow" — so v8 and v9 ship releases but publish no floating
vNref. Moving above v7 means pinning a full version or a SHA, which is a separate decision with different maintenance properties. Worth taking deliberately rather than as a side effect of this cleanup.Checked before bumping, not after
enable-cache: true, plusversion: "latest"onlabel-correspondence.yaml. Both are present in v7'saction.yml(23 inputs;enable-cachedefaults toauto,versionto empty).claude-code-review.ymlhas run@v7withenable-cache: truegreen repeatedly today, so this isn't a theoretical compatibility argument.prune-cachedefault from true to false, which would increase Actions cache usage. Irrelevant at v7, but it is the sort of thing that makes an eventual SHA pin worth doing on purpose.All seven workflows still parse and retain their
on:/jobs:keys.This PR touches
qc.yaml,pytest.yaml,validate-strict.yaml,pr-sanity.yamlandlabel-correspondence.yaml, so CI exercises the bump on itself — every one of those jobs runs here.🤖 Generated with Claude Code