失敗したビルドまたはリリースパイプラインのジョブとステージの再起動
そのステージまたはパイプライン Azure DevOps 失敗またはキャンセルされたビルド、リリース変更、またはパイプラインを再実行または再展開します。再試行は、新しい実行を作成するのではなく、 DevOps パイプライン UI に連続実行として表示されます。
パイプラインまたはステージ Azure DevOps 再実行
失敗またはキャンセルされたビルドを再実行したり、パイプラインをリリースしたり、 Azure DevOpsでジョブを変更したりできます。再実行は、 ServiceNow DevOpsでの最初の実行と同じパイプライン実行の一部として処理されます。パイプライン全体、または特定の失敗またはキャンセルされたジョブとステージを再実行できます。ステージまたはパイプラインを再起動するたびに新しい変更要求を作成する代わりに、変更要求を再利用することを選択できるようになりました。
ペイロードに attemptNumber パラメーターが追加され、再実行の追跡に役立ちます。関連するテストサマリー、ソフトウェア品質スキャン結果、 コミット、再実行試行ごとに対応する作業アイテムも ServiceNow DevOpsで更新されます。
Azure Invoke REST API を使用した変更管理の構成 を使用している場合は、ビルド パイプラインとリリース パイプラインに対して指定された構文形式でペイロード本文に試行番号パラメーターを追加する必要があります。試行回数パラメーターを指定しない場合、デフォルトの試行回数は 1 に設定されます。
"attemptNumber": "$(system.jobAttempt)""attemptNumber": "$(Release.AttemptNumber)"変更要求の再利用
変更が有効なジョブが再実行され、前回の実行/試行に対する変更要求が存在する場合は、ベースシステムの「DevOps 変更要求の再利用可能性決定サブフロー」を使用して、前の変更要求を再利用するか、新しい変更要求を作成するかを選択できます。このサブフローのデフォルト実装では、変更要求が実装状況または実装後状況である場合に、前回の試行からの変更要求を再利用できます。変更要求がその他のステータスの場合 (デフォルトでは )、ジョブを再実行すると新しい変更要求が作成されます。既存の動作に従って、テストサマリーやスキャンなどの関連するすべての詳細が新しく生成されますが、新しい変更要求に対してコミットと作業アイテムは変更されずに保持されます。
たとえば、変更要求が承認された後に特定のステージでパイプラインに障害が発生し、そのステージを再実行する場合などです。変更要求が再利用され、関連するテストサマリーとソフトウェア品質スキャン、およびアーティファクトに関連付けられたコミットと作業アイテムが、承認した同じ変更要求に関連付けられます。
再利用性のためにカスタムロジックを適用するには、既存のサブフローをコピーして変更を加え、公開し、下の新しいサブフロー名を更新します .
通常のベースシステムフローでは、変更が作成されると、変更要求に対する決定が下された後、ステップ実行レコードのStateフィールドを更新するために「DevOps フローのカスタマイズ」が使用されます。ただし、変更を再利用する場合、作成される変更要求の最初のトリガー条件は満たされません。ジョブが再実のときに変更要求が再利用されるたびに、「DevOps 変更要求の再利用可能性モデルサブフロー」ベースシステムサブフローが代わりにトリガーされます。このサブフローのデフォルトの実装は、 DevOps モデル変更要求フローと似ています。次の場所で カスタムサブフローを作成し、サブフロー名を更新できます .
パイプライン UI の変更
- カードをクリックすると、そのステージの最新の試行が表示されます。
- [すべての試行を表示] リンクをクリックすると、すべてのステップ実行と、複数回実行されたステップまたはステージに関連付けられた関連情報が表示されます。
- [変更を表示] リンクには、最新の試行に関連付けられた変更要求が表示されます。