プッシュルール

プラン: Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

プッシュルールは、使いやすいインターフェースで有効にできるpre-receive Gitフックです。プッシュルールを使用すると、リポジトリにプッシュできるものとプッシュできないものをより詳細に制御できます。GitLabには保護ブランチがありますが、次のような、より具体的なルールが必要になる場合があります。

コミットの内容を評価する。
コミットメッセージが期待される形式に一致することを確認する。
ブランチ名のルールを適用する。
ファイルの詳細を評価する。
Gitタグの削除を防ぐ。
署名されたコミットを要求します。

GitLabのプッシュルールの正規表現では、RE2構文が使用されます。regex101正規表現テスターでテストできます。各正規表現は511文字に制限されています。

カスタムプッシュルールには、サーバーフックを使用します。

フォークの同期中にプッシュルールはバイパスされます。アップストリームプロジェクトからフォークを更新すると、フォークのプッシュルールに対する検証なしで変更が直接適用されます。

プッシュルールは、継承された設定ではなく、テンプレートとして機能します:

グローバルプッシュルールは、新しいプロジェクトのテンプレートとして機能します。グローバルプッシュルールを作成すると、それ以降に作成されたすべてのプロジェクトにコピーされます。
プロジェクトプッシュルールは独立したコピーです。プロジェクトが作成された後、グローバルルールまたはグループルールを変更しても、そのプッシュルールは自動的に更新されません。
プロジェクトプッシュルールを削除すると、そのプロジェクトからすべてのプッシュルール制御が削除されます。プロジェクトは、グローバルルールまたはグループルールを使用するようには戻りません。

更新されたグローバルプッシュルールを既存のプロジェクトに適用するには、各プロジェクトごとに個別にグローバルプッシュルールをオーバーライドする必要があります。

プロジェクトからプッシュルールを削除すると、そのプロジェクトにはプッシュルールがまったくなくなります。プロジェクトは、グループまたはインスタンスからルールを自動的に継承しません。プッシュルールを復元するには、そのプロジェクトに対して再度設定する必要があります。

グローバルプッシュルールを有効にする

すべての新しいプロジェクトのテンプレートとして機能するプッシュルールを作成できます。これらのルールは、個々のプロジェクトまたはグループでオーバーライドできます。

グローバルプッシュルールを設定する場合:

グローバルプッシュルールを設定した後で作成されたすべてのプロジェクトは、この設定のコピーを継承します。
既存のプロジェクトは影響を受けません。これらのプロジェクトを手動で更新するには、プロジェクトごとのグローバルプッシュルールをオーバーライドを参照してください。
グローバルプッシュルールへの変更は、すでにプッシュルールが設定されているプロジェクトを更新しません。

前提条件:

管理者である必要があります。

グローバルプッシュルールを作成するには:

右上隅で、管理者を選択します。
プッシュルールを選択します。
プッシュルールを展開します。
必要なルールを設定します。
プッシュルールを保存を選択します。

グループプッシュルール

プラン: Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

グループッシュルールにより、グループメンテナーは特定のグループで新しく作成されたプロジェクトのプッシュルールを設定できます。

グループのプッシュルールを設定するには:

上部のバーで、検索または移動先を選択して、グループを見つけます。
設定 > リポジトリを選択します。
事前定義されたプッシュルールセクションを展開します。
必要な設定を選択します。
プッシュルールを保存を選択します。

新しいプロジェクトは、プッシュルールを以下から継承します。

プッシュルールが定義された最も近い親グループ。
プッシュルールが定義された親グループがない場合は、インスタンス全体に設定されたプッシュルール。

プロジェクトのみがプッシュルールを継承します。サブグループは、親グループからプッシュルールを継承しません。どのプッシュルールが新しいプロジェクトに適用されるかを確認するには、サブグループにプロジェクトを作成し、プロジェクトのプッシュルールを確認します。

プロジェクトごとにグローバルプッシュルールをオーバーライドする

プロジェクトプッシュルールは、グローバルプッシュルールとは独立しています。プロジェクトにプッシュルールを設定すると、それらのルールは、そのプロジェクトに対して以前に設定されていたルールを置き換えます。

プロジェクトのプッシュルールを設定するには:

