Communityコーディング&開発github.com

playwright-ci-caching

CI/CDパイプライン(GitHub Actions、Azure DevOps)でPlaywrightブラウザバイナリをキャッシュし、ビルドごとの1〜2分のダウンロードオーバーヘッドを回避します。

playwright-ci-caching とは?

このスキルは、CI/CDパイプライン(GitHub ActionsおよびAzure DevOps)でPlaywrightブラウザバイナリをキャッシュする方法を提供します。デフォルトでは、Playwrightブラウザ(約400MB)はCI実行のたびにダウンロードされ、1〜2分の時間がかかり、帯域幅を浪費し、ネットワークの問題で失敗する可能性があります。このスキルは、キャッシュキーにPlaywrightのバージョンを使用することで自動的にキャッシュを無効化し、ブラウザバージョンとSDKの整合性を保ちます。Linux、macOS、Windowsの各OSに対応したキャッシュパスを定義し、ヘルパースクリプト(playwright.ps1)を使用してPlaywright CLIの場所を抽象化します。これにより、開発者はビルド時間を短縮し、プルリクエストのフィードバックループを高速化できます。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Aaronontheweb/dotnet-skills/tree/main/skills/playwright-ci-caching

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

CI/CDでのPlaywrightブラウザのキャッシュ

このスキルを使用するタイミング

以下の場合にこのスキルを使用します:

  • Playwright E2Eテストを使用するプロジェクトでCI/CDを設定する場合
  • ブラウザのダウンロード(約400MB、1〜2分)によりビルド時間が遅い場合
  • Playwrightのバージョンが変わったときに自動的にキャッシュを無効化したい場合
  • GitHub ActionsまたはAzure DevOpsパイプラインを使用している場合

問題点

Playwrightブラウザ(約400MB)は、デフォルトではCI実行のたびにダウンロードする必要があります。これにより:

  • 毎回のビルドに1〜2分追加される
  • 帯域幅を浪費する
  • 一時的なネットワーク問題で失敗する可能性がある
  • PRのフィードバックループが遅くなる

コアパターン

  1. Playwrightバージョンの抽出: Directory.Packages.props(CPM)からキャッシュキーとして使用するPlaywrightバージョンを抽出する
  2. ブラウザバイナリのキャッシュ: プラットフォームに適したパスを使用してブラウザバイナリをキャッシュする
  3. 条件付きインストール: キャッシュミス時のみダウンロードする
  4. 自動キャッシュバスト: キーにバージョンを含めることで、パッケージのアップグレード時にキャッシュが無効化される

OSごとのキャッシュパス

OSパス
Linux~/.cache/ms-playwright
macOS~/Library/Caches/ms-playwright
Windows%USERPROFILE%\AppData\Local\ms-playwright

GitHub Actions

- name: Playwrightバージョンを取得
  shell: pwsh
  run: |
    $propsPath = "Directory.Packages.props"
    [xml]$props = Get-Content $propsPath
    $version = $props.Project.ItemGroup.PackageVersion |
      Where-Object { $_.Include -eq "Microsoft.Playwright" } |
      Select-Object -ExpandProperty Version
    echo "PlaywrightVersion=$version" >> $env:GITHUB_ENV

- name: Playwrightブラウザをキャッシュ
  id: playwright-cache
  uses: actions/cache@v4
  with:
    path: ~/.cache/ms-playwright
    key: ${{ runner.os }}-playwright-${{ env.PlaywrightVersion }}

- name: Playwrightブラウザをインストール
  if: steps.playwright-cache.outputs.cache-hit != 'true'
  shell: pwsh
  run: ./build/playwright.ps1 install --with-deps

マルチOS GitHub Actions

複数のオペレーティングシステムで実行するワークフローの場合:

- name: Playwrightブラウザをキャッシュ
  id: playwright-cache
  uses: actions/cache@v4
  with:
    path: |
      ~/.cache/ms-playwright
      ~/Library/Caches/ms-playwright
      ~/AppData/Local/ms-playwright
    key: ${{ runner.os }}-playwright-${{ env.PlaywrightVersion }}

Azure DevOps

- task: PowerShell@2
  displayName: 'Playwrightバージョンを取得'
  inputs:
    targetType: 'inline'
    script: |
      [xml]$props = Get-Content "Directory.Packages.props"
      $version = $props.Project.ItemGroup.PackageVersion |
        Where-Object { $_.Include -eq "Microsoft.Playwright" } |
        Select-Object -ExpandProperty Version
      Write-Host "##vso[task.setvariable variable=PlaywrightVersion]$version"

