Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
golang-parallel-test-by-github-actions-and-merg...
Search
SatoKeiju
December 11, 2024
0
140
golang-parallel-test-by-github-actions-and-merge-coverage-report
SatoKeiju
December 11, 2024
Tweet
Share
More Decks by SatoKeiju
See All by SatoKeiju
CVPR2020読み会 Proxy Anchor Loss for Deep Metric Learning
satokeiju
7
4.1k
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
427
64k
The Pragmatic Product Professional
lauravandoore
32
6.3k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Code Review Best Practice
trishagee
65
17k
Become a Pro
speakerdeck
PRO
26
5k
Gamification - CAS2011
davidbonilla
80
5.1k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Fireside Chat
paigeccino
34
3.1k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Adopting Sorbet at Scale
ufuk
73
9.1k
Rails Girls Zürich Keynote
gr2m
94
13k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
Transcript
GitHub ActionsでGoの テストを並列実行し カバレッジレポートを作る 2024/12/11 @DMM.go プラットフォーム開発本部 第一開発部 ポイントクラブグループ webチーム
デザインエンジニア @SANdglAss
• 2021年に新卒で入社したバックエンドエンジニア • 3年目からは「デザインエンジニア」としてUI/UXデザインや UXライティングも担当中 くわしくは「デザインエンジニア」で検索 🔍 自己紹介
GoプロジェクトのCIをCircleCI → GitHub Actionsに
• とある事情で移行することに • 無事すべて移行できた • テストジョブの所要時間が1分半 → 5分になった GoプロジェクトのCIをCircleCI →
GitHub Actionsに
GoプロジェクトのCIをCircleCI → GitHub Actionsに なんでやねん • とある事情で移行することに • 無事すべて移行できた •
テストジョブの所要時間が 1分半 → 5分になった
遅くなった主な理由: マシンスペック(コア数) Docker 実行環境の使用 - CircleCI GitHub Actions CircleCI About
GitHub-hosted runners - GitHub Enterprise Cloud Docs ↑のドキュメントはエンプラですが Cloudも同じです
CIに詳しいマリーアントワネット
CIに詳しいマリーアントワネット 「スペックが足りないなら 強いのを使えばいいじゃない」
CIに詳しいマリーアントワネット 「スペックが足りないなら 強いのを使えばいいじゃない」 → 現状のDMM Organizationでは使えない ...
CIに詳しいマリーアントワネット
CIに詳しいマリーアントワネット 「コアが少ないならノード並列で 分割実行すればいいじゃない」
CIに詳しいマリーアントワネット 「コアが少ないならノード並列で 分割実行すればいいじゃない」 → それでいきましょう
1つのジョブを並列実行: CircleCI編
1つのジョブを並列実行: CircleCI編 とてもかんたん
1つのジョブを並列実行: GitHub Actions編
1つのジョブを並列実行: GitHub Actions編 ない
1つのジョブを並列実行: GitHub Actions編 なんでやねん ない
1つのジョブを並列実行: GitHub Actions編 ジョブを並列実行する仕組み自体は、ないわけではない
1つのジョブを並列実行: GitHub Actions編 ジョブを並列実行する仕組み自体は、ないわけではない その名も matrix ワークフローでのジョブのバリエーションの実行 - GitHub Docs
1つのジョブを並列実行: GitHub Actions編 ジョブを並列実行する仕組み自体は、ないわけではない その名も matrix 変数のパターンを 列挙しておくと ワークフローでのジョブのバリエーションの実行 -
GitHub Docs
1つのジョブを並列実行: GitHub Actions編 ジョブを並列実行する仕組み自体は、ないわけではない その名も matrix 各値が設定された ジョブが並列で 立ち上がる ワークフローでのジョブのバリエーションの実行
- GitHub Docs 変数のパターンを 列挙しておくと
1つのジョブを並列実行: GitHub Actions編 ジョブを並列実行する仕組み自体は、ないわけではない その名も matrix 各値が設定された ジョブが並列で 立ち上がる 変数のパターンを
列挙しておくと どうにかして 使えないものか ... ワークフローでのジョブのバリエーションの実行 - GitHub Docs
Rubyで用いし先駆者がいた
Rubyで用いし先駆者がいた GitHub Actions でテストを並列化して CI 時間を短縮する - Gunosy Tech Blog
Rubyで用いし先駆者がいた GitHub Actions でテストを並列化して CI 時間を短縮する - Gunosy Tech Blog
並列化したい数だけ IDを宣言しておいて
Rubyで用いし先駆者がいた GitHub Actions でテストを並列化して CI 時間を短縮する - Gunosy Tech Blog
並列化したい数だけ IDを宣言しておいて 全テストをいい感じに 各IDに割り振って
Rubyで用いし先駆者がいた GitHub Actions でテストを並列化して CI 時間を短縮する - Gunosy Tech Blog
並列化したい数だけ IDを宣言しておいて 各ノードは自分の IDの テストだけ実行 全テストをいい感じに 各IDに割り振って
Rubyで用いし先駆者がいた GitHub Actions でテストを並列化して CI 時間を短縮する - Gunosy Tech Blog
並列化したい数だけ IDを宣言しておいて 各ノードは自分の IDの テストだけ実行 全テストをいい感じに 各IDに割り振って これをGoでも やりたい!
Goでのテスト分割は(とりあえず)パッケージ毎で
Goでのテスト分割は(とりあえず)パッケージ毎で これが
Goでのテスト分割は(とりあえず)パッケージ毎で これが こうなりました
Goでのテスト分割は(とりあえず)パッケージ毎で これが こうなりました パッケージのパスを列挙して
Goでのテスト分割は(とりあえず)パッケージ毎で これが こうなりました パッケージのパスを列挙して テスト対象外の パッケージを 除外して (無くてもいいしいくつあってもいい )
Goでのテスト分割は(とりあえず)パッケージ毎で これが こうなりました パッケージのパスを列挙して 行番号を4(並列数)で割ったあまり == 自分のid なら担当 テスト対象外の パッケージを
除外して (無くてもいいしいくつあってもいい )
Goでのテスト分割は(とりあえず)パッケージ毎で これが こうなりました パッケージのパスを列挙して テスト対象外の パッケージを 除外して (無くてもいいしいくつあってもいい ) 行番号を4(並列数)で割ったあまり
== 自分のid なら担当 よし!いけるぞ! と言いたいところだが ...
唯一の懸念点: カバレッジレポートどうしよう
Goは素晴らしい言語なので $ go test -cover ./... -coverprofile=<ファイル名>.out でテスト時にカバレッジのプロファイルを吐き出しておき $ go
tool cover -html=<ファイル名>.out -o <ファイル名>.html でカバレッジレポートを作れる 唯一の懸念点: カバレッジレポートどうしよう
唯一の懸念点: カバレッジレポートどうしよう Goは素晴らしい言語なので $ go test -cover ./... -coverprofile=<ファイル名>.out でテスト時にカバレッジのプロファイルを吐き出しておき
$ go tool cover -html=<ファイル名>.out -o <ファイル名>.html でカバレッジレポートを作れる でもnノードで分割実行したら細切れのカバレッジレポートが n個できちゃう
唯一の懸念点: カバレッジレポートどうしよう Goは素晴らしい言語なので $ go test -cover ./... -coverprofile=<ファイル名>.out でテスト時にカバレッジのプロファイルを吐き出しておき
$ go tool cover -html=<ファイル名>.out -o <ファイル名>.html でカバレッジレポートを作れる でもnノードで分割実行したら細切れのカバレッジレポートが n個できちゃう → 結論: プロファイルの仕様で (無理やり)解決!
唯一の懸念点: カバレッジレポートどうしよう 結論: プロファイルの仕様で (無理やり)解決!
唯一の懸念点: カバレッジレポートどうしよう 結論: プロファイルの仕様 で(無理やり)解決!
唯一の懸念点: カバレッジレポートどうしよう 結論: プロファイルの仕様 で(無理やり)解決! カバレッジの計算モード set・count・atomicがある(割愛) ※ golang/go/src/cmd/cover/profile.goに該当の実装があります
各ファイルのカバレッジ情報 <file_path>:<start_line>.<start_col>,<end_line>.<end_col> <num_statements> <count> というフォーマットでカバレッジが大量にメモられている カバレッジの計算モード set・count・atomicがある(割愛) ※ golang/go/src/cmd/cover/profile.goに該当の実装があります 唯一の懸念点:
カバレッジレポートどうしよう 結論: プロファイルの仕様 で(無理やり)解決!
そしてできあがった.yamlがこちら
そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります
そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります 例のID
例のID そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります テストを実行しプロファイルを出力
例のID そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります テストを実行しプロファイルを出力 名前にIDを含んだartifactを後続のジョブに遺す
例のID そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります テストを実行しプロファイルを出力 名前にIDを含んだartifactを後続のジョブに遺す ダウンロード
例のID そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります テストを実行しプロファイルを出力 名前にIDを含んだartifactを後続のジョブに遺す ダウンロード 1行目を直接書いて最終ファイルを作成 →各プロファイルの2行目以降をくっつける
例のID そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります テストを実行しプロファイルを出力 名前にIDを含んだartifactを後続のジョブに遺す ダウンロード レポート 作成
例のID そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります テストを実行しプロファイルを出力 名前にIDを含んだartifactを後続のジョブに遺す ダウンロード レポート 作成
最終レポート(HTML)を保存
例のID そしてできあがった.yamlがこちら ※ 環境変数や serviceなど、この発表の範囲外と判断したために一部省略している箇所があります テストを実行しプロファイルを出力 名前にIDを含んだartifactを後続のジョブに遺す ダウンロード レポート 作成
最終レポート(HTML)を保存 絶対もっといいやり方あるだろ
\ ありがとうございました! /