Zenn
🧰

Check! GitHub Repository rulesetsとは？

2023/08/04に公開
GitHub
tech

Prologue

こんにちは、@dz_ こと、岩永かづみです。

突如登場した「GitHub Repository rulesets」について、まとめていきます。

  • 何ができるのか
  • 旧来のBranch protection rulesetsとの違いは？

GitHub Repository rulesetsとは

まずは、ざっくりと何ができるかポイントをまとめます。

  • BranchとTagに対し、ルールを設けることができる
  • パブリックリポジトリ、またはGitHub Pro/Team/Enterprise Cloudの契約下のプライベートリポジトリで利用できる
  • Bypassの対象や、metadataによる拒否など、柔軟な制御ができる
  • Organizationレベルでもルールセットを作成し、配下にリポジトリに継承させることができる💮

リポジトリにおけるRulesets

まず、リポジトリレベルにおけるrulesetsについて説明します。

画面キャプチャ

リポジトリにおけるRulesetsの新規作成画面
リポジトリにおけるRulesetsの新規作成画

Enforcement status

rulesetを適用するかどうかを指定できます。

Organization配下のリポジトリでは、「Active」「Evaluate」「Disable」を選択できます。「Evaluate」を選択すると、ルールは適用されないが、Insightsでルールの評価結果を確認できます。

Organization配下のリポジトリのEnforcement status
Organization配下のリポジトリのEnforcement status

個人アカウント配下のリポジトリでは、「Active」「Disable」を選択できます。

個人アカウント配下のリポジトリのEnforcement status
個人アカウント配下のリポジトリのEnforcement status

Bypass list

rulesetを適用しない対象を指定できます。指定は、ロールやチーム、GitHub Appsの単位で指定できます。ユーザーに対する指定はできません。

Bypassを割り当てる対象を追加する
Bypassを割り当てる対象を追加する

Target branches/tags

rulesetを適用する対象を指定できます。指定は、以下の選択肢があります。Tagの場合も同様です。

  • Include default branch
  • Include all branches
  • Include by pattern
  • Exclude by pattern

適用する対象を指定する
適用する対象を指定する

Branch protections/Tag protections

後述します。

Metadata restrictions

Organization配下のリポジトリでは、Metadataによる制御ができます。個人アカウント配下のリポジトリでは、項目がありません。

Metadata restrictionsの設定項目
Metadata restrictionsの設定項目

Applies ToとRequirementの選択肢は下記の通りです。

Applies To

  • Commit message
  • Author email
  • Committer email
  • Branch name

Requirement

項目 説明
Must start with a matching pattern 前方一致
Must end with a matching pattern 後方一致
Must contain a matching pattern 指定したパターンを含む
Must match a given regex pattern 正規表現による指定と一致する
Must not start with a matching pattern 指定したパターンから始まらない
Must not end with a matching pattern 指定したパターンで終わらない
Must not contain a matching pattern 指定したパターンを含まない
Must not match a given regex pattern 正規表現による指定と一致しない

リポジトリにおけるRule Insights

Organization配下のリポジトリでは、ルールの評価結果を確認できます。個人アカウント配下のリポジトリでは、利用できません。

リポジトリにおけるRule insights
リポジトリにおけるRule insights

※ 追って、評価の様子がわかるキャプチャを掲載したいです。

OrganizationレベルにおけるRulesets

Repository rulesetsは、Organizationレベルでも作成でき、対象とするリポジトリに適用できます。ここでは、Organizationレベルに置ける設定を紹介します。（リポジトリレベルと同様の項目は割愛します）

画面キャプチャ

OrganizationレベルにおけるRulesetsの新規作成画面
OrganizationレベルにおけるRulesetsの新規作成画面

Target repositories

Rulesetsを適用する対象のリポジトリを指定できます。指定は、「全て」「fnmatchによる指定」「個別に選択」を利用できます。また、Prevent renaming of target repositoriesを有効化することにより、リポジトリ名の変更を防ぐことができます。

Target repositoriesの設定項目
Target repositoriesの設定項目

