はじめに

本記事は個人開発でGitHub Actionsを用いた自動テスト環境を構築する際に調べた内容をまとめました。
個人開発でもチーム開発でも関係なく知っておくべき内容だと思うので、忘備録として書きました。

ゴール

最終的に達成したい内容は下記です。(mainブランチへの直pushは禁止している前提です)

GitHub Actionsを用いてソースコードをpushした際にテスト(Lintチェック, 型チェック)を実行する。
テストが通らなければマージブロックする。
マージブロックが解消されたらマージする。

GitHub Actionsとは

今回利用するGitHub ActionsとはCI/CDのプラットフォームです。

言葉だけでは何もわからないので実際にコードを書き、それぞれの用語について解説していきます。

ワークフローの作成

特定のイベント(特定のアクティビティが実行された時、スケジュールした時間)で実行したい内容を記述します。
今回はpushされた時にテストを走らせることが目的です。
ワークフローは以下の手順で作成します。

自身のリポジトリで、ワークフローファイルを格納するための.github/workflows/ディレクトリをルート直下に作成します。
.github/workflows/ディレクトリで、任意のファイル名.ymlという名前の新しいファイルを作成し、コードを追加します。
これらの変更をコミットして、GitHubリポジトリにプッシュします。

コードの内容は以下のようになります。

それぞれ用語を解説していきます。

用語

nameについて (1行目)
そのまま単純にこのワークフローの名前を表しています。
GitHubリポジトリのActionタブのワークフロー実行の一覧に表示されます。
onについて (2行目から5行目)
このワークフローのトリガーを指定しています。
今回はpushイベントを使用しており、かつpathsでsrc/**と指定しています。
具体的に何をしているかと言うと「srcディレクトリ以下の変更内容がpushされた時」トリガーされます。
jobsについて (7行目から12行目)
このワークフローで実行される全てのジョブをグループ化します。
今回はbuildという名前のジョブが実行されます。
実行環境は、runs-onで指定することができ、最新のUbuntu環境を指定しています。
また、複数のマシンで実行する場合はstrategyを指定する必要があり、10行目から12行目ではnode-versionで指定した16.xと18.xの各バージョンで実行することを意味しています。
stepsについて (14行目から23行目)
このワークフローで実行される一連のタスクを指定しています。
uses: actions/checkout@v2はリポジトリをチェックアウトするためのアクションで、事前定義されているものを使用しています。(v2はメジャーバージョンを表しています)
同じようにuses: actions/setup-node@v2ではNode.jsの実行環境を作成しています。
runはコマンドラインで実行する内容を表しており、今回はyarn tscとyarn lintを実施しています。
(各nameは各アクションの名前です)

GitHub Actionsの挙動確認

上記のコードを実際に試します。
mainブランチに作成したワークフローがマージされていることを確認し、新しくブランチを切ってpushしてみます。
(pathsでフィルターをかけているのでsrcディレクトリ以下の変更内容でないとワークフローが実行されません)

testブランチを作成し、pushしてPRを作成しました。

スクショのSome checks haven't completed yetでテストが行われていることがわかります。
Checksタブを開いてみます。

先ほどjobsで設定したbuildという名前で、Node.jsのバージョン[16.x 18.x]それぞれの環境で実行されていることがわかります。

これでGitHub Actionsの自動テストが正しく行われていることが確認できました。
ですが、テストが通らずエラーとなっていてもマージできてしまう状態です。

テストが通らなかった場合はマージできないように、マージブロックを設定します。

マージブロックの設定

まずはリポジトリのSettingsタブを開きます。
サイドメニューのBranchesを選択し、Add branch protection ruleを開きます。

Branch name pattern を入力し、Require status checks to pass before mergingにチェックを入れます。
Require status checks to pass before mergingは「マージ前にステータスチェックに合格する必要がある」ことを意味しているので、どのステータスチェックに合格する必要があるのかを選択します。

ここでステータスチェックの検索にかけるワードは先ほど記述したワークフローのjobsの名前です。
(今回はbuildと設定しているのでbuildで検索)

build(16.x)とbuild(18.x)がヒットしたので両方選択し、一番下のCreateボタンで作成します。

サイドバーのBranchesを選択すると、新たにルールが作成されていることが確認できます。

ルールが作成されたことを確認できたら、先ほどのPRを見てみます。
先ほどとは異なり、マージができないようになっています。

テストのエラーが解消された段階でマージが可能な状態になります。
これでマージブロックの設定が完了しました。

チーム開発であればテストの合否だけでなく、レビューをしてもらわないとマージできないようにも設定できます。

次は個人開発をしているときに重宝されるであろう(知らんけど)自動マージについて解説していきます。

自動マージの設定

テストでこけた(マージブロック)PRで自動マージを設定していきます。

自動マージの設定はリポジトリ単位ではなくPR単位になります。

まずは今までと同様にリポジトリのSettingタブを開きます。
中盤から下の方にある、Pull RequestsセクションのAllow auto-mergeにチェックします。

これで先ほどマージブロックされたPRを見てみます。
Enable auto-mergeと表示されているのがわかります。

Enable auto-mergeをクリックするとマージする時と同じような画面が出るので必要なコメントを残しConfirm auto-mergeをクリックします。
これで自動マージの準備は完了しました。(Disable auto-mergeからいつでも設定解除できます。)

この状態でマージブロックを解消してやると自動でマージされます。

まとめ

今回記事を書いていく中で、GitHub Actionsのワークフローに関してはまだまだ理解が足りないなと実感しました。(できることが多すぎる)
ですが、自動テストに関してはこれから転職を目指す初心者の方にとっても知っていて損はないので実際に試していただきたいところです。
自動マージに関しましては、PRごとに設定する必要があり、必ず自動化の恩恵が受けられるとは思わないので必要に応じて使いこなしていければいいかなと思いました。
書けば書くほど雑になりましたが、最後にブランチ削除の設定だけ解説して終わりにしたいと思います。
興味のある方だけ読んでみてください。

オマケ

ブランチの自動削除の設定を行います。
基本的にマージされたブランチは必要ないものなので削除すると思うのですが、この操作も自動化してしまいます。(めちゃ簡単です)
先ほど自動マージの設定と同様にリポジトリのSettingを開きます。
そして先ほどチェックを入れたAllow auto-mergeの下のAutomatically delete head branchesにチェックを入れます。

終わりです。
これでマージされたタイミングで自動でブランチが削除されるようになりました。

自動化できるところはどんどん自動化して開発スピードを上げていきましょう！

GitHub Actions を用いた自動テストと自動マージ