From 532b7b854a1f0fad2e10010fa2b0da031076ac74 Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Tue, 11 Aug 2026 16:44:12 +0000 Subject: [PATCH] ci(pip-release): drop the removed `buildjet` cache provider MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit BuildJet is shutting down its GitHub Actions service, so Swatinem/rust-cache removed the provider in v2.9.2 (2026-08-06). The workflow floats on `@v2`, so it picked the removal up automatically and every `linux` job now logs "The `cache-provider` `buildjet` is not valid". The action swallows the error, so the jobs still pass — they just run with no caching at all and a red annotation. Rather than re-point at `cache-provider: github`, drop the step. It was not earning its keep: - rust-cache doesn't include the matrix in its key, and the workspace has a single Cargo.lock, so all 8 expansions of the `linux` job shared one key (`v0-rust-linux-Linux-x64-2e010167-37d8d8b3`) and one ~2.25 GB entry — polluted across 4 target triples and 2 crates. - Job durations are the same with the cache warm and with it gone entirely (12-19 min either way). - The repo cache already sits at ~9.7/10 GB. Moving this 2.25 GB blob onto the GitHub budget would LRU-evict the ci.yml workspace and e2e caches that the PR loop actually depends on — the exact thrash 93b9e5cf6 fixed. Also removes delete-buildjet-cache.yml (a manual `buildjet/cache-delete` dispatch with nothing left to delete) and refreshes the nightly.yml comment that pointed at BuildJet as the escape hatch. Co-Authored-By: Claude Opus 5 (1M context) --- .github/workflows/delete-buildjet-cache.yml | 18 -------------- .github/workflows/nightly.yml | 7 +++--- .github/workflows/pip-release.yml | 27 ++++++++++++++++----- 3 files changed, 25 insertions(+), 27 deletions(-) delete mode 100644 .github/workflows/delete-buildjet-cache.yml diff --git a/.github/workflows/delete-buildjet-cache.yml b/.github/workflows/delete-buildjet-cache.yml deleted file mode 100644 index 804e5569af..0000000000 --- a/.github/workflows/delete-buildjet-cache.yml +++ /dev/null @@ -1,18 +0,0 @@ -name: Manually Delete BuildJet Cache -on: - workflow_dispatch: - inputs: - cache_key: - description: 'BuildJet Cache Key to Delete' - required: true - type: string - -jobs: - manually-delete-buildjet-cache: - runs-on: ubuntu-latest - steps: - - name: Checkout - uses: actions/checkout@v6 - - uses: buildjet/cache-delete@v1 - with: - cache_key: ${{ inputs.cache_key }} diff --git a/.github/workflows/nightly.yml b/.github/workflows/nightly.yml index c7c1da46d2..2586e4aa89 100644 --- a/.github/workflows/nightly.yml +++ b/.github/workflows/nightly.yml @@ -20,9 +20,10 @@ name: Nightly Regression # high-frequency PR loop (ci.yml) depends on. Nightly is a non-blocking # once-daily job, so it restores where it can but never saves — trading # a slower nightly for a warm PR loop. Do NOT drop these `save-if: -# false` gates. If nightly build time becomes a problem, move these to a -# separate cache backend (e.g. `cache-provider: buildjet`, as -# pip-release.yml does) rather than saving into the GitHub budget. +# false` gates. If nightly build time becomes a problem, find a cache +# backend outside the GitHub budget rather than saving into it. Note +# that BuildJet — the escape hatch pip-release.yml used to use — is +# shutting down, and rust-cache v2.9.2 removed that provider. # # Triggers: # - schedule: daily at 06:00 UTC diff --git a/.github/workflows/pip-release.yml b/.github/workflows/pip-release.yml index a6d0580c72..ad763512e2 100644 --- a/.github/workflows/pip-release.yml +++ b/.github/workflows/pip-release.yml @@ -72,11 +72,25 @@ jobs: python-version: ${{ env.PYTHON_VERSION }} - run: rustup default ${{ env.RUST_VERSION }} - run: rustup update ${{ env.RUST_VERSION }} - - uses: Swatinem/rust-cache@v2 - with: - cache-provider: buildjet - # only save caches for `main` branch - save-if: ${{ github.ref == 'refs/heads/main' }} + # No rust-cache step here, deliberately. This job used to run + # `Swatinem/rust-cache@v2` with `cache-provider: buildjet`, which + # kept these cross-builds off the 10 GB GitHub cache budget. + # BuildJet is shutting down its GitHub Actions service, so + # rust-cache v2.9.2 dropped the provider and the step started + # erroring out ("The `cache-provider` `buildjet` is not valid"). + # + # It is not worth re-pointing at `cache-provider: github`: + # - rust-cache does not put the matrix in the cache key, and the + # workspace has a single Cargo.lock, so all 8 expansions of + # this job shared ONE ~2.25 GB entry. That blob is polluted + # across 4 target triples and 2 crates — whichever expansion + # wins the save race populates it for everyone else. + # - Measured accordingly: job durations are identical with the + # cache warm and with it removed entirely (12-19 min either + # way). It was buying ~0. + # - 2.25 GB is ~23% of the repo-wide budget, which already runs + # at ~9.7/10 GB. Saving it would LRU-evict the ci.yml + # workspace/e2e caches that the PR loop actually depends on. - name: Build wheels uses: PyO3/maturin-action@v1 with: @@ -87,7 +101,8 @@ jobs: # object, flooding the 10 GB repo-wide cache with thousands of # micro-entries that evict the workspace caches PR CI relies on. # These release cross-builds don't help the PR loop, so keep it - # off. rust-cache above already caches deps (via BuildJet). + # off. See the note above for why there is no rust-cache + # step to fall back on either. sccache: "false" working-directory: ${{ matrix.repository.path }} before-script-linux: |