上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
設定 > リポジトリを選択します。
プッシュルールを展開します。
必要なルールを設定します。
プッシュルールを保存を選択します。

プロジェクトが新しいグローバルプッシュルールに一致するようにするには、プロジェクトのプッシュルールがグローバル設定に一致するように設定する必要があります。プロジェクトは、グローバルプッシュルールへの変更を自動的に継承しません。

ユーザーを検証する

これらのルールを使用して、コミットを行うユーザーを検証します。

これらのプッシュルールは、コミットにのみ適用され、タグには適用されません。

未認証のユーザーを拒否する: コミッターのメールは、ユーザーの確認済みのメールアドレスまたはプライベートコミットメールアドレスのいずれかと一致する必要があります。
一貫性のないユーザー名を拒否する: 作成者とコミッターのメールアドレスが同じであるコミットの場合、コミット作成者名はユーザーのGitLabアカウント名と一致する必要があります。これらのメールアドレスが異なる場合、チェックはスキップされます。これは、他のコントリビューターからのコミットをチェリーピックするまたはリベースするなどのワークフロー中に発生します。
このルールは、ユーザーのGit設定における設定ミスを検出することでコミットの整合性を維持するのに役立ちますが、代理はブロックしません。暗号学的なID検証には、代わりに署名されていないコミットを拒否を使用します。
コミットの作成者がGitLabのユーザーであるかどうかを確認する: コミットの作成者とコミッターのメールアドレスは、両方ともGitLabユーザーの確認済みのメールアドレスと一致する必要があります。
コミットの作成者のメール: 作成者とコミッターの両方のメールアドレスが、正規表現と一致する必要があります。任意のメールアドレスを許可するには、空のままにします。

プロジェクトのボットユーザーまたはグループのボットユーザーを使用する場合は、生成されたメールサフィックスを追加して、ボットトークンが変更をコミットしてプッシュできるようにする必要があります。

コミットメッセージを検証する

コミットメッセージには次のルールを使用します:

コミットメッセージ内に必要な表現: メッセージは、その表現と一致する必要があります。任意のコミットメッセージを許可するには、空のままにします。マルチラインモードを使用します。(?-m)を使用すると無効にできます。検証の例は、次のとおりです。
- JIRA\-\d+は、すべてのコミットがRefactored css. Fixes JIRA-123のようにJiraのイシューを参照することを要求します。
- [[:^punct:]]\b$は、最後の文字が句読点である場合、コミットを拒否します。Gitがコミットメッセージの最後に改行文字（\n）を追加するため、単語境界文字（\b）は偽陰性を防ぎます。
GitLab UIで作成されたコミットメッセージは、改行文字として\r\nを設定します。正規表現で\nの代わりに(\r\n?|\n)を使用して、正しく一致させてください。
たとえば、次の複数行のコミットの説明があるとします。
```
JIRA:
Description
```
正規表現JIRA:(\r\n?|\n)\w+で検証できます。
コミットメッセージ内の拒否する表現: コミットメッセージは、その表現と一致してはなりません。任意のコミットメッセージを許可するには、空のままにします。マルチラインモードを使用します。(?-m)を使用すると無効にできます。

ブランチ名を検証する

ブランチ名を検証するには、ブランチ名の正規表現を入力します。任意のブランチ名を許可するには、空のままにします。デフォルトブランチは常に許可されます。特定の形式のブランチ名は、セキュリティ上の目的でデフォルトで制限されています。Gitコミットハッシュと同様の40個の16進文字の名前は禁止されています。

検証の例は、次のとおりです。

ブランチはJIRA-で始まる必要があります。
```
^JIRA-
```
ブランチは-JIRAで終わる必要があります。
```
-JIRA$
```
ブランチの長さは4文字から15文字の間で、小文字、数字、ダッシュのみを受け入れる必要があります。
```
^[a-z0-9\\-]{4,15}$
```

意図しない結果を防ぐ

これらのルールを使用して、意図しない結果を防ぎます。

署名なしコミットを拒否: コミットは署名されている必要があります。このルールは、Web IDEで作成された正当なコミットをブロックしたり、GitLabによって作成された署名なしコミットがコミット履歴に表示されることを許可したりする場合があります。
git pushでGitタグを削除することをユーザーに許可しない: ユーザーは、git pushを使用してGitタグを削除できません。

