ビルドが完了した後、ビルドのビルド結果を設定することは可能ですか？
これを実行するプラグインはまだ見つかりませんでした。自分でプラグインを作成することを検討していましたが、その道を進む前に、これが可能かどうかを確認したいと思いました。
（既存のコードと「FailThe Build」プラグインがどのように機能するかを例として見てきましたが、Jenkinsコードベースの理解は、すべての可能性を理解するのに十分なほど進んでいません。）
ユースケース：ビルドパイプラインがあり、パイプラインの終わり近くに、アーティファクトをQA環境にデプロイするデプロイからQAへのステップがあります。このステップの前に、アーティファクトの問題を検出するための自動テストを実施しましたが、一部の領域ではテストカバレッジがそれほど高くないため、バグがクラックをすり抜ける可能性があります。事後にdeploy-to-qaビルドをFAILEDとしてマークして、その特定のパイプラインが無効であり、本番リリースの候補ではないことを示す機能が必要です。（基本的に、このビルドパイプラインプラグインの問題と同じです）
コードをさらに調査した結果、これは不可能だと思います。
差出人hudson.model.Run：
public void setResult(Result r) {
// state can change only when we are building
assert state==State.BUILDING;
// snip
...
}
したがって、「ビルド」状態の場合を除いて、ビルド結果を変更することはできません。
lastSuccessfulおよびlastStableシンボリックリンクをいじくりまわすことができますが（のdelete()関数で行われるようにhudson.model.AbstractBuild）、Jenkinsがからビルド結果をリロードするとすぐにリセットされjobs/JOBNAME/builds/ます。
テストされていない提案があります：パラメータ化されたビルドを作成します。ここで、パラメータはビルドが失敗するかどうかを決定します（たとえば、設定した環境変数からパラメータをテストし、exit0またはexit1を実行する単純なbat/シェルスクリプト）。これは、パイプラインを手動でトリガーするステップがパラメーターを要求し、デフォルト値を使用しないことを前提としています。
インタラクティブなビルドパラメータをサポートしていない場合は、失敗するかどうかをこの追加のビルドステップに伝えるために他の方法が必要です。おそらく、アップストリームのビルドの説明または表示名を編集して失敗を示し、ビルドパイプラインがこの追加のビルドステップに進むことを許可します。これには、おそらくシステムgroovyスクリプトを使用してアップストリームのビルドの説明または表示名を掘り下げる必要があります。
私は以前にこのトピックに関するいくつかの議論を見てきました、そして結果は常にそうすることが理論的に可能であるということでした、しかしコードベースはこれを可能にするように設計されておらず、それは非常にハッキーな回避策でなければなりません。
これは一般的に悪い習慣だとも言われていますが、それに対する議論が何であったかは覚えていません。
私は同じ要件に直面しています。適切なプラグインが見つかりません。ビルドステータスの変更は単なるフラグではなく、リンクに他の影響を及ぼします（たとえば、最新の成功したビルドなど）。そのため、ビルドのステータスを変更する代わりに、ビルドを修飾する可能性を探しました。プロモートビルドプラグインは、フラグを適用してビルドし、さまざまな品質ステージなどを定義します。ビルドプロモーションは、手動で実行することも、ダウンストリームプロジェクトの成功したビルドなどに基づいて実行することもできます。プロモーションに基づいて、成功したビルドを認定できます。タグ付けやアーカイブなど、追加のビルドおよびビルド後のアクションを実行できます。
実際、build.xml手動でをに変更することでそれを行うことができました<result>FAILURE</result>。
次に、シンボリックリンクを作成するために少し遊んだ後mklink、lastSuccessfulBuildの名前をlastFailedBuildに変更しましたが、機能しました。Jenkinsプラグイン内からファイルシステムへのアクセスが許可されている場合は、ファイルシステムを作成できます。
現在のビルドを削除し、バージョン番号を使用して同じビルドを開始し、次のBUILD_NUMBERを削除されたビルドに設定する場合は、このプラグインを使用して、成功する代わりに失敗するように指示できます。