そのページは、通常のビルドサイクルではなく、「バグを見つける」プラグインについて話していました。セットアップ方法に応じて、Jenkins は失敗の原因となった正確なコミットと作成者を特定できます。Jenkins に適切なソース管理プラグインがインストールされていて、ビルドが関連付けられているリポジトリを認識するように構成されている場合、ビルドごとに最後のビルド以降の変更が一覧表示されます。
さらに、Jenkins のレポート プラグインの多くには、欠陥のあるコミッターを非難する機能があります。たとえば、失敗したビルドに関する電子メール通知を、誤ったコミットを行った開発者に送信できます。
ただし、多くの設定により、Jenkins が知ることが困難になります。たとえば、Jenkins が毎日のビルド用に構成されている場合、問題を引き起こした可能性のある多くのコミットが存在する可能性があります。Jenkins がソース管理リポジトリを認識するように構成されていないか、ソース管理リポジトリがない可能性もあります。これらの問題により、Jenkins がビルド ブレーカーを識別できなくなる可能性があります。
具体的には、失敗したコミッターに電子メールを送信するために、最後の成功したビルド以降にコミットしたすべての人に電子メールを送信するオプションを持つemail-extプラグインを使用できます。
この件に関するユーモラスな見方については、このアプローチをご覧ください。
あなたが求めていることは、場合によっては不可能だと思います。犯人を特定するには、人間だけが判断できる紛争解決への洞察が必要です。それでも、仲裁のためにマネージャーが関与しなければならない場合があります。たとえば、既存の定義に依存する 3 つのコミット (A、B、C) を取得するとします。ただし、別のコミット (D) により、その関数の動作が変更されます。あなたはどちらを元に戻しますか？おそらく、A、B、Cをそのままにして、Dを元の状態に戻すのが事業計画です。反対に、A、B、C を変更して D の変更に適応させることも可能です。
マシンが調停を処理できる場合、原因を特定するのは単体テストと静的アナライザーの責任です (まだ不完全ではありますが)。静的アナライザーには、違反を犯した人に電子メールを送信する機能が組み込まれている場合があります。単体テストは、失敗したテストの責任を負うチームまたはチーム メンバーに通知するように記述できます。どちらも、特定の行で最後に失敗したコミッターを特定するのと同じ方法で機能します。それでも、リンクに問題がある場合は、おそらく一部のメンバーを特定のメイクファイルに関連付ける必要があります。