個人環境でもCIを使いたい
仕事でCI環境を使っていて大分慣れてきた為に、個人で何かやる時も環境がないと不安になるようになってきた。
GitHub Actionsを使うと簡単に実現できるらしく、試してみたので備忘録兼ねて残しておく。
Freeプラン(無料)で使える範囲
GitHubはFreeプランで使っているので、無料で使える枠を調べてみた。
公式のドキュメントによると、Freeプランでつかえる条件は次のような感じらしい。
- パブリック(公開)リポジトリ若しくはセルフホストのランナーだと、無条件に無料で利用できる。
- プライベート(非公開)リポジトリは、GitHubアカウント単位で2000分/月まで無料で利用できる。
個人ユースだと大抵パブリックでも問題はないが、そのうち仕事でも使うかもしれないので、プライベートでのユースについても少し調べる。
プライベートリポジトリでActionsを実行した後に、詳細画面上部に表示されるsummaryに表示されるBillable timeが課金対象の時間のようだ。
ちなみに、パブリックリポジトリだとBillable timeの項目自体が表示されない。
この時間の月辺りの合計が2000分まで無料で使えるということ。
ただし、ランナーに指定するOSによって、この時間に倍率がかかるらしい。
| OS | 倍率 |
|---|---|
| Linux | x1 |
| Windows | x2 |
| macOS | x10 |
上で例示したワークフローをLinuxで実行すると22s無料枠を消費するが、macOSで実行すると220sの無料枠を消費してしまうということのようだ。
Linterのような、特段OS依存性を気にしなくていいジョブであれば、Linuxを使っておくと節約になる。
現時点での利用状況は、公式ドキュメントのGitHub Actions の使用状況を表示するで説明されている手順で確認できる。
ワークフローを設定する
自動化したい一連の流れをワークフローといい、GitHub ActionsではYAMLファイルで定義する。
ワークフローを未定義の状態でActionsのタブを開くと、こんな感じにテンプレを用意してくれているものから選択することができる。
リポジトリの内容に応じて、推奨するテンプレを上位に表示してくれているようで、Set up this workflowをクリックすれば、こんな編集画面に遷移する。
ここで必要に応じて内容を編集し、いい感じなら右上のStart commitをクリックすると、リポジトリルートに.github/workfrows/***.ymlが追加されたコミットが行われる。(***は編集画面で設定した任意のファイル名)
以降は、このファイルを編集すれば色々なワークフローを実現できるようになる。
YAMLファイルの構文については、公式ドキュメントのリファレンス - ワークフロー構文に詳しく載っているので、テンプレの構文と合わせて参考にすると良い感じ。
CIでやりたいこと
CIで自動化したいことは、運用ルールによって異なると思うが、以下の4つあたりが多い気がする。
- ユニットテストの実行
- カバレッジの測定
- コーディング規約のチェック
- 循環複雑度のチェック
これらをワークフローに組み込むと、こんな感じの実行ステップになる。
- リポジトリのクローン・チェックアウト
- 実行環境の構築
- ユニットテストの実行
- カバレッジの測定
- コーディング規約のチェック
- 循環複雑度のチェック
この各ステップをYAMLファイル上に、実行コマンドで定義していく。
これらを1つのjobで設定しても良いが、途中のステップでコケると以降が実行されないので、独立性が高い5,6辺りは別jobにしてしまうのもアリだと思う。
トリガを決める
ワークフローを実行するトリガも同じYAMLファイル内で定義する。
主には、統合ブランチへのプッシュまたはプルリクで実行させたいケースが多いと思われるので、こんな設定になると思われる。
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
mainブランチをリリース専用にして、メインラインとしてdevelopブランチを用意している場合は、こんな感じになりそう。
on:
push:
branches: [ develop ]
pull_request:
branches: [ main, develop ]
この辺りの設定は、ブランチの運用ルールによって結構変わるので、リポジトリ毎にルールに見合った設定を逐次やる感じになる。
ちなみに、push,pull_requestはトリガが不要なら丸ごと消せばいい。例えばdevelopブランチだけでやりくりする場合は、pull_requestの項はいらないとか。
READMEにバッジをつける
最新のテスト結果のステータス表示とリンクとして、バッジを使うことができる。
Actionsのワークフローを選んで、右上の・・・からCreate status badgeをクリックすると、バッジの設定画面が表示される。
ここで、対象のブランチやイベント(プッシュやプルリクなど)を選ぶと、それに対応したバッジのリンクが作られるので、Copy status badge Markdownをクリックすれば、クリップボードにMarkdown書式でバッジのリンク付き画像がコピーされる。
後は、これをREADME.mdとかにペーストするだけで、こんな感じにREADME上にバッジを貼れる。
まとめ
GitHubアカウントさえ持っていれば、とてもお手軽にCI環境が作れていい感じ。
公式ドキュメントも割と充実しているので、使い方で困ることはそんなになさそう。
プライベートリポジトリだと無料枠の上限があるが、個人ユースでちょこっと使ってる分には、多分上限行かないと思う。
codeCovを合わせて使うと更に便利だったので、そちらの記事も書きたいなぁ。