Execution sequence and waiting logic for rerun jobs

  • Release version: Australia
  • Updated March 12, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Execution Sequence and Waiting Logic for Rerun Jobs

    This document outlines the execution sequence and waiting logic for rerun jobs within ServiceNow DevOps, particularly focusing on how change requests are handled during rerun attempts in Azure DevOps pipelines.

    Show full answer Show less

    Key Features

    • Change Request Handling: Change requests should not exist in stages with parallel jobs, and they cannot be the first job in multiple parallel stages.
    • Execution Logic: During rerun attempts, existing calls for the same artifact version are ignored, but new packages associated with artifact versions can be created.
    • Sequential Processing: The first run of pipelines processes stages sequentially, while subsequent rerun attempts must wait for the completion of all previous events.
    • Test and Quality Scan Results: Only the latest results are shown on change requests for rerun stages, while all results are displayed when a change request is reused.

    Key Outcomes

    ServiceNow customers can expect that rerun attempts will follow a defined sequence, ensuring that all events are processed in order. This structured approach helps maintain clarity and integrity in the pipeline execution. Customers should be aware that after upgrading, they may need to rerun pipelines to capture new changes effectively, as previous failed attempts will not carry over. Understanding this logic enables customers to manage their pipelines more efficiently and effectively utilize the capabilities of ServiceNow DevOps.

    Processing sequence and waiting logic for rerun jobs are different when you reuse or create a change request as part of a rerun job.

    Existing Considerations

    • A change request should not exist in a stage which contains parallel jobs.
    • If more than one stage is running in parallel, change request should not be the first job in both the stages.
    Note:
    Parallel stages in release pipelines are processed and displayed in the pipeline UI as they occur in the Azure DevOps pipeline. Parallel stages in build pipelines are still processed in parallel but appear in a serial order in the pipeline UI.

    Upgrade Considerations

    There is no change in the functionality or execution when you run the first pipeline attempt. All stages are processed sequentially and associated tests, software quality scans and change requests are executed and created as modeled.
    Note:
    • Run a new pipeline after you upgrade if you have rerun stages and pipelines before upgrading. Rerun attempts and failed events prior to the upgrade are ignored by ServiceNow DevOps for reattempts.
    • If you have only run the pipeline once before upgrade, you can rerun the stage or the pipeline. The rerun functionality applies as designed and is saved in ServiceNow DevOps.

    Execution Sequence and processing logic

    • If the same artifact version registration call is received in reattempt, the registration call is ignored.
    • Package registration calls with same package name are not ignored. A new package associated to artifact versions and pipeline execution is created during reattempt. The artifacts that are associated to the latest package, will be shown on the change request.

    From the Azure DevOps GUI, if you rerun a stage in a build pipeline the subsequent stages reruns are also triggered in it's specified sequence. If you reattempt processing a pipeline before all the stages of the previous attempt are not complete. The subsequent attempt waits until all the events in the previous attempt are processed.

    For release pipelines, the stages are run in the specified sequence only during the first run. For subsequent rerun attempts manually run each stage. In release pipelines even if stages are running in parallel in Azure DevOps, from the second attempt onwards the events are processed in the specified sequence.

    • When a new change request is created for a reattempt stage job, and the stage that you are reattempting includes a test and a software quality scan only the latest Test Summary and Software Quality scan results display on the change request related list.
    • When a change request is reused for a rerun stage job, the Test Summary and Software Quality scan results for each attempt displays in the change request related list.