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

Declarative Pipeline Parallel Stages Post Events non-deterministic

      The Jenkins Declarative Pipeline is experiencing non-deterministic results when entering the post steps for parallel stages. For example, when an error is raised in one of two parallel stages and the other stage succeeds, but finish around the same time, then the successful stage executes the failure post stage, instead of the successful.

      stage("Parallel stages") {
          parallel {
              stage("Stage 1"){
                  agent none
                  steps {
                      script {
                          // sleep 10 // when sleeping long enough, stages behave correctly.
                          error("Which post step will get executed?")
                      }
                  }
                  post {
                      success {
                          echo "Stage 1 success!"
                      }
                      failure {
                          echo "Stage 1 failure!"
                      }
                  }
              }
              stage("Stage 2"){
                  agent none
                  steps {
                      script {
                          echo "Stage 2 code executing..."
                      }
                  }
                  post {
                      success {
                          echo "Stage 2 success!"
                      }
                      failure {
                          echo "Stage 2 failure!"
                      }
                  }
              }
          }
          post {
              success {
                  echo "Parallel post steps success!"
              }
              failure {
                  echo "Parallel post steps failure!"
              }
          }
      }

       

      So when Stage 1 has the sleep step commented out the results I see are:

      [Stage 1] Stage 1 failure!

      [Stage 2] Stage 2 failure!

      Parallel post steps failure!

       

      But when Stage 1 has the sleep step active, the results I see are:

      [Stage 1] Stage 1 failure!

      [Stage 2] Stage 2 success!

      Parallel post steps failure!

       

      I should expect the second scenario in all situations, right?

          [JENKINS-52114] Declarative Pipeline Parallel Stages Post Events non-deterministic

          Andrew Bayer added a comment -

          Regrettably, it actually is deterministic, it's just kinda crappy. =) The failure/success doesn't actually refer to failure/success of the individual stage, but of the build as a whole at the time that the post block is evaluated. So if stage 1 hasn't finished yet when stage 2 finishes, the build status is still success.

          This is, yes, annoying. There's an open ticket for better per-stage status tracking, and independent of that, I might be able to tweak the success condition specifically to be more stage-specific (though failure/unstable/aborted would still have to look at the overall build status). Will update once I have a chance to experiment.

          Andrew Bayer added a comment - Regrettably, it actually is deterministic, it's just kinda crappy. =) The failure/success doesn't actually refer to failure/success of the individual stage, but of the build as a whole at the time that the post block is evaluated. So if stage 1 hasn't finished yet when stage 2 finishes, the build status is still success. This is, yes, annoying. There's an open ticket for better per-stage status tracking, and independent of that, I might be able to tweak the success condition specifically to be more stage-specific (though failure/unstable/aborted would still have to look at the overall build status). Will update once I have a chance to experiment.

          Brandon Klos added a comment -

          I would expect that the post sections for each stage react independently of other concurrent stages. There is a post section for the parallel stages as a whole. The outer post section is where I would expect to see an error 100% of the time when a build failure occurs in either parallel stage.

          From my understanding the post stages are intended to perform some work that may be specific for the result of that stage. If I randomly have a stage execute the wrong post step, then I get unintentional (appearing non-deterministic) results.

          In either case, yes, this is annoying. In one other scenario, we sent a notification out saying two stages were marked as unstable. In the meantime, only one stage was unstable. Figuring out which it was, was kind of annoying.

          Brandon Klos added a comment - I would expect that the post sections for each stage react independently of other concurrent stages. There is a post section for the parallel stages as a whole. The outer post section is where I would expect to see an error 100% of the time when a build failure occurs in either parallel stage. From my understanding the post stages are intended to perform some work that may be specific for the result of that stage. If I randomly have a stage execute the wrong post step, then I get unintentional (appearing non-deterministic) results. In either case, yes, this is annoying. In one other scenario, we sent a notification out saying two stages were marked as unstable. In the meantime, only one stage was unstable. Figuring out which it was, was kind of annoying.

          Andrew Bayer added a comment -

          I may have a solution for this specifically for success and failure - unstable will still need JENKINS-39203, though, and there's no way I can have it fire failure if you do currentBuild.result = "FAILURE" in a stage and not fire failure for a successful parallel stage with a failing sibling, but hey.

          Andrew Bayer added a comment - I may have a solution for this specifically for success and failure - unstable will still need JENKINS-39203 , though, and there's no way I can have it fire failure if you do currentBuild.result = "FAILURE" in a stage and not fire failure for a successful parallel stage with a failing sibling, but hey.

          Andrew Bayer added a comment -

          Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/285

          Andrew Bayer added a comment -

          Ok, this change will be in 1.3.2, which is releasing momentarily!

          Andrew Bayer added a comment - Ok, this change will be in 1.3.2, which is releasing momentarily!

          Liam Newman added a comment -

          Bulk closing resolved issues.

          Liam Newman added a comment - Bulk closing resolved issues.

            abayer Andrew Bayer
            bklos Brandon Klos
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: