概要
Github のBranch protection 「Require status checks to pass before merging」に設定するstatus check用のjobを作成すると良さそう という話。
動機
Github のBranch protection には、「Require status checks to pass before merging」というruleがある。
If status checks are required for a repository, the required status checks must pass before you can merge your branch into the protected branch.
引用元：ステータスチェックについて
という記載の通り、
Branch protection ruleにstatus checkを設定すれば、
status check を通過しない限り、保護対象のブランチに対して作業ブランチがマージできないように保護することができる。
status checkの設定方法は以下の通り。
- Repository > Setting > Branches >
Add ruleor 既存ruleのeditをクリック。rule 設定ページに遷移 - Protect matching branches > Require status checks to pass before merging にチェックを入れて、
「Search for status checks in the last week for this repository」のフォームから、
status checkに使用するjob を指定する
上記の通り、
status-check は、workflowのjob単位で指定する必要がある。
例えば、以下のようなGithub Actoinsのworkflowファイルを作成済みの場合、
name: status-check
on:
workflow_dispatch:
pull_request:
jobs:
eslint:
name: eslint
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
# see https://github.com/reviewdog/action-eslint
- uses: reviewdog/action-eslint@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
workdir: './src/'
eslint_flags: 'resources/**/*.{js,ts}'
fail_on_error: truejobs > eslintを指定したい場合、以下の通り設定する必要がある。
これを設定すると、 保護対象のブランチ向けに作成されたpull requestは、
jobs > eslint がpassしない限り、マージできなくなる。
例えば、以下のような感じ。
「Require status checks to pass before merging」のProtection Ruleの使い方は上記の通りだが、
このRuleは、記載した通り
「status-check は、workflowのjob単位で指定する必要がある。」
そのため、status-check にステータスチェック対象を追加したくなった場合、
「Require status checks to pass before merging」のProtection Ruleに、チェック対象のjobを追加する必要がある。
例えば、ステータスチェック用のjob「php-cs-fixer」を追加する場合を考える。
まずは、jobを作成。
jobs:
php-cs-fixer:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
- name: Install dependencies
run: |
cd src
composer install
- name: Run PHP CS Fixer
run: |
cd src
composer run cs-fixer-dry-runで、以下の通り、チェック対象のjobを
Protect matching branches > 「Require status checks to pass before merging」 から追加する必要がある。
これが面倒だなと思っていました。
ソースだけで完結できればと思っていましたが、以下記事を見つけまして。
GitHub Actions による Renovate の安全自動マージ _5. status check 用の GitHub Actions job を用意する
まさに、これを解決する記事でした。
（元々、Renovateをいい感じに使う方法を探していて見つけた記事です）
上記の記事を読めば事足りる内容ではありますが、 実際に動きを確認してみたので、今回記事にしました。
（前置きが長い）
成果物
以下を設定していきます。
- worflowファイルの作成
- Branch protection の設定
1. workflow
name: status-check
on:
workflow_dispatch:
pull_request:
jobs:
eslint:
name: eslint
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
# see https://github.com/reviewdog/action-eslint
- uses: reviewdog/action-eslint@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
workdir: './src/'
eslint_flags: 'resources/**/*.{js,ts}'
fail_on_error: true
php-cs-fixer:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
- name: Install dependencies
run: |
cd src
composer install
- name: Run PHP CS Fixer
run: |
cd src
composer run cs-fixer-dry-run
# needsに指定したjobが一つでも失敗した場合、exit 1（失敗する）
status-check:
runs-on: ubuntu-latest
needs:
- eslint
- php-cs-fixer
if: failure()
steps:
- run: exit 1ポイントはstatus-check のjobです。
このjobは、
「needsで設定したjob（eslint、php-cs-fixer）が失敗したら、status-checkのjob自体を失敗として処理する」というものです。
仮に、status-checkしたいjobをが増えた場合には、以下手順になります。
１）workflowファイル内に、jobを新規で追加
２）status-check のneedsに「１）」のjobを追加する。
Branch protection側の変更が不要なのが嬉しい。
2. Branch protection の設定
「1. workflow」で作成したworkflowファイルのstatus-check のjobを指定します。
必要な設定は以上。
上記の通り設定後、保護対象ブランチ向けにpull requestを作成すると…
上記の通り、
php-cs-fixer のjobが失敗したために、
status-check のjobが失敗して、マージができなくなっていることが確認できました。
（蛇足ですが）
ついでに、
Repository > Github Actionsのstatus-check のworkflowを確認してみると
以下キャプチャのようになっています。
この表示、時々見かけたけどやっと意味が分かりました。
workflow内の主従関係？を表している図なんですね。
今回の場合で言うと、php-cs-fixer のjobが失敗してることに引っ張られて、status-check のjobも失敗しています。
と言う意味ですね。
副次的に勉強になりました。
感想
また一つ新しいことを知ることができた。
楽しい。嬉しい。
コメント