ファイルを検証する

これらのルールを使用して、コミットに含まれるファイルを検証します。

シークレットファイルのプッシュを防止: ファイルにシークレットが含まれていてはなりません。
禁止されているファイル名: リポジトリに存在しないファイルは、正規表現と一致してはなりません。すべてのファイル名を許可するには、空のままにします。一般的な例を参照してください。
最大ファイルサイズ: 追加または更新されたファイルは、このファイルサイズ（MB単位）を超えてはなりません。任意のサイズのファイルを許可するには、0に設定します。Git LFSによって追跡されるファイルは除外されます。

リポジトリへのシークレットのプッシュを防止する

認証情報ファイルやSSHシークレットキーなどのシークレットをバージョン管理システムにコミットしないでください。GitLabでは、定義済みのファイル名パターンリストを使用して、一致するファイルがリポジトリにプッシュされるのを防ぐことができます。一致するファイルを含むマージリクエストはブロックされます。このプッシュルールは、リポジトリにすでにコミットされているファイルを制限しません。ルールを使用するには、既存のプロジェクトの設定を更新する必要があります。これは、プロジェクトごとのグローバルプッシュルールをオーバーライドで説明されているプロセスを使用します。

このルールによってブロックされるファイルは、以下にリストされています。条件の完全なリストについては、files_denylist.ymlを参照してください。

AWS CLI認証情報blob:
- .aws/credentials
- aws/credentials
- homefolder/aws/credentials
プライベートRSA SSHキー:
- /ssh/id_rsa
- /.ssh/personal_rsa
- /config/server_rsa
- id_rsa
- .id_rsa
プライベートDSA SSHキー:
- /ssh/id_dsa
- /.ssh/personal_dsa
- /config/server_dsa
- id_dsa
- .id_dsa
プライベートED25519 SSHキー:
- /ssh/id_ed25519
- /.ssh/personal_ed25519
- /config/server_ed25519
- id_ed25519
- .id_ed25519
プライベートECDSA SSHキー:
- /ssh/id_ecdsa
- /.ssh/personal_ecdsa
- /config/server_ecdsa
- id_ecdsa
- .id_ecdsa
プライベートECDSA_SK SSHキー:
- /ssh/id_ecdsa_sk
- /.ssh/personal_ecdsa_sk
- /config/server_ecdsa_sk
- id_ecdsa_sk
- .id_ecdsa_sk
プライベートED25519_SK SSHキー:
- /ssh/id_ed25519_sk
- /.ssh/personal_ed25519_sk
- /config/server_ed25519_sk
- id_ed25519_sk
- .id_ed25519_sk
これらのサフィックスで終わるファイル:
- *.pem
- *.key
- *.history
- *_history

ファイル名による禁止

Gitでは、ファイル名にはファイルの名前と、名前の前にあるすべてのディレクトリが含まれます。git pushすると、プッシュ内の各ファイル名が禁止されているファイル名の正規表現と比較されます。

この機能は、肯定的または否定的な先読みをサポートしないRE2構文を使用します。

正規表現は次のことができます:

リポジトリ内の任意の場所にあるファイル名と一致します。
特定の場所にあるファイル名と一致します。
部分的なファイル名と一致します。
拡張子によって特定のファイルタイプを除外します。
複数の式を組み合わせて、複数のパターンを除外します。

正規表現の例

これらの例では、一般的な正規表現文字列の境界パターンを使用します。

^: 文字列の先頭に一致します。
$: 文字列の末尾に一致します。
\.: リテラルピリオド文字に一致します。バックスラッシュはピリオドをエスケープします。
\/: リテラルフォワードスラッシュと一致します。バックスラッシュはフォワードスラッシュをエスケープします。

特定のファイルタイプの防止

.exeファイルをリポジトリ内の任意の場所にプッシュするのを防ぐには、次のようにします。
```
\.exe$
```

特定のファイルの防止

特定の設定ファイルのプッシュを防ぐには、次のようにします。
- リポジトリルート内:
```
^config\.yml$
```
- 特定のディレクトリ内:
```
^directory-name\/config\.yml$
```
任意の場所 - この例では、install.exeという名前のファイルのプッシュを防ぎます。
```
(^|\/)install\.exe$
```

