失敗したビルドまたはリリースパイプラインのジョブとステージの再開
そのステージまたはパイプラインで失敗またはキャンセルされたビルド、リリースの変更、またはパイプラインを再実行または再展開 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 変更要求の再利用可能性決定サブフロー」を使用して、以前の変更要求を再利用するか、新しい変更要求を作成するかを選択できます。このサブフローのデフォルト実装では、変更要求が実装後または実装後ステータスの場合、前回の試行からの変更要求を再利用できます。変更要求がその他のステータスの場合、 デフォルトでは、ジョブを再実行すると新しい変更要求が作成されます。既存の動作ごとに、テストサマリーやスキャンなどの関連するすべての詳細が新たに生成されますが、コミットと作業アイテムは新しい変更要求に対して変更されずに保持されます。
たとえば、変更要求が承認された後の特定のステージでパイプラインが失敗し、そのステージを再実行した場合などです。変更要求が再利用され、関連付けられたテストサマリーとソフトウェア品質スキャン、およびアーティファクトに関連付けられたコミットと作業アイテムが、承認した同じ変更要求に関連付けられます。
再利用性のためにカスタムロジックを適用するには、既存のサブフローをコピーして変更し、公開して、新しいサブフロー名を更新します。 .
通常のベースシステムフローでは、変更が作成されると、変更要求に対する決定が行われた後に、「DevOpsフローのカスタマイズ」を使用してステップ実行レコードの Stateフィールドが更新されます。ただし、変更を再利用する場合、作成される変更要求の最初のトリガー条件は満たされません。ジョブの再実行時に変更要求が再利用されるたびに、「DevOps 変更要求の再利用可能性モデルサブフロー」 ベースシステムサブフローがトリガーされます。このサブフローのデフォルト実装は、 DevOps モデル変更要求フローに似ています。でカスタムサブフローを作成し、サブフロー名を更新できます .
パイプライン UI の変更
- カードをクリックすると、そのステージの最新の試行が表示されます。
- [ すべての試行を表示 ] リンクをクリックすると、複数回実行されるステップまたはステージに関連するすべてのステップ実行と関連情報が表示されます。
- [変更を表示] リンクには、最新の試行に関連付けられた変更要求が表示されます。