サイボウズ 生産性向上チーム 💪Publicationへの投稿📸GitHub Actions のキャッシュを使った VRT のすゝめFuta Hirakoba2023/12/12に公開2023/12/154件GitHub ActionsPlaywrightVRTtechGitHubで編集を提案サイボウズ 生産性向上チーム 💪Publicationサイボウズ株式会社 開発本部 生産性向上チームです。 サイボウズエンジニアの生産性を上げるために日々活動しています 💪Discussionyorifuji2023/12/12に更新いつも有用な記事をありがとうございます、記事を読んだ感想をコメントさせていただきます🙏 実際に試してはいないのですが成果物のハッシュ値の計算は組み込みのhashFilesが使えるのではと思いました https://docs.github.com/ja/actions/learn-github-actions/expressions#hashfiles テストオラクルのキャッシュ戦略で「そもそも保存しない」という選択肢について、テストの実行時間が長くなるデメリットを挙げられていましたが、もしテストオラクルのイメージ生成がトピックブランチのそれと並列に実行できればテスト全体の実行時間には影響が無いように思いました（public repositoryであればrunnerの課金も気にならないですし） Artifactの容量についての言及がありませんでしたが、たしかStorageを使用するので画面（スクショ）が増えるとStorageを圧迫してきそうだなと思いました https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#:~:text=Storing artifacts uses storage space on GitHub. Futa Hirakoba2023/12/13いつもお読みいただきありがとうございます！コメントいただきうれしく思います。 早いうちにコメントいただいた内容を本文に盛り込みたいと思います。 お恥ずかしながら組み込みでハッシュ計算する関数があることを知りませんでした…globパターンで指定できそうなので代用できるかもしれません（近いうちに試したいです） 個人的には、がんばれば保存せずとも保存する場合と同じ速度を実現できると思うが、仕組みが複雑になって実装・メンテコストが高くなるかなと考えています 並列実行できれば総実行時間は減らせるとは思います。しかし、テストオラクルのイメージ生成とテストによるイメージ比較には依存関係があるので、並列に実行する順序やタイミングを考えると、結構工夫が必要だなと考えています。 GitHub Actions の文脈的には、jobs.<job_id>.strategy.matrix で複数ランナーを立ち上げて並列実行する選択肢と、larger runner や self-hosted runner を使って 1 つのハイスペックなランナー内で並行実行する選択肢があると思います（標準ランナーだとスペック的に並行度を上げづらいという認識）。ただ、前者で行う場合はジョブ間でデータを受け渡すために結局どこかに保存する必要がありそうですね（依存関係の考慮は必要）。後者の場合の方が前者よりも依存関係を考慮した並列実行の実装は容易そうですね。しかし larger runners の場合はお金の面が、self-hosted runner の場合はメンテナンスコストの面が無視できなくなってしまいますね。 また、VRT 以外のジョブも同時に実行する場合、VRT に関しては直列にしても、他のジョブと並列に動くため総実行時間を減らすのは容易にできそうですね（他のジョブの実行時間による）。 そうですね！そこは観点から抜けていました。cache がリポジトリごとに 10 GB まで使えるのに対して、artifacts は owner が持つ共有ストレージ（Free の場合 500MB）を消費しちゃいますね。方法を選定する際の重要な判断材料になりそうです。 返信を追加tacrew2023/12/13いつものように楽しく拝読しようとしたらネタ被り＆紹介まで頂いていることに気付いてびっくりしました！光栄で嬉しいです！ ネタ被りといいつつもアプローチの比較含めとても分かりやすく、勉強になりました。 今後の記事も楽しみにしています～（ちなみにProductivity Weeklyは最初期からフォローしていて、毎回勉強させていただいています。 Futa Hirakoba2023/12/13コメントありがとうございます。こちらこそ普段から拝読いただいてるとのことで光栄です！ （逆にこの記事についての紹介を追記していただいたようでありがとうございます🙇） 実は、最初は reg-suit を使ってスナップショットをキャッシュに保存しようとしていたのですが、機能が多すぎて調べるの大変だなーというところから、Playwright のみ使う方針にしました。 reg-suit を使った方法はよくわからず終わってしまっていたので、tacrew さんの記事はめちゃ参考になります！ 今後もタメになる記事期待しています😎 返信を追加
yorifuji2023/12/12に更新いつも有用な記事をありがとうございます、記事を読んだ感想をコメントさせていただきます🙏 実際に試してはいないのですが成果物のハッシュ値の計算は組み込みのhashFilesが使えるのではと思いました https://docs.github.com/ja/actions/learn-github-actions/expressions#hashfiles テストオラクルのキャッシュ戦略で「そもそも保存しない」という選択肢について、テストの実行時間が長くなるデメリットを挙げられていましたが、もしテストオラクルのイメージ生成がトピックブランチのそれと並列に実行できればテスト全体の実行時間には影響が無いように思いました（public repositoryであればrunnerの課金も気にならないですし） Artifactの容量についての言及がありませんでしたが、たしかStorageを使用するので画面（スクショ）が増えるとStorageを圧迫してきそうだなと思いました https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#:~:text=Storing artifacts uses storage space on GitHub. Futa Hirakoba2023/12/13いつもお読みいただきありがとうございます！コメントいただきうれしく思います。 早いうちにコメントいただいた内容を本文に盛り込みたいと思います。 お恥ずかしながら組み込みでハッシュ計算する関数があることを知りませんでした…globパターンで指定できそうなので代用できるかもしれません（近いうちに試したいです） 個人的には、がんばれば保存せずとも保存する場合と同じ速度を実現できると思うが、仕組みが複雑になって実装・メンテコストが高くなるかなと考えています 並列実行できれば総実行時間は減らせるとは思います。しかし、テストオラクルのイメージ生成とテストによるイメージ比較には依存関係があるので、並列に実行する順序やタイミングを考えると、結構工夫が必要だなと考えています。 GitHub Actions の文脈的には、jobs.<job_id>.strategy.matrix で複数ランナーを立ち上げて並列実行する選択肢と、larger runner や self-hosted runner を使って 1 つのハイスペックなランナー内で並行実行する選択肢があると思います（標準ランナーだとスペック的に並行度を上げづらいという認識）。ただ、前者で行う場合はジョブ間でデータを受け渡すために結局どこかに保存する必要がありそうですね（依存関係の考慮は必要）。後者の場合の方が前者よりも依存関係を考慮した並列実行の実装は容易そうですね。しかし larger runners の場合はお金の面が、self-hosted runner の場合はメンテナンスコストの面が無視できなくなってしまいますね。 また、VRT 以外のジョブも同時に実行する場合、VRT に関しては直列にしても、他のジョブと並列に動くため総実行時間を減らすのは容易にできそうですね（他のジョブの実行時間による）。 そうですね！そこは観点から抜けていました。cache がリポジトリごとに 10 GB まで使えるのに対して、artifacts は owner が持つ共有ストレージ（Free の場合 500MB）を消費しちゃいますね。方法を選定する際の重要な判断材料になりそうです。 返信を追加
Futa Hirakoba2023/12/13いつもお読みいただきありがとうございます！コメントいただきうれしく思います。 早いうちにコメントいただいた内容を本文に盛り込みたいと思います。 お恥ずかしながら組み込みでハッシュ計算する関数があることを知りませんでした…globパターンで指定できそうなので代用できるかもしれません（近いうちに試したいです） 個人的には、がんばれば保存せずとも保存する場合と同じ速度を実現できると思うが、仕組みが複雑になって実装・メンテコストが高くなるかなと考えています 並列実行できれば総実行時間は減らせるとは思います。しかし、テストオラクルのイメージ生成とテストによるイメージ比較には依存関係があるので、並列に実行する順序やタイミングを考えると、結構工夫が必要だなと考えています。 GitHub Actions の文脈的には、jobs.<job_id>.strategy.matrix で複数ランナーを立ち上げて並列実行する選択肢と、larger runner や self-hosted runner を使って 1 つのハイスペックなランナー内で並行実行する選択肢があると思います（標準ランナーだとスペック的に並行度を上げづらいという認識）。ただ、前者で行う場合はジョブ間でデータを受け渡すために結局どこかに保存する必要がありそうですね（依存関係の考慮は必要）。後者の場合の方が前者よりも依存関係を考慮した並列実行の実装は容易そうですね。しかし larger runners の場合はお金の面が、self-hosted runner の場合はメンテナンスコストの面が無視できなくなってしまいますね。 また、VRT 以外のジョブも同時に実行する場合、VRT に関しては直列にしても、他のジョブと並列に動くため総実行時間を減らすのは容易にできそうですね（他のジョブの実行時間による）。 そうですね！そこは観点から抜けていました。cache がリポジトリごとに 10 GB まで使えるのに対して、artifacts は owner が持つ共有ストレージ（Free の場合 500MB）を消費しちゃいますね。方法を選定する際の重要な判断材料になりそうです。
tacrew2023/12/13いつものように楽しく拝読しようとしたらネタ被り＆紹介まで頂いていることに気付いてびっくりしました！光栄で嬉しいです！ ネタ被りといいつつもアプローチの比較含めとても分かりやすく、勉強になりました。 今後の記事も楽しみにしています～（ちなみにProductivity Weeklyは最初期からフォローしていて、毎回勉強させていただいています。 Futa Hirakoba2023/12/13コメントありがとうございます。こちらこそ普段から拝読いただいてるとのことで光栄です！ （逆にこの記事についての紹介を追記していただいたようでありがとうございます🙇） 実は、最初は reg-suit を使ってスナップショットをキャッシュに保存しようとしていたのですが、機能が多すぎて調べるの大変だなーというところから、Playwright のみ使う方針にしました。 reg-suit を使った方法はよくわからず終わってしまっていたので、tacrew さんの記事はめちゃ参考になります！ 今後もタメになる記事期待しています😎 返信を追加
Futa Hirakoba2023/12/13コメントありがとうございます。こちらこそ普段から拝読いただいてるとのことで光栄です！ （逆にこの記事についての紹介を追記していただいたようでありがとうございます🙇） 実は、最初は reg-suit を使ってスナップショットをキャッシュに保存しようとしていたのですが、機能が多すぎて調べるの大変だなーというところから、Playwright のみ使う方針にしました。 reg-suit を使った方法はよくわからず終わってしまっていたので、tacrew さんの記事はめちゃ参考になります！ 今後もタメになる記事期待しています😎
Discussion
いつも有用な記事をありがとうございます、記事を読んだ感想をコメントさせていただきます🙏
実際に試してはいないのですが成果物のハッシュ値の計算は組み込みの
hashFilesが使えるのではと思いましたhttps://docs.github.com/ja/actions/learn-github-actions/expressions#hashfiles
テストオラクルのキャッシュ戦略で「そもそも保存しない」という選択肢について、テストの実行時間が長くなるデメリットを挙げられていましたが、もしテストオラクルのイメージ生成がトピックブランチのそれと並列に実行できればテスト全体の実行時間には影響が無いように思いました（public repositoryであればrunnerの課金も気にならないですし）
Artifactの容量についての言及がありませんでしたが、たしかStorageを使用するので画面（スクショ）が増えるとStorageを圧迫してきそうだなと思いました
https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#:~:text=Storing artifacts uses storage space on GitHub.
いつもお読みいただきありがとうございます！コメントいただきうれしく思います。
早いうちにコメントいただいた内容を本文に盛り込みたいと思います。
jobs.<job_id>.strategy.matrixで複数ランナーを立ち上げて並列実行する選択肢と、larger runner や self-hosted runner を使って 1 つのハイスペックなランナー内で並行実行する選択肢があると思います（標準ランナーだとスペック的に並行度を上げづらいという認識）。ただ、前者で行う場合はジョブ間でデータを受け渡すために結局どこかに保存する必要がありそうですね（依存関係の考慮は必要）。後者の場合の方が前者よりも依存関係を考慮した並列実行の実装は容易そうですね。しかし larger runners の場合はお金の面が、self-hosted runner の場合はメンテナンスコストの面が無視できなくなってしまいますね。いつものように楽しく拝読しようとしたらネタ被り＆紹介まで頂いていることに気付いてびっくりしました！光栄で嬉しいです！
ネタ被りといいつつもアプローチの比較含めとても分かりやすく、勉強になりました。
今後の記事も楽しみにしています～（ちなみにProductivity Weeklyは最初期からフォローしていて、毎回勉強させていただいています。
コメントありがとうございます。こちらこそ普段から拝読いただいてるとのことで光栄です！
（逆にこの記事についての紹介を追記していただいたようでありがとうございます🙇）
実は、最初は reg-suit を使ってスナップショットをキャッシュに保存しようとしていたのですが、機能が多すぎて調べるの大変だなーというところから、Playwright のみ使う方針にしました。
reg-suit を使った方法はよくわからず終わってしまっていたので、tacrew さんの記事はめちゃ参考になります！
今後もタメになる記事期待しています😎