fnmatchについては、下記ドキュメントをご参照ください。

OrganizationレベルにおけるRule Insights

Organizationレベルでも、ルールの評価結果を確認できます。

OrganizationレベルにおけるRule insights
OrganizationレベルにおけるRule insights

※ 追って、評価の様子がわかるキャプチャを掲載したいです。

Branch protectionsでできること

Branch protectionsにおいて設定できる項目は、以下の通りです。

項目 小項目 説明
Restrict creations ブランチの作成を禁止する
Restrict updates 更新（pushなど）を禁止する
Restrict deletions ブランチの削除を禁止する（デフォルトで有効）
Require linear history 履歴の分岐を許さない
Require deployments to succeed before merging マージする前に、deploymentsが成功することを要求する
Require signed commits 署名付きのコミットを要求する
Require a pull request before merging マージする前に、プルリクエストを要求する
Required approvals プルリクエストにおいて、承認（approval）を要求する
Dismiss stale pull request approvals when new commits are pushed 新しいコミットがプッシュされたときに古い承認を取り消す
Require review from Code Owners Code Ownersによるレビューを要求する
Require approval of the most recent reviewable push Approvalを得た後にプッシュされた変更がある場合は、approvalを要求する
Require conversation resolution before merging マージする前に、プルリクエストのconversation（コメント）が解決されていることを要求する
Require status checks to pass before merging マージする前に、status checkをクリアしていることを要求する
Require branches to be up to date before merging マージする前に、作業ブランチが最新（マージ先のブランチの変更が取り込まれている）であることを要求する
Block force pushes force pushを禁止する（デフォルトで有効）

なお、Branch protection rulesにある下記の設定項目は、Repository rulesetsでは確認できませんでした。

  • Restrict who can dismiss pull request reviews
  • Require merge queue

既存のBranch protection rulesとの違いは？

Repository rulesetsのBranch rulesetsと旧来のBranch protection rulesは、どちらもブランチに対する保護を行える機能ですが、その違いについて確認しました。

ロードマップでは、下記に「既存のbranch protection rulesの進化版」と表現されており、どうやらRepository rulesetsはBranch protection rulesの後継と解釈してよさそうです。

Repository rules are the evolution of GitHub's current branch protection rules, which will allow you to operate repository protections at scale with confidence and clarity.

大きな違いは、以下の点と筆者は考えます。Repository rulesetsの方がより柔軟にブランチの利用を制御できるようです。

  • Repository rulesetsは、Organizationレベルで設定でき配下のリポジトリに継承できる
    • （これまで私が担当したお客様からも、Branch protection rulesをOrganizationで制御したいというご要望を聞いておりました）
  • Repository rulesetsは、同じ名前パターンに対し、複数のrulesetsと設定できる
    • Branch protection rulesでは、同じ名前パターンに対し、1つのルールしか設定できない

Branch protection rulesについては、こちらの記事にまとめました。

https://zenn.dev/dzeyelid/articles/b8309a130d3b3b

Tag rulesetsでできること

Tag protectionsにおいて設定できる項目は、以下の通りです。

項目 小項目 説明
Restrict creations ブランチの作成を禁止する
Restrict updates 更新（pushなど）を禁止する
Restrict deletions ブランチの削除を禁止する（デフォルトで有効）
Require linear history 履歴の分岐を許さない
Require deployments to succeed before merging マージする前に、deploymentsが成功することを要求する
Require signed commits 署名付きのコミットを要求する
Require status checks to pass before merging マージする前に、status checkをクリアしていることを要求する
Require branches to be up to date before merging マージする前に、作業ブランチが最新（マージ先のブランチの変更が取り込まれている）であることを要求する
Block force pushes force pushを禁止する（デフォルトで有効）

Epilogue

Repository rulesetsは、Branch protection rulesと似たようなものでしょ？と高を括っていたのですが、改めて確認してみるとかなり柔軟にルールを設定できることがわかりました。

ブランチの扱いは日々の作業のトイルを減らすために非常に有用です。快適な開発・運用ライフを過ごせるようにしっかり活用していきたいですね。

Discussion