- task: Cache@2
  displayName: 'Playwrightブラウザをキャッシュ'
  inputs:
    key: 'playwright | "$(Agent.OS)" | $(PlaywrightVersion)'
    path: '$(HOME)/.cache/ms-playwright'
    cacheHitVar: 'PlaywrightCacheHit'

- task: PowerShell@2
  displayName: 'Playwrightブラウザをインストール'
  condition: ne(variables['PlaywrightCacheHit'], 'true')
  inputs:
    filePath: 'build/playwright.ps1'
    arguments: 'install --with-deps'

ヘルパースクリプト: playwright.ps1

build/playwright.ps1スクリプトを作成して、Playwright CLIを見つけて実行します。これにより、プロジェクト構造によって異なるPlaywright CLIの場所を抽象化します。

# build/playwright.ps1
# Microsoft.Playwright.dllを見つけて、バンドルされたPlaywright CLIを実行します

param(
    [Parameter(ValueFromRemainingArguments = $true)]
    [string[]]$Arguments
)

# Playwright DLLを見つける(dotnet build/restore後)
$playwrightDll = Get-ChildItem -Path . -Recurse -Filter "Microsoft.Playwright.dll" -ErrorAction SilentlyContinue |
    Select-Object -First 1

if (-not $playwrightDll) {
    Write-Error "Microsoft.Playwright.dllが見つかりません。最初に 'dotnet build' を実行してください。"
    exit 1
}

$playwrightDir = $playwrightDll.DirectoryName

# Playwright CLIを見つける(パスはOSとNodeのバージョンによって異なる)
$playwrightCmd = Get-ChildItem -Path "$playwrightDir/.playwright/node" -Recurse -Filter "playwright.cmd" -ErrorAction SilentlyContinue |
    Select-Object -First 1

if (-not $playwrightCmd) {
    # Unix実行可能ファイルを試す
    $playwrightCmd = Get-ChildItem -Path "$playwrightDir/.playwright/node" -Recurse -Filter "playwright" -ErrorAction SilentlyContinue |
        Where-Object { $_.Name -eq "playwright" } |
        Select-Object -First 1
}

if (-not $playwrightCmd) {
    Write-Error "Playwright CLIが $playwrightDir/.playwright/node に見つかりません"
    exit 1
}

Write-Host "使用するPlaywright CLI: $($playwrightCmd.FullName)"
& $playwrightCmd.FullName @Arguments

使用法:

# ブラウザをインストール
./build/playwright.ps1 install --with-deps

# 特定のブラウザをインストール
./build/playwright.ps1 install chromium

# インストール済みブラウザを表示
./build/playwright.ps1 install --dry-run

前提条件

このパターンは以下を前提としています:

  1. 中央パッケージ管理(CPM) と Directory.Packages.props:

    <Project>
      <ItemGroup>
        <PackageVersion Include="Microsoft.Playwright" Version="1.40.0" />
      </ItemGroup>
    </Project>
    
  2. playwright.ps1 を実行する前に プロジェクトがビルドされている こと(DLLが存在するため)

  3. CIエージェントで PowerShellが利用可能 であること(GitHub ActionsとAzure DevOpsではプリインストール済み)

バージョンベースのキャッシュキーが重要な理由

キャッシュキーにPlaywrightのバージョンを使用することで、以下が保証されます:

  • 自動的な無効化: Playwrightをアップグレードすると自動的に無効化される
  • 古いブラウザバイナリが残らない: SDKのバージョンと一致しないブラウザバイナリが存在しない
  • バージョンアップ後に手動でキャッシュをクリアする必要がない

キャッシュキーをハードコード(例:playwright-browsers-v1)すると、Playwrightをアップグレードするたびに手動でキーを変更する必要があり、そうしないと理解しにくいバージョン不一致エラーが発生します。

トラブルシューティング

キャッシュが使用されない

  1. バージョン抽出ステップが正しいバージョンを出力していることを確認する
  2. キャッシュパスがOSと一致していることを確認する
  3. Directory.Packages.props が存在し、Playwrightパッケージを含んでいることを確認する

キャッシュヒット後に「ブラウザが見つからない」

