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 と全体的なパフォーマンスに悪影響を及ぼす可能性があります。