[ci] Cache Chrome binary across CI runs for Browser Run tests#13981
Conversation
petebacondarwin
added
the
ci:no-changeset-required
|
workers-devprod
requested review from
a team and
jamesopstad
and removed request for
a team
|
Codeowners approval required for this PR:
Show detailed file reviewers |
|
Now I have the key information from
But wait -- the PR uses But the So the actual path to Chrome files on Linux would be: The PR caches:
This looks correct. Let me also double-check what The Let me also verify the The matrix is This means:
This matches the comment that the browser fixture is skipped on Ubuntu (AppArmor) but miniflare spec runs everywhere. The change looks clean and correct. The version matches, the paths match the xdg library behavior, the condition logic is sound, and the degradation mode (cache miss just triggers a download) is safe. LGTM |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
Browser Run tests in `packages/miniflare/test/plugins/browser/index.spec.ts` and the `fixtures/browser-run` fixture call into `@puppeteer/browsers` to ensure Chrome is downloaded into the global Wrangler cache. Every CI run currently re-downloads ~150 MB of Chrome from scratch because the cache directory is per-runner-instance and not shared between runs. Add an `actions/cache@v4` step keyed on the OS + the Chrome version hardcoded in `packages/miniflare/src/index.ts` (`126.0.6478.182")`, restoring/saving `~/.cache/.wrangler/chrome` (Linux), `~/Library/Caches/.wrangler/chrome` (macOS), and `~/AppData/Local/xdg.cache/.wrangler/chrome` (Windows). Benefits: - Cuts ~150 MB and the associated download time off cold CI runs. - Reduces the surface area for the intermittent partial-extraction race that surfaces as `The browser folder (...) exists but the executable (...) is missing` (see #13971 for the diagnostic that exposed this, #13980 for the in-process recovery layer). When the cache is warm and the binary is already extracted, this race can't fire at all because `install()` short-circuits. The cache step runs for the `packages-and-tools` suite on all three OSes and for the `fixtures` suite on macOS + Windows (the Browser Run fixture is excluded on Ubuntu because of AppArmor). When the Chrome version in `packages/miniflare/src/index.ts` changes, the cache key here needs to be bumped manually. A miss only triggers a fresh download — no functional impact.
Move the `126.0.6478.182` Chrome version literal out of `packages/miniflare/src/index.ts` into a dedicated `packages/miniflare/src/plugins/browser-rendering/browser-version.ts` module, and switch the `actions/cache` key to `hashFiles()` over that file. Bumping the constant in one place now automatically invalidates the CI cache without a separate workflow edit.
petebacondarwin
force-pushed
the
pbd/ci/cache-chrome-binary
branch
from
be05bea to
4f6f5ce
Compare
workers-devprod
left a comment
workers-devprod
left a comment
There was a problem hiding this comment.
Codeowners reviews satisfied
3 participants
No tracked issue; follow-up to #13971 and #13980.
What
Browser Run tests in
packages/miniflare/test/plugins/browser/index.spec.tsand thefixtures/browser-runfixture call into@puppeteer/browsersto ensure Chrome is downloaded into the global Wrangler cache. Every CI run currently re-downloads ~150 MB of Chrome from scratch because the cache directory is per-runner-instance and not shared between runs.Cache it across runs.
How
Add an
actions/cache@v4step keyed on the OS plus the Chrome version hardcoded inpackages/miniflare/src/index.ts(126.0.6478.182), restoring/saving:~/.cache/.wrangler/chrome(Linux)~/Library/Caches/.wrangler/chrome(macOS)~/AppData/Local/xdg.cache/.wrangler/chrome(Windows)actions/cache@v4silently skips paths that don't exist for the current OS, so listing all three in a single step keeps the workflow flat.The cache step runs for the
packages-and-toolssuite on all three OSes (miniflare browser spec runs everywhere) and for thefixturessuite on macOS + Windows (the Browser Run fixture is excluded on Ubuntu because of AppArmor — pptr.dev/troubleshooting).Why
Two benefits:
The browser folder (...) exists but the executable (...) is missing(diagnostic in #13971, in-process recovery in #13980). When the cache is warm and the binary is already fully extracted,install()short-circuits and the race can't fire at all.These two PRs are complementary, not alternatives:
Maintenance note
The cache key has the Chrome version literally in it:
chrome-${{ runner.os }}-126.0.6478.182. When that version is bumped inpackages/miniflare/src/index.ts, this key needs a manual bump too. The cost of forgetting is just one extra download (the new version misses the cache, downloads, then populates the new key) — no functional impact, no broken tests. AvoidinghashFiles('packages/miniflare/src/index.ts')because that file is ~3,200 lines and changes for unrelated reasons constantly, which would defeat the cache.Test plan
pnpm check:format✅The first run on this PR will be a cache miss (no key exists yet). The cache populates from this run. Subsequent runs on this branch — and any PRs branched off main after this lands — will be cache hits.