キャッシュされたブラウザがPlaywright SDKのバージョンと一致しません。これは以下の場合に発生します:

  • キャッシュキーにバージョンが含まれていない
  • バージョン抽出がサイレントに失敗した

修正:キャッシュキーにPlaywrightのバージョンが含まれていることを確認します。

playwright.ps1がDLLを見つけられない

スクリプトを実行する前に dotnet build または dotnet restore を実行します。Playwright DLLはNuGetリストア後にのみ存在します。

参考情報

このパターンは本番プロジェクトで実証済みです:

関連スキル

  • dotnet-skills:playwright-blazor - Blazorアプリケーション向けのPlaywrightテスト作成
  • dotnet-skills:project-structure - 中央パッケージ管理のセットアップ

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

akka-hosting-actor-patterns

Patterns for building entity actors with Akka.Hosting - GenericChildPerEntityParent, message extractors, cluster sharding abstraction, akka-reminders, and ITimeProvider. Supports both local testing and clustered production modes.

akka-net-aspire-configuration

Configure Akka.NET with .NET Aspire for local development and production deployments. Covers actor system setup, clustering, persistence, Akka.Management integration, and Aspire orchestration patterns.

akka-net-best-practices

Critical Akka.NET best practices including EventStream vs DistributedPubSub, supervision strategies, error handling, Props vs DependencyResolver, work distribution patterns, and cluster/local mode abstractions for testability.

akka-net-management

Akka.Management for cluster bootstrapping, service discovery (Kubernetes, Azure, Config), health checks, and dynamic cluster formation without static seed nodes.

akka-net-testing-patterns

Write unit and integration tests for Akka.NET actors using modern Akka.Hosting.TestKit patterns. Covers dependency injection, TestProbes, persistence testing, and actor interaction verification. Includes guidance on when to use traditional TestKit.

api-design

Design stable, compatible public APIs using extend-only design principles. Manage API compatibility, wire compatibility, and versioning for NuGet packages and distributed systems.

aspire-configuration

Configure Aspire AppHost to emit explicit app config via environment variables; keep app code free of Aspire clients and service discovery.

aspire-integration-testing

Write integration tests using .NET Aspire

aspire-service-defaults

Create a shared ServiceDefaults project for Aspire applications. Centralizes OpenTelemetry, health checks, resilience, and service discovery configuration across all services.

crap-analysis

Analyze code coverage and CRAP (Change Risk Anti-Patterns) scores to identify high-risk code. Use OpenCover format with ReportGenerator for Risk Hotspots showing cyclomatic complexity and untested code paths.

csharp-concurrency-patterns

Choosing the right concurrency abstraction in .NET - from async/await for I/O to Channels for producer/consumer to Akka.NET for stateful entity management. Avoid locks and manual synchronization unless absolutely necessary.

database-performance

Database access patterns for performance. Separate read/write models, avoid N+1 queries, use AsNoTracking, apply row limits, and never do application-side joins. Works with EF Core and Dapper.

dependency-injection-patterns

Organize DI registrations using IServiceCollection extension methods. Group related services into composable Add* methods for clean Program.cs and reusable configuration in tests.

dotnet-devcert-trust

Diagnose and fix .NET HTTPS dev certificate trust issues on Linux. Covers the full certificate lifecycle from generation to system CA bundle inclusion, with distro-specific guidance for Ubuntu, Fedora, Arch, and WSL2.

dotnet-local-tools

Managing local .NET tools with dotnet-tools.json for consistent tooling across development environments and CI/CD pipelines.

dotnet-project-structure

Modern .NET project structure including .slnx solution format, Directory.Build.props, central package management, SourceLink, version management with RELEASE_NOTES.md, and SDK pinning with global.json.

dotnet-slopwatch

Use Slopwatch to detect LLM reward hacking in .NET code changes. Run after every code modification to catch disabled tests, suppressed warnings, empty catch blocks, and other shortcuts that mask real problems.

efcore-patterns

Entity Framework Core best practices including NoTracking by default, query splitting for navigation collections, migration management, dedicated migration services, and common pitfalls to avoid.

ilspy-decompile

Understand implementation details of .NET code by decompiling assemblies. Use when you want to see how a .NET API works internally, inspect NuGet package source, view framework implementation, or understand compiled .NET binaries.

mailpit-integration

Test email sending locally using Mailpit with .NET Aspire. Captures all outgoing emails without sending them. View rendered HTML, inspect headers, and verify delivery in integration tests.

関連スキル