Problem
gh-aw's generated astral-sh/setup-uv step, defined in pkg/workflow/runtime_definitions.go, does not explicitly disable setup-uv's default Actions caching behavior.
In the normal AWF sandbox configuration, the agent cannot use or write setup-uv's runner-side cache. Restoring and saving that cache therefore adds time without benefiting the agent's uv commands. Making the cache path writable to the agent would not be a safe workaround: setup-uv's post-job save could then put agent-written content into a repository-wide Actions cache, exposing other jobs to cache poisoning.
Runtime deduplication also carries custom setup-step inputs into generated steps, and those inputs take precedence over runtime defaults. Simply changing the default would not be sufficient if a carried-over cache setting could re-enable caching.
Proposed fix
Generate the setup-uv step with its enable-cache input explicitly set to false. Keep runtime deduplication from carrying a conflicting enable-cache setting into the generated replacement, while retaining unrelated setup inputs and existing custom-version behavior.
Validate custom setup-uv steps that remain in the agent job after deduplication, including workflows where no generated uv step is needed. If such a step leaves caching enabled or does not explicitly disable it, emit an actionable warning identifying the step and explaining how to disable caching. Treat the same condition as a compilation error in strict mode. Explicitly cache-disabled custom steps should remain valid and retain their other customizations.
Keep this change focused on Actions caching in agentic jobs. Do not make runner-side cache paths writable to the agent or couple the fix to environment-forwarding or Cloud Hypervisor HOME-state changes.
Regression coverage
Add regression tests confirming that generated setup-uv steps disable caching and that deduplication cannot re-enable it through carried-over inputs. Cover preserved custom steps, omitted and enabled cache settings, explicitly disabled caching, and workflows with a custom setup-uv step but no detected uv command. Verify that unsafe custom steps produce warnings in non-strict mode and compilation errors in strict mode, while safe custom steps preserve their version and other settings.
Provenance
This change was first written in #66958, "Disable uv Actions caching and isolate sandbox runtime paths." That PR is being split per maintainer request; this issue tracks the generated setup-uv cache default, deduplication protection, and custom-step validation separately.
Problem
gh-aw's generated
astral-sh/setup-uvstep, defined inpkg/workflow/runtime_definitions.go, does not explicitly disable setup-uv's default Actions caching behavior.In the normal AWF sandbox configuration, the agent cannot use or write setup-uv's runner-side cache. Restoring and saving that cache therefore adds time without benefiting the agent's uv commands. Making the cache path writable to the agent would not be a safe workaround: setup-uv's post-job save could then put agent-written content into a repository-wide Actions cache, exposing other jobs to cache poisoning.
Runtime deduplication also carries custom setup-step inputs into generated steps, and those inputs take precedence over runtime defaults. Simply changing the default would not be sufficient if a carried-over cache setting could re-enable caching.
Proposed fix
Generate the setup-uv step with its enable-cache input explicitly set to false. Keep runtime deduplication from carrying a conflicting enable-cache setting into the generated replacement, while retaining unrelated setup inputs and existing custom-version behavior.
Validate custom setup-uv steps that remain in the agent job after deduplication, including workflows where no generated uv step is needed. If such a step leaves caching enabled or does not explicitly disable it, emit an actionable warning identifying the step and explaining how to disable caching. Treat the same condition as a compilation error in strict mode. Explicitly cache-disabled custom steps should remain valid and retain their other customizations.
Keep this change focused on Actions caching in agentic jobs. Do not make runner-side cache paths writable to the agent or couple the fix to environment-forwarding or Cloud Hypervisor HOME-state changes.
Regression coverage
Add regression tests confirming that generated setup-uv steps disable caching and that deduplication cannot re-enable it through carried-over inputs. Cover preserved custom steps, omitted and enabled cache settings, explicitly disabled caching, and workflows with a custom setup-uv step but no detected uv command. Verify that unsafe custom steps produce warnings in non-strict mode and compilation errors in strict mode, while safe custom steps preserve their version and other settings.
Provenance
This change was first written in #66958, "Disable uv Actions caching and isolate sandbox runtime paths." That PR is being split per maintainer request; this issue tracks the generated setup-uv cache default, deduplication protection, and custom-step validation separately.