Continuous Integrationにちょっと興味が出ているので練習する。
目標
- GitHub Actionsを触る
- プッシュ時に自動的にビルド・Formatter適用・Linter適用ができるようにする
- Googleテストを触る
- 上のGitHub Actionsと連動して自動テストまでできると良い
今回は(1)のGitHub Actionsを試す。
CI_Practiceという練習用のリポジトリを作ってそこで遊ぶ。
1. GitHub Actions
1.1. 自動ビルド
とりあえずGitHub Actionsを押してみたところ、冒頭にCMake用のテンプレートがあったのでポチッと押したらすぐになにかできた。
あえてコンパイルエラーを起こすコミットを入れてみる。マージ前にやってしまったのでちょっと見にくくなったりしたが、ちゃんとエラーになることが確認できた。
ついでに「Run failed」を通知するメールも送られてきた。これなら気づかないということもないだろう。
1.2. 自動フォーマット
次は、プッシュした際に自動でフォーマットをかけたい。
（チェックするだけなら参考リンクというものがあるようだ。どうなんだろう、チェックだけで済ませるべきなのか、フォーマットかけるところまでやってしまった方が良いのか。）
とりあえずフォーマットをかけるところまでやる方向で考える。
フォーマットをかける場合、変更が生じたらそれをコミットする必要がある。それを行えるのが以下のものらしい。
継ぎ接ぎでコピペして作ると、たとえば以下のような感じの動作ができた。ぐちゃぐちゃの状態でコミットしたものが自動的にフォーマットされている。
フォーマットで更新がなかった場合はなにも起きない。
1.3. Linter適用
最後にclang-tidyを自動的に適用して警告をチェックする。
clang-tidyを使うときはcompile_commands.jsonというコンパイル設定を記述したファイルがあると良く、これはCMakeを行う際にcmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ONとすることで生成できる。参考リンク
コンパイル情報も必要なので、GitHub Actionsのbuildの後に付け足した。
これで変なコードを入れると警告が出るようになった。警告が出るだけではコマンド実行自体は正常にできているので通知メールなどは飛んでこない。clang-tidyに-warnings-as-errors=*オプションを立てることで全てエラーとして検知することで無理やり通知させることはできたが、ややスマートではないか。まぁとりあえず目標は達成できたということにする。
所感
ある程度GitHub Actionsを使うことはできたが、実運用的にはまだ学ばないといけないところが多い。
いつ適用するか
今回は試しなのでmasterへのプッシュ全てに適用させた。個人開発だと直接masterにプッシュすることもわりとあるので、これで良いのかもしれないが、チーム開発などではmasterへのPRを作るタイミング？ あるいはマージするタイミング？ など、ちゃんと考えなきゃいけない点はありそう。
またその際にフォーマッタはかけるのか、警告だけに留めるか、などの使い分けはありそう。
あと、GitHub Actionsにい登録しているJobの順番も実は大事で、フォーマッタかけて変更をしてからビルド・Linter適用という順番になってほしいが、今は多分不定になっている。
GPU環境をどうするか
将棋ソフトで試そうとすると、ビルドする際にCUDAやcuDNNやLibTorchなどが必要になってくるのでこんな簡単にはできない。フォーマッタ適用やビルド情報なしでのLinter適用くらいならできそうだが、それにどれだけの価値があるか……。
