Execution sequence and waiting logic for rerun jobs

  • Release version: Yokohama
  • 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 and execution sequence differences when rerunning jobs in ServiceNow DevOps, specifically regarding change requests and pipeline stages. It highlights how rerun logic varies depending on whether a change request is reused or newly created during rerun attempts, with emphasis on handling parallel stages and synchronization with Azure DevOps pipelines.

    Show full answer Show less

    Existing Considerations

    • A change request must not reside in a stage containing 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 mirror the Azure DevOps pipeline UI order, while build pipelines display parallel stages serially.

    Upgrade Considerations

    • The initial pipeline run behavior remains unchanged post-upgrade, with sequential stage processing and proper execution of tests, scans, and change requests.
    • Rerun attempts and failed events from before the upgrade are ignored; therefore, it is recommended to run a new pipeline after upgrading if reruns were previously performed.
    • If the pipeline was run only once before upgrade, rerun functionality behaves as designed and is recorded in ServiceNow DevOps.

    Execution Sequence and Processing Logic

    • Artifact version registration calls received during reruns are ignored if they match previous calls; however, new package registrations with the same package name are created during reruns.
    • Artifacts linked to the latest package appear on the change request.
    • In build pipelines, rerunning a stage from the Azure DevOps GUI triggers reruns of subsequent stages in the defined sequence.
    • If a pipeline rerun is initiated before the previous attempt completes, the new attempt waits until all prior events are processed.
    • Release pipelines run stages sequentially only during the first attempt; subsequent reruns require manual stage execution and process events sequentially regardless of parallelism in Azure DevOps.
    • When a new change request is created for a rerun stage that includes tests and software quality scans, only the latest results are shown in the change request related list.
    • When reusing a change request for a rerun stage, results from all attempts are displayed in the 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.