playwright-ci-caching

Configure CI/CD pipelines to cache Playwright browser binaries using version-based cache keys.

Updated Mar 8, 2026
One-click install
npx skills add https://github.com/AGIBuild/dotnet.CI.template --skill playwright-ci-caching-agibuild
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: playwright-ci-caching
Source: https://github.com/AGIBuild/dotnet.CI.template/tree/main/.cursor/skills/playwright-ci-caching
Command: npx skills add https://github.com/AGIBuild/dotnet.CI.template --skill playwright-ci-caching-agibuild

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Playwright browser binaries (~400MB) are downloaded on every CI run by default, adding 1-2 minutes to each build, wasting bandwidth, and causing failures on transient network issues. This Skill eliminates that overhead by caching browsers with automatic invalidation on version upgrades. ## Core Features & Use Cases - Version-Based Cache Keys: Extracts the Playwright version from Directory.Packages.props (Central Package Management) so cache invalidates automatically when the package is upgraded. - Multi-Platform Support: Provides ready-to-use configurations for GitHub Actions and Azure DevOps across Linux, macOS, and Windows cache paths. - Helper Script Pattern: Includes a build/playwright.ps1 script that discovers the Playwright CLI from the built DLL location, abstracting away path differences. - Use Case: A .NET team running Playwright E2E tests in GitHub Actions adds the cache step with the version-derived key, cutting browser download time from every PR build while ensuring browsers always match the SDK version. ## Quick Start Set up Playwright browser caching in my GitHub Actions workflow using the version from Directory.Packages.props as the cache key.

Frequently Asked Questions about playwright-ci-caching

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I cache Playwright browsers in GitHub Actions?▼

Use actions/cache@v4 with the path ~/.cache/ms-playwright and a key combining the runner OS and Playwright version. Then add a conditional install step that only runs when the cache misses, using a script like playwright.ps1 install --with-deps.

How to cache Playwright browsers in Azure DevOps pipelines?▼

Use the Cache@2 task with a key containing the agent OS and Playwright version, pointing to $(HOME)/.cache/ms-playwright. Set cacheHitVar and run the browser install step only when the cache hit variable is not true.

Why should the Playwright version be in the cache key?▼

Including the version ensures automatic cache invalidation when you upgrade Playwright, preventing stale browser binaries that mismatch the SDK. Hardcoded keys require manual bumps and cause cryptic version mismatch errors.

Where are Playwright browsers stored on different operating systems?▼

Linux uses ~/.cache/ms-playwright, macOS uses ~/Library/Caches/ms-playwright, and Windows uses %USERPROFILE%\AppData\Local\ms-playwright. Multi-OS workflows should list all paths in the cache configuration.

Why does Playwright browser caching fail with browser not found errors?▼

This happens when cached browsers do not match the Playwright SDK version, usually because the cache key lacks the version or version extraction failed silently. Verify the extraction step outputs the correct version from Directory.Packages.props.

What prerequisites are needed for Playwright CI caching with this approach?▼

You need Central Package Management with Directory.Packages.props containing the Microsoft.Playwright version, a completed dotnet build so the Playwright DLL exists, and PowerShell available on CI agents, which is pre-installed on GitHub Actions and Azure DevOps.