Github ActionsでCI構築

はじめに

「今の開発ブランチ、ビルドできなくない？」
ソース管理してるのにCIを構築していないと実際に起こる会話です。
手元ではビルドできるしターゲットブランチとのコンフリクトもないけど、マージしてみたらビルドは駄目だったなんてことは普通にある話です。

今回はGitHub Actionsを使ってゼロからCIを構築し、「エラーを起こしているブランチがmaster（や、develop）にマージされることはない」という状態を目指してみたいと思います。

環境

• .NET 6（今回はそこまで触れません）
• WIndows
• Powershell Core

準備

リポジトリ直下に.github/workflowsディレクトリを作成します。

> mkdir .github/workflows | cd

作成したworkflowディレクトリに適当な名前のymlファイルを作成します。

> New-Item workflow.yml

作成したymlファイルが、GitHub Actionsで実行するワークフローを定義するためのファイルになります。

ワークフローを作る

今回はVisual Studio 2022で作成した適当なサンプルプログラムを対象にCIを構築してみます。

ワークフロー名をきめる

ワークフローの名前を決めます。
これはGithub上のページで確認したりするのに使う名前なので、わかりやすいものがいいでしょう。

workflow.yml

 name: Build

どのタイミングで実行するかを決める

Github Actionsは特定のトリガーをもとに実行されます。
今回はプルリクエストのチェックに使いたいので、pull_requestをトリガーに設定します。

workflow.yml

  name: Build

+ on:
+   pull_request:
+     types: [opened, synchronize]

利用できるトリガーはGitHub Docsに記載があります。

実行するアクションを定義する

workflow.yml

  name: Build

  on:
    pull_request:
      types: [opened, synchronize]

+ jobs:
+   build:
+     runs-on: ubuntu-latest

一気に書きましたが一つづつ説明します。

実行単位

GitHub Actionsには、３つの実行単位があります

• Workflow
  • ワークフロー全体のことです。yamlファイル全体という認識で基本的には問題ないはずです。
• Job
  • 実行するマシンを共有する単位です。同一job内であれば同じマシン、jobを複数作成すれば別々のマシンが使われることになります。
• Step
  • 実行するシェルを共有する単位です。
    stepが複数ある場合、マシンは同じものですが別のシェルが与えられているため、シェル変数などはstep間で共有できません。
    単にコマンドを実行することもできるし、GitHubやサードパーティが公開しているアクションを使用することもできます。

今回は実行するマシンは単一で問題ないので、「build」ジョブ一つのみです。
実行環境はubuntu-latestを選択しています。

実行環境はGitHub側で用意してあるものを利用する「ホステッドランナー」と、自前で用意する「セルフホステッドランナー」のどちらかを選択できます。

ブランチのチェックアウト

ソースコードを引っ張ってこなければ意味がないので、まずはGitHubからソースコードを取得します。
GitHubの公式アクションを使います。

workflow.yml

  name: Build

  on:
    pull_request:
      types: [opened, synchronize]

  jobs:
    build:
      runs-on: ubuntu-latest
+     steps:
+       - name: Checkout
+         uses: actions/checkout@v3
+         

ビルド

ここまでくれば各言語、フレームワークで手元の環境と同じようなコマンドをランナーにやらせるだけです。
今回は.NET 6なのでdotnetコマンドを流します。
（※.NETの場合、事前にSDKのセットアップを実行しておく必要があります。）

workflow.yml

  name: Build

  on:
    pull_request:
      types: [opened, synchronize]

  jobs:
    build:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v3
+       - name: Setup .NET
+         uses: actions/setup-dotnet@v2
+       - name: build
+         run: dotnet build -c Release

実行してみる

master（main）以外のブランチにチェックアウトした後適当にコミットしてプッシュします。
プルリクエストを立てると、ワークフローが実行されます。
成功すれば、緑色のチェックが付きます。

とりあえずこのプルリクエストはマージしておきます。

ブランチ保護ルールの設定

さて、これだけでは「ビルド成否はチェックされるけど、ビルドエラーでもマージはできる」という状態なのでmaster（main）にブランチ保護ルール（Branch protection rules）を設定します。
”Require status checks to pass before merging”にチェックを入れ、ワークフロー名を入力し選択します。
”Do not allow bypassing the above settings”にもチェックを入れるとよいでしょう。

これを設定した後、適当にビルドエラーになるコードを新規ブランチにプッシュ、プルリクエストを作成します。

プルリクエストを確認すると、ビルドエラーが発生しマージボタンがグレーアウトされます