ジェンキンスのビルド/テスト失敗時のロールバック

Question

さて、実際には何の答えもありませんが、それに対する警告があります。だから私はなぜこれをするのは迷惑で危険なのか理解し、これらのことを考えました。しかし私のチームプロジェクト/管理がどのように設定されているのか（少なくとも今のところ）、誰かがコミットしてJenkinsがBitBucketのコミットを取り消し、テストは失敗します。これを行うためのプラグイン/方法はありますか？

Answer 1

しかし、ブランチからHEADコミットを取り除くには十分に簡単ですが、いくつかの理由で実際にはこれをjenkinsジョブで安全に実行することはできません。

最初の理由は、1回のコミットを処理していない可能性があることです。ジェンキンがどのように構成されているか（例えば、待ち時間がある）に応じて、単一のジェンキンジョブは複数のコミットを包含することができる。さらに、ユーザーが複数のコミットを一度にプッシュした可能性があります。

第2に、Jenkinsが起動したときにJenkinsを開始したコミットがHEADにあるという保証はありません。 Jenkinsが実行されている間に誰かがプッシュするだけで、人間の介入なしには不可能な、もっと複雑なリベースを試みる必要があります（特に、デフォルトでは自動的にマージコミットを再開できません）。

master/developブランチからのコミットを削除するのではなく、gitlabsのようなものがマスターにマージするようなところにパターンを取り入れることを強くお勧めします。 jenkinsでマルチブランチパイプラインジョブを設定すると、自動的にブランチを構築し、gitlabsを設定して、jenkinsジョブが失敗している間はマージを防ぐことができます。アイデアは、タスクごとにブランチを作成し、その後、ジェンキンスがあなたのブランチにマスターをマージし、プルリクエストを提出するときにそれを構築するというものです。このビルドが成功すると、マスターにマージすることができます。

https://about.gitlab.com/2014/09/29/gitlab-flow/

Answer 2

他の回答で述べたように、それは後よりも前にチェックする方が簡単です。

実際、試してみるともう一つのアイデアがあります。基本的に手動マージを繰り返します。誰かがそれを実装するのに成功し、経験を分かち合うのはうれしいことです。

1. 開発者は決して直接masterにプッシュしません。 （*）
2. 新しいコンテンツはmaster-rcにプッシュされます。これは常にmasterからの早送りです。彼らはレビューやいくつかの事前チェックの後、プルリクエストからのマージの開発者から直接プッシュすることができます。それが構築した場合（**）
3. あなたのCIは、テストでは、すべてのチェックが成功した場合、ビルドの成果物が、保存されているmasterは早送りAにある
4. など渡し、具体的には現在のmaster-rcからAをコミットし、テストを取得します。その後、手順3に戻ります。
5. チェックが失敗した場合、master-rcはmasterにリセットされ、そこに使用されていた作成者には障害が通知されます。その後、手順3に戻ります。（***）

この方法では、マスターはビルド済みであることが常に確実です。

（*）例外的な場合を除き、エラーの場合と同様にmaster-rcは新しいmasterにリセットされます。または、おそらくこれが必要な場合はmasterが壊れているので、解決するまで手順2〜6を停止するだけです。

（**）選択肢があります - ビルドサイクルとは独立していますが、新しいコンテンツは常にmaster-rc以上あります - 次の項目を参照してください。あるいは、彼らはサイクルの開始まで待つ。後者は、必要に応じて自動的にマージ可能なプルリクエストがあり、マージが承認された方が便利です。

（***）master-rcに内容がある場合、失敗したものと一緒に破棄することができます。これにより、作成者は再作成できます。または自動的にリベースされますが、これはすでにいくつかの複雑さです。