Skip to content

Disable known GitHub cache clients in release workflows - #761

Closed
zaniebot wants to merge 1 commit into
mainfrom
zb/disable-release-caches
Closed

zaniebot wants to merge 1 commit into
mainfrom
zb/disable-release-caches

Conversation

@zaniebot

@zaniebot zaniebot commented Aug 17, 2026 •

Copy link
Copy Markdown
Collaborator

Release workflows can restore shared GitHub caches through the docs Rust cache and setup-uv's automatic caching. Remove the docs Rust cache and explicitly disable caching in every release invocation of setup-uv, setup-python, and maturin-action. The shared binary-build workflow also keeps setup-uv caching off when invoked by CI.

release-prepare.yml, same-run artifacts, and Depot's own cache are unchanged. This configures the known cache clients; it does not revoke cache-service access.

@zaniebot
zaniebot force-pushed the zb/disable-release-caches branch from 728182b to 0c2c610 Compare August 17, 2026 17:01
@zaniebot zaniebot changed the title Disable GitHub caches in release workflows Disable known GitHub cache clients in release workflows Aug 17, 2026
@zaniebot
zaniebot force-pushed the zb/disable-release-caches branch from 9524b25 to 0c2c610 Compare August 17, 2026 17:41
@zanieb
zanieb marked this pull request as ready for review August 17, 2026 17:44
@zanieb zanieb added internal A refactor or improvement that is not user-facing security labels Aug 17, 2026
@astral-automations-bot

Copy link
Copy Markdown

Promoted to #21168.

zanieb added a commit to astral-sh/uv that referenced this pull request Aug 18, 2026
Trusted release actions must not accidentally restore a poisoned shared
GitHub cache. Set `ACTIONS_CACHE_MODE: none` in `release.yml` and each
reusable workflow it calls so clients that support the variable skip
cache reads and writes. Each reusable workflow needs its own setting
because workflow-level environment variables do not propagate to called
workflows. The shared binary-build workflow uses the same cache-disabled
setting when invoked by CI.

This is a cooperative client-side default, not token revocation or
server-enforced denial. Older or independent clients, or code calling
the cache API directly, can still access the service. The
`@actions/cache` library's [6.2.0
change](actions/toolkit#2447) skips operations
before contacting the cache backend; that is separate from its handling
of server-denied requests. The release graph uses `[email protected]` and
`[email protected]`, whose pinned
[setup-uv](https://github.com/astral-sh/setup-uv/blob/20cfd1bf945f4377ade1205e4dbc17946fc9a30d/package-lock.json)
and
[setup-python](https://github.com/actions/setup-python/blob/5fda3b95a4ea91299a34e894583c3862153e4b97/package-lock.json)
dependencies include `@actions/[email protected]`. Both honor this variable.
The separate `actions/[email protected]` action still bundles
`@actions/[email protected]` and does not honor it; the release graph does not
invoke that action directly.

Stacked on astral-sh#761, which keeps the action-specific
opt-outs, removes the docs Rust cache, and explicitly disables maturin's
sccache integration. `release-prepare.yml`, same-run artifacts, and
Depot's own cache are unchanged.

Co-authored-by: Zanie Blue <[email protected]>
@astral-automations-bot astral-automations-bot Bot added internal:automations Related to internal automations internal:releases Related to building and distributing release artifacts of uv labels Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

internal:automations Related to internal automations internal:releases Related to building and distributing release artifacts of uv internal A refactor or improvement that is not user-facing security

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants