pre-receiveフックについて

pre-receiveフックについて

プッシュが行われると、各スクリプトは分離された環境で実行され、プッシュの内容についてのチェックを実行できます。 このスクリプトの終了ステータスが0ならプッシュは受け付けられ、0以外なら拒否されることになります。

pre-receiveフックは、ビジネスルールを満たしたり、規制の遵守を強制したり、一般的なミスを避けたりするために利用してください。

pre-receiveフックの利用方法の例：

• 正当なチケット番号を含めたり、一定以上の長さでなければならなかったりといった特定のパターンやフォーマットに伴うコミットメッセージを要求する。
• すべてのプッシュを拒否する事でブランチまたはリポジトリをロックする。
• キーワード、パターン、またはファイルタイプをブロックすることにより、機密データがリポジトリに追加されないようする。
• PRの作者が自身の変更をマージしないようにする。

GitHub Enterprise Server の受信前フックの例を github/platform-samples リポジトリで参照できます。

パフォーマンスとワークフローへの影響

開発者と開発者のワークフローへの影響は大きくなりうるので、注意深く検討することが必要です。 ビジネス上の要求に基づき、思慮深く実装されたpre-receiveフックは、全体として組織に最大のメリットをもたらします。

pre-receive フックは お使いの GitHub Enterprise Server インスタンス のパフォーマンスに意図しない影響をもたらすことがあるため、慎重に実装して確認する必要があります。

インスタンスのすべてのユーザーに対する障害およびパフォーマンスへの影響のリスクを考慮し、次のことをお勧めします。

• pre-receive フック内での API 要求を回避します。 特に、外部サービスへの要求は、時間がかかる上にパフォーマンスへの影響が大きくなる可能性があるため、推奨しておりません。
• pre-receive フック内での実行時間の長い Git 操作を回避します。 pre-receive フックが大規模なリポジトリまたは高負荷のリポジトリ内で Git 操作を実行する場合、インスタンスの Git と全体的なパフォーマンスに悪影響を及ぼす可能性があります。

プッシュ ルールと pre-receive フックの選択

プッシュ ルールと pre-receive フックを使って、ユーザーがリポジトリにプッシュできる変更を制御できます。 どちらもポリシーを適用するのに役立ちますが、その動作方法は異なり、異なるユース ケース用に設計されています。

プッシュ ルールは、リポジトリ間で一般的なポリシーを適用するための組み込みの方法です。 それを使うと、特定のファイルとパス、ファイル サイズ、ファイルの種類の更新など、特定の条件を満たしていないプッシュをブロックできます。 プッシュ ルールは UI または API を使って管理できます。 プッシュ ルールは、リポジトリ ルールセットの一種であるため、監査ログをサポートしており、評価モードで使って変更をプレビューしたり、必要に応じてバイパスしたりできます。

次のことを簡単に行いたい場合は、プッシュ ルールを使います。

• スクリプトを書かずに標準ポリシーを適用します。
• 複数の organization やリポジトリにポリシーを一貫して適用します。
• GitHub の UI と API を使ってルールを管理します。
• 監査ログ、バイパス リスト、ルール分析情報など、GitHub のネイティブ機能を使います。