Skip to content

Fix: Run setup-uv in the action directory - #238

Open
ModeSevenIndustrialSolutions wants to merge 1 commit into
lfreleng-actions:mainfrom
modeseven-lfreleng-actions:fix/isolate-python-invocations
Open

ModeSevenIndustrialSolutions wants to merge 1 commit into
lfreleng-actions:mainfrom
modeseven-lfreleng-actions:fix/isolate-python-invocations

Conversation

@ModeSevenIndustrialSolutions

Copy link
Copy Markdown
Member

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:

  • 1529 tests pass.
  • The planted-file check was replayed locally with real uv (0.11.21 and 0.13.4): with the previous steps a planted interpreter ran (a marker file it writes on start appeared); with these steps none did.
  • prek hooks pass; the aislop gate adds no findings; zizmor --persona auditor reports nothing.

The new CI checks have not run anywhere yet: this pull request is their first run.

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
ModeSevenIndustrialSolutions requested review from a team and a balanced review from Copilot October 30, 2026 08:35
@github-actions github-actions Bot added the bug Something isn't working label Oct 30, 2026

This comment was marked as outdated.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

No active review issues were identified for the workspace-isolation changes.

No open issues 🎉

1 resolved since last review

Review effort: Balanced

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants