GitHubのブランチ保護でステータスチェックを必須にする

GitHubのブランチ保護でステータスチェックを必須にする

Clock Icon2023.09.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

GitHubには保護されたブランチという機能があり、ブランチに対してプッシュをする前に特定の条件をクリアしていることを強制することができます。例えば、1人以上の承認レビューが必要であるという条件をつけることで、レビューされていないプルリクエストが誤ってマージされるのを防ぐことができます。

どういう条件が設定できるかは、GitHub上にブランチ保護ルールとしていくつか選択肢が用意されていますが、「マージ前にステータスチェック必須」という機能を使って、指定されたCIテストにパスすることを必須にすることができるようです。どのように設定するのかなと疑問に思いましたので、この記事で実際に試してみます。

保護されたブランチについて - GitHub Docs

リポジトリ作成

GitHubのドキュメントには、

保護されたブランチは、GitHub Free及びOrganizationのGitHub Freeのパブリックリポジトリ、GitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverのパブリック及びプライベートリポジトリで利用できます。

とあります。今回はGitHub Freeのアカウントを使用するので、パブリックリポジトリを作成します。

新しいパブリックリポジトリを作成し、.gitignoreファイルだけがある状態です。

ブランチ保護の設定は、リポジトリの「Settings」⇒「Branches」から行えます。今はルールが何もないので、「Add branch protection rule」をクリックしてルールを作成します。

ステータスチェックを必須にするには「Require status checks to pass before merging」にチェックを入れます。今はまだ、チェックを入れても「No status checks found」と表示されて何も選択できません。よく読むと、過去1週間に行われたCIテストを探すようなので、まずはCIテストがリポジトリで実行される必要があります。

ワークフロー作成

リポジトリをローカルにチェックアウトして、.github/workflows/check.ymlファイルを作成します。

name: Status Check
on:
  push:
    branches:
      - '**'
      - '!master'

jobs:
  check1:
    runs-on: ubuntu-latest

    steps:
      - name: something test1
        run: exit 1

  check2:
    runs-on: ubuntu-latest

    steps:
      - name: something test2
        run: exit 0

そして、ブランチを作成してコミットとプッシュをします。すると、GitHubのActionsのところから、ワークフローが実行されたことがわかります。check1の方はexit 1にしているので失敗となります。

プッシュしたブランチからプルリクエストを作成します。現在はブランチ保護の設定を行っていないので、チェックは失敗しているもののマージはできるようになっています。

ブランチ保護の設定を開きます。先ほどは何も表示されていませんでしたが、GitHub Actionsが実行されたことで検索ボックスが表示されています。検索文字列を入力してみると、ワークフローのジョブがヒットします。

チェックに使いたいジョブを選択し、保護するブランチにmasterを入力して一番下の「Create」をクリックします。

プルリクエストを再度見てみると、今後は各ジョブのところにRequiredの表示がされ、チェックが失敗しているためマージボタンが押せないようになっています。

ワークフローをexit 0にしてプッシュすると、必須となっている全てのCIテストに通ったのでマージができるようになります。

このように、GitHubワークフローなどで作成したCIの仕組みをマージの必須条件にできるので、普段実行しているテストを条件に設定することもできますし、テストとは別にマージの条件をチェックするジョブを作ってそれでチェックするということもできそうです。

おわりに

マージできる状態だけど、本当にマージしていいのかな?と不安になったり、誤操作でマージしてしまったりすることもあるので、こういったチェックを使って条件に合っていないものは操作できないようにすると安心だと思いました。余計なことを考えず、開発に専念できるような仕組みはどんどん活用していきたいです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.