Execution sequence and waiting logic for rerun jobs

  • Release version: Xanadu
  • Updated July 31, 2025
  • 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 explains the processing sequence and waiting logic for rerun jobs in ServiceNow DevOps, specifically when reusing or creating change requests as part of rerun jobs. It highlights key considerations for both build and release pipelines, especially in relation to parallel stages, artifact registration, and change request handling during reruns.

    Show full answer Show less

    Existing Considerations

    • A change request must not be placed in a stage that contains parallel jobs.
    • If multiple stages run in parallel, a change request should not be the first job in both stages.
    • Parallel stages in release pipelines are processed and displayed in the pipeline UI as they appear in Azure DevOps.
    • Parallel stages in build pipelines run in parallel but are displayed serially in the UI.

    Upgrade Considerations

    • The initial pipeline run behavior and execution sequence remain unchanged after upgrading.
    • It is recommended to run a new pipeline after upgrading to ensure proper handling of rerun stages and pipelines.
    • Rerun attempts and failed events before upgrading are ignored and not reattempted by ServiceNow DevOps.
    • If the pipeline was run only once before upgrade, rerunning stages or the entire pipeline after upgrade works as designed and is tracked in ServiceNow DevOps.

    Execution Sequence and Processing Logic

    • If the same artifact version registration call is received during a rerun, it is ignored to prevent duplication.
    • Package registration calls with the same package name are not ignored; a new package is created for each rerun attempt, associating the latest artifacts with the change request.
    • In Azure DevOps build pipelines, rerunning a stage triggers reruns of subsequent stages in their defined order.
    • If a pipeline rerun is initiated before all stages from the previous run complete, the new attempt waits until the prior events finish processing.
    • For release pipelines, stages run sequentially only during the first run; from the second rerun attempt onward, stages must be manually rerun one by one.
    • Despite parallel execution in Azure DevOps release pipelines, rerun attempts process stages sequentially from the second attempt onward.

    Change Request and Test Results Handling

    • When a new change request is created for a rerun stage job that includes tests and software quality scans, only the latest test summary and scan results are shown in the change request related list.
    • If an existing change request is reused for a rerun stage job, test summaries and software quality scan results from each attempt are retained and displayed in the change request related list.

    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.