Repository navigation
Fix: Run setup-uv in the action directory - #238
Open
ModeSevenIndustrialSolutions wants to merge 1 commit into
Open
ModeSevenIndustrialSolutions wants to merge 1 commit into
ModeSevenIndustrialSolutions wants to merge 1 commit into
Conversation
setup-uv worked in the caller's workspace, its default
working-directory. There it ran 'uv python find' and then executed
the interpreter found, which a .venv or a .python-version in the
workspace chooses, and it read required-version and cache-dir from a
uv.toml or pyproject.toml there with its own code. Documented use
puts no other repository's files in the workspace, but nothing stops
a caller running the action after checking out pull request code.
The step now sets working-directory to github.action_path, so the
interpreter lookup and the uv settings come from this action's own
files. UV_NO_CONFIG, UV_SYSTEM_PYTHON and UV_NO_PROJECT on the step
cover the action sitting inside the workspace ('uses: ./'), where the
workspace is a parent of that directory. The python-version input is
not used: it would export UV_PYTHON to every later step of the
caller's job.
The default cache-dependency-glob now hashes this action's pyproject,
uv.lock and runtime pin instead of whatever the caller's workspace
holds. Those files decide what uvx installs into the cache, so the key
tracks the cached content; for this repository's own workflows,
which check out the same commit, the hashed files are unchanged.
The run step's uvx call is unchanged: run from a workspace holding
all three plants, with uv 0.11.21 and 0.13.4, uvx neither executes
the planted interpreters nor reads the planted uv.toml.
testing.yaml now plants a .venv and a .python-version whose
interpreters only append to a marker file, plus a uv.toml with an
unusable cache-dir and required-version, before running the action,
then asserts its outputs and that no marker exists. Replayed locally
with the real setup-uv v10.3.3: the old step stops on the planted
required-version, and without the uv.toml it executes the planted
interpreter; the new step installs uv, never runs a planted
interpreter, and the action completes with failed=false.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Matthew Watkins <mwatkins@linuxfoundation.org>
ModeSevenIndustrialSolutions
requested review from
a team
and
a balanced review from Copilot
October 30, 2026 08:35
This branch has not been deployed
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.

Summary
setup-uv worked in the caller's workspace, its default working-directory. There it ran 'uv python find' and then executed the interpreter found, which a .venv or a .python-version in the workspace chooses, and it read required-version and cache-dir from a uv.toml or pyproject.toml there with its own code. Documented use puts no other repository's files in the workspace, but nothing stops a caller running the action after checking out pull request code.
The step now sets working-directory to github.action_path, so the interpreter lookup and the uv settings come from this action's own files. UV_NO_CONFIG, UV_SYSTEM_PYTHON and UV_NO_PROJECT on the step cover the action sitting inside the workspace ('uses: ./'), where the workspace is a parent of that directory. The python-version input is not used: it would export UV_PYTHON to every later step of the caller's job.
The default cache-dependency-glob now hashes this action's pyproject, uv.lock and runtime pin instead of whatever the caller's workspace holds. Those files decide what uvx installs into the cache, so the key tracks the cached content; for this repository's own workflows, which check out the same commit, the hashed files are unchanged.
The run step's uvx call is unchanged: run from a workspace holding all three plants, with uv 0.11.21 and 0.13.4, uvx neither executes the planted interpreters nor reads the planted uv.toml.
testing.yaml now plants a .venv and a .python-version whose interpreters only append to a marker file, plus a uv.toml with an unusable cache-dir and required-version, before running the action, then asserts its outputs and that no marker exists. Replayed locally with the real setup-uv v10.3.3: the old step stops on the planted required-version, and without the uv.toml it executes the planted interpreter; the new step installs uv, never runs a planted interpreter, and the action completes with failed=false.
Validation
Local, before push:
prekhooks pass; theaislopgate adds no findings;zizmor --persona auditorreports nothing.The new CI checks have not run anywhere yet: this pull request is their first run.