Restarting failed build or release pipeline jobs and stages
Summarize
Summary of Restarting failed build or release pipeline jobs and stages
This functionality in ServiceNow DevOps allows customers to rerun failed or canceled Azure DevOps build or release pipelines, stages, or specific jobs without creating new pipeline executions. Instead, reruns are treated as continuous attempts within the same pipeline execution, simplifying tracking and management of pipeline retries.
Show less
Key Features
- Rerun Options: Customers can rerun entire pipelines or specific failed or canceled jobs and stages within the same execution context.
- Attempt Tracking: An
attemptNumberparameter in the payload helps track each rerun attempt, ensuring associated test summaries, software quality scan results, commits, and work items are updated accordingly. - Change Request Reusability: When rerunning change-enabled jobs, customers can choose to reuse a previous change request if it is in implement or post-implement states, or create a new one. This behavior is governed by the base system subflow DevOps Change Request Reusability Decision Subflow, which can be customized to apply different reuse logic.
- Customizable Subflows: Customers can customize the change request reuse logic and related state management by copying and modifying the provided subflows (DevOps Change Request Reusability Decision Subflow and DevOps Change Request Reusability Model Subflow), then updating these in DevOps Properties.
- Pipeline UI Enhancements: The DevOps pipeline UI now reflects rerun attempts as continuous runs under the same pipeline execution. Customers can view the latest attempt details, all attempts for a step or stage, and associated change requests directly from the UI.
Practical Considerations
- When using Azure Invoke REST API for change control configuration, include the
attemptNumberparameter correctly in the payload to enable proper tracking of rerun attempts. - Do not rely on existing started and completed notifications for stage jobs if rerun functionality is required, as these notifications can interfere with rerun processing.
- Reusing change requests means test summaries and scan results are regenerated while commits and work items remain unchanged, preserving development traceability.
Benefits
This rerun capability streamlines pipeline failure recovery by reducing redundant pipeline executions and improving visibility into rerun attempts and their associated change requests and artifacts. ServiceNow customers gain enhanced control over build and release processes, with flexible change request management and comprehensive UI insights, facilitating efficient DevOps workflows.
Rerun or redeploy Azure DevOps build, release changes, or pipelines that are failed or canceled in that stage or pipeline. The reattempts display on the DevOps pipeline UI as continuous runs instead of creating new executions.
Rerun Azure DevOps pipelines or stages
You can rerun a failed or canceled build or release pipelines or change jobs in Azure DevOps. The reruns are processed as part of the same pipeline execution as the first run in ServiceNow DevOps. You can rerun entire pipelines or specific failed or canceled jobs and stages. You can now choose to reuse a change request instead of creating a new change request each time you restart a stage or a pipeline.
An attemptNumber parameter is added to the payload which helps us track reruns. Associated test summary, software quality scan results, commits, work items corresponding to every rerun attempt is also updated in ServiceNow DevOps.
If you are using the Configuring change control using the Azure Invoke REST API you must add the attempt number parameter to your payload body in the specified syntax format for build and release pipelines. If you do not specify the attempt number parameter, the default attempt number is set to 1.
"attemptNumber": "$(system.jobAttempt)""attemptNumber": "$(Release.AttemptNumber)"Reusing Change Requests
If a change enabled job is rerun, and a change request exists for the previous run/attempt, you can choose to reuse the previous change request or create a new change request, using the base system ‘DevOps Change Request Reusability Decision Subflow’. The default implementation of this subflow, allows you to reuse a change request from the previous attempt if the change request is in implement, or post-implement states. If the Change request is in any other state, by default, a new change request is created when you rerun the job. Per existing behavior, all associated details such as test summaries, and scans, are newly generated while commits and work items are retained unchanged for new change requests.
For example, when a pipeline fails at a specific stage after the change request is approved, and you rerun that stage. The change request is reused, the associated test summary and software quality scans, and the commits and work items associated to the artifact are associated with the same change request which you approved.
To apply a custom logic for reusability, you can copy the existing subflow, make the changes, publish it, and update the new subflow name under .
In the regular base system flow when a change is created, ‘ Customizing DevOps flows’ is used to update the State field of step execution record after a decision is taken on the change request. However, when you reuse a change, the first trigger condition of a change request being created is not met. A base system subflow ‘DevOps Change Request Reusability Model Subflow’ is triggered instead, whenever a change request is reused when a job is a rerun. The default implementation of this subflow is similar to the DevOps Model Change Request flow. You can create a custom subflow and update the subflow name at .
Pipeline UI changes
- Click a card to view the latest attempt of that stage.
- Click the View all attempts link to see all the step executions and related information associated to the step or stage that is run more than once.
- The View change link displays the change request associated with the latest attempt.