chore: GitHub Actions 効率化(Playwright キャッシュ追加・重複テスト削除)#293
Conversation
Co-authored-by: ujiro99 <677231+ujiro99@users.noreply.github.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #293 +/- ##
=======================================
Coverage 19.03% 19.03%
=======================================
Files 312 312
Lines 28829 28829
Branches 1321 1321
=======================================
Hits 5489 5489
Misses 23340 23340 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
このPull Requestは、GitHub Actions の test ワークフローを効率化し、CI実行時間を約40秒削減することを目的としています。具体的には、重複するテスト実行の削除と Playwright ブラウザのキャッシュ化により、無駄な処理を排除しています。
Changes:
testジョブから重複していたyarn test --runステップを削除し、yarn test:coverage --runに統合(約17秒削減)e2eジョブに Playwright ブラウザのキャッシュ機構を追加(約25秒削減)
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
PRレビューGitHub Actions の効率化を目的としたこのPRについてレビューします。変更内容は全体的に妥当で、CI の実行時間短縮に有効なアプローチを取っています。 良い点1. 重複テスト実行の削除(.github/workflows/test.yml 旧29〜31行) ルートの package.json を確認すると:
yarn test:coverage は vitest --coverage を実行するため、全テストを包含しています。重複削除は正しい最適化です。 2. Playwright キャッシュの実装(.github/workflows/test.yml 60〜75行) cache-hit == 'true' の場合は install-deps のみ、cache-hit != 'true' の場合は --with-deps で完全インストールという分岐は、Playwright の推奨パターンに沿っており適切です。 指摘事項1. キャッシュキーに OS 情報が含まれていない(.github/workflows/test.yml 63〜65行) 現在のキー: 現在は ubuntu-latest のみでの実行のため問題ありませんが、将来的に複数 OS でのテストを追加する場合、OS が異なるにもかかわらず同じキャッシュが使われてしまいます。以下のように runner.os を含めることを推奨します。 2. restore-keys による部分一致キャッシュの挙動(.github/workflows/test.yml 66〜67行) yarn.lock が Playwright と無関係な理由で変更された場合、古いキャッシュが restore-keys で復元されます。この場合 cache-hit は false になるため、Install Playwright browsers ステップ(完全インストール)が正しく実行されます。機能的には問題ありませんが、古いブラウザファイルが一時的にディスクに展開されるという軽微な無駄が生じます。 3. actions/cache@v4 のバージョン固定(.github/workflows/test.yml 61行) 公式 GitHub Actions であるため実用上の問題は少ないですが、セキュリティのベストプラクティスとして SHA 固定が推奨されます。既存の他ステップ(actions/checkout@v4 等)と整合性を合わせているため、プロジェクトのポリシーに準じた判断で問題ありません。 補足情報
総評PRの主な変更(重複テスト削除・Playwright キャッシュ化)はいずれも適切な実装です。指摘事項は将来の拡張性やセキュリティに関する改善提案ですが、現状の要件においては問題なくマージ可能な品質です。特にキャッシュキーへの runner.os の追加は、将来的な保守性向上のために対応を検討いただけると良いかと思います。 |
PR レビュー: GitHub Actions 効率化\n\nこのPRはすでにマージ済みですが、参考のためレビューを記載します。\n\n---\n\n### 概要\n\nCI実行時間を約40秒削減するための2つの最適化(重複テスト削除・Playwrightキャッシュ)が含まれており、方向性は正しいです。ただし、いくつか確認・改善すべき点があります。\n\n---\n\n### 1. 重複テスト削除(.github/workflows/test.yml 29-31行目)\n\nテスト対象スコープの差異に注意\n\n- yarn test : extension と hub の両ワークスペースを明示的に順次実行\n- yarn test:coverage : yarn workspaces run test:coverage で全ワークスペースを対象に実行\n\n判定: 現在の構成では問題なく動作していると考えられますが、前提条件を明示するとより堅牢です。\n\n---\n\n### 2. Playwright キャッシュ(.github/workflows/test.yml 60-78行目)\n\n#### 良い点\n\n- キャッシュヒット時に --with-deps を省略し install-deps のみ実行する二段構えのロジックは正しい実装です\n- -v1 サフィックスによるキャッシュ手動無効化の仕組みが組み込まれている点も良い\n\n#### 懸念点 1: restore-keys のサフィックス不一致(68行目付近)\n\n現在のキャッシュ設定:\n- key: playwright-chromium-(hash)-v1\n- restore-keys: playwright-chromium-\n\nrestore-keys に -v1 が含まれていないため、v1 以前の古いキャッシュが存在する場合にそれを拾ってしまうリスクがあります。\n\n推奨修正: restore-keys を playwright-chromium-v1- に変更する\n\n#### 懸念点 2: hashFiles のグロブパターンが広すぎる(65行目付近)\n\n現在: hashFiles('/package.json', 'yarn.lock')\n\n推奨修正**: hashFiles('yarn.lock') のみに絞り込む\n\n#### 懸念点 3: OS依存性(マイナー)\n\nキャッシュキーにランナーOSが含まれていません。将来的に複数OSでのテストを追加する場合は runner.os を含めることを推奨します。\n\n---\n\n### 3. セキュリティ\n\n既存ワークフローと一貫して actions/cache@v4 のような major バージョンタグを使用しています。これはリポジトリの既存ポリシーと統一されており問題ありません。\n\n---\n\n### まとめ\n\n全体的に意図は明確で、CI効率化としての効果も期待できます。上記の懸念点は軽微なものですが、今後のメンテナンス性向上のためフォローアップを検討いただければ幸いです。 |
testワークフローの2ジョブで合計約40秒/実行の無駄が発生していた。変更点
重複テスト実行の削除(約17秒削減)
testジョブでyarn test --runとyarn test:coverage --runが同一テストを2回実行していたRun testsステップを削除し、カバレッジ付き実行に統合Playwright ブラウザのキャッシュ化(約25秒削減)
e2eジョブで毎回 Chromium + Chrome Headless Shell(約113MB)をダウンロードしていたactions/cacheでキャッシュし、ヒット時はシステム依存関係のみ再インストールOriginal prompt
🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.