パターンの結合

複数のパターンを1つの式に結合できます。この例では、以前のすべての式を結合します。

(\.exe|^config\.yml|^directory-name\/config\.yml|(^|\/)install\.exe)$

署名されたコミットを要求する

署名されたコミットは、Gitコミットの信頼性と整合性を検証するために使用されるデジタル署名です。署名されていないコミットを拒否プッシュルールを使用して、外部コントリビューターに対して署名されたコミットを適用し、GitLabで作成されたコミットは署名なしコミットのままにすることを許可します。

署名されていないコミットを拒否プッシュルールを有効にすると:

GitLabの外部からプッシュされたコミット (git pushを使用) には、有効な暗号学的署名が含まれている必要があります。署名なしコミットは拒否されます。
GitLab UIまたはAPIを介して作成されたコミットは、署名がなくても許可されます。これらのコミットは、Web IDE、マージリクエストアクション、およびAPI操作から発生する可能性があります。

GitLabで作成されたコミットはこのルールの対象外であるため、ルールが有効になっている場合でも、署名なしコミットがコミット履歴に表示される可能性があります。このルールは、外部Gitクライアントからプッシュされたコミットのみを検証するします。

詳細については、イシュー5361を参照してください。

署名は、サポートされている署名方法で作成する必要があります:

GPG
SSH
X.509

無効な署名または破損した署名を持つコミットは拒否されます。

ルールを有効にする

署名されていないコミットを拒否プッシュルールを有効にするには:

上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
設定 > リポジトリを選択します。
プッシュルールを展開します。
署名されていないコミットを拒否を選択します。
プッシュルールを保存を選択します。

署名なしコミットとWeb IDEを拒否する

プロジェクトに署名されていないコミットを拒否プッシュルールが設定されている場合、ユーザーはGitLab Web IDEを介してデフォルトではコミットを作成できません。

このプッシュルールを持つプロジェクトでWeb IDEを介したコミットを許可するには、GitLab管理者が機能フラグreject_unsigned_commits_by_gitlabを無効にする必要があります:

Feature.disable(:reject_unsigned_commits_by_gitlab)

この機能フラグが無効になっている場合、Web IDEで作成されたコミットは署名なしで許可されます。詳細については、機能の有効化または無効化を参照してください。

DCO認定されていないコミットを拒否する

Developer Certificate of Origin（DCO）で署名されたコミットは、コントリビューターがそのコミットでコントリビュートされたコードを作成したか、または送信する権利を有することを証明します。プロジェクトへのすべてのコミットがDCOに準拠するように要求できます。このプッシュルールでは、すべてのコミットメッセージにSigned-off-by:トレーラーが必要であり、それがないコミットは拒否されます。

リポジトリを保護する
複雑なカスタムプッシュルールを作成するためのGitサーバーフック（以前はサーバーフックと呼ばれていました）
署名済みコミット
保護ブランチ
シークレット検出

トラブルシューティング

すべてのプロジェクトのプッシュルールの一括更新

すべてのプロジェクトでプッシュルールを同じにするように更新するには、Railsコンソールを使用するか、プッシュルールAPIエンドポイントを使用して各プロジェクトを更新するスクリプトを作成します。

たとえば、コミットの作成者がGitLabのユーザーであるかどうかを確認しますチェックボックスと**git pushでGitタグを削除することをユーザーに許可しない**チェックボックスを有効にし、Railsコンソールを介して特定のEメールのドメインからのコミットのみを許可するフィルターを作成するには、次のようにします。

データを変更するコマンドは、正しく実行されない場合、または適切な条件下で実行されない場合に、損傷を引き起こす可能性があります。最初にテスト環境でコマンドを実行し、復元できるバックアップインスタンスを準備してください。

Project.find_each do |p|
  pr = p.push_rule || PushRule.new(project: p)
  # Check whether the commit author is a GitLab user
  pr.member_check = true
  # Do not allow users to remove Git tags with `git push`
  pr.deny_delete_tag = true
  # Commit author's email
  pr.author_email_regex = '@domain\.com$'
  pr.save!
end