Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63115

Inconsistent Parallel Stage Order

    Details

    • Similar Issues:

      Description

      When running pipeline job with parallel stages, the order of stages returned by the endpoint '/job/<jobname>/wfapi/runs' is inconsistent with the way the stages are created and displayed when completed. The ui is designed to display  runs from the newest to the oldest with stages provided in the same order. Therefore when parallel stages are used, the ui will almost always only display the last run.

       

      Attached screenshots will show :

      • Before running the job (Consistent Before Run.png), the order of stages of the completed runs allow to display all previous runs.
      • When running the job (Inconsistent During Run.png), the different order of stages of the running job discontinue the display of the previous runs.
      • After running the job (Consistent After Run.png), the order of stages of the newly completed run follows its natural creation order and allow the ui to display the previous runs.

      The previous exemple was made with the script (parallelPipelineScriptTest.txt) attached and was tested on :

      • A Jenkins server version : 2.235.1 with the Pipeline plugin version 2.6 (containing plugin Pipeline: Stage View Plugin version 2.13)
      • A local development post with pipeline-stage-view-plugin, branch : master, current version : 2.14-SNAPSHOT. Some changes in pom.xml files had to be maid to create the pipeline, 'node' being not recognized in the goovy script with the vanilla dependencies provided by the poms, see changes in patchPoms.txt.

        Attachments

        1. Consistent After Run.png
          Consistent After Run.png
          330 kB
        2. Consistent Before Run.png
          Consistent Before Run.png
          306 kB
        3. Inconsistent During Run.png
          Inconsistent During Run.png
          220 kB
        4. parallelPipelineScriptTest.txt
          0.4 kB
        5. patchPoms.txt
          5 kB
        6. stages-order-on-blue-ocean.png
          stages-order-on-blue-ocean.png
          23 kB
        7. stages-order-on-console-log.png
          stages-order-on-console-log.png
          27 kB
        8. stages-order-on-stage-view.png
          stages-order-on-stage-view.png
          29 kB

          Activity

          Hide
          lsouchard Ludovic Souchard added a comment - - edited

          I have created the PR 88 to resolve the issue.

          Show
          lsouchard Ludovic Souchard added a comment - - edited I have created the PR  88  to resolve the issue.
          Hide
          agabrys Adam Gabryś added a comment -

          The merged PR doesn't solve the issue. If I understand the code correctly, stages are sorted depending on the nodes execution start up. When parallel stages require heavy nodes, the order is not always the same as the nodes requesting order. Some pods are created on slower machines and start up later. It causes that the order is invalid. I would suggest use the same approach which is used by BlueOcean - sort stages alphabetically. It guarantees that the order is always the same, no matter when the stages are started (nodes are allocated).

          Correct order:

          • BlueOcean:
          • Console Log:

          Incorrect order:

          • Stage View:
          Show
          agabrys Adam Gabryś added a comment - The merged PR doesn't solve the issue. If I understand the code correctly, stages are sorted depending on the nodes execution start up. When parallel stages require heavy nodes, the order is not always the same as the nodes requesting order. Some pods are created on slower machines and start up later. It causes that the order is invalid. I would suggest use the same approach which is used by BlueOcean - sort stages alphabetically. It guarantees that the order is always the same, no matter when the stages are started (nodes are allocated). Correct order: BlueOcean: Console Log: Incorrect order: Stage View:
          Hide
          lsouchard Ludovic Souchard added a comment -

          Well, it fixes it as long as Jenkins is not waiting to start the job... No, of course, I agree, the solution is too limited. I overlooked what I took from Nuh and I didn't have a proper environment to test when Jenkins or its nodes are busy.

           

          However, I disagree with the solution you suggested. Applying directly a lexicographical sorting would mess up the chronological order of serial stages. If we had the relations between the stages, we could apply that rule locally (event tho I still don't like it). Right now I don't see how to gather that data with the ChunkVisitor.

          Show
          lsouchard Ludovic Souchard added a comment - Well, it fixes it as long as Jenkins is not waiting to start the job... No, of course, I agree, the solution is too limited. I overlooked what I took from Nuh and I didn't have a proper environment to test when Jenkins or its nodes are busy.   However, I disagree with the solution you suggested. Applying directly a lexicographical sorting would mess up the chronological order of serial stages. If we had the relations between the stages, we could apply that rule locally (event tho I still don't like it). Right now I don't see how to gather that data with the ChunkVisitor.

            People

            • Assignee:
              svanoort Sam Van Oort
              Reporter:
              lsouchard Ludovic Souchard
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: