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

Pipeline Declarative post unsuccessful block

    Details

    • Similar Issues:

      Description

      In my declarative pipeline I need to repeat the same step in the unstable, failure, and aborted post conditions, e.g.

      post {
        always {
          // do some stuff to collect junit reports
        }
        success {
          // push the tags
        }
        unstable {
          sh "mvn nexus-staging:drop"
        }
        failure {
          sh "mvn nexus-staging:drop"
        }
        aborted {
          sh "mvn nexus-staging:drop"
        }
      }

      This is really crappy having to repeat the exact same tidy-up in three places.

      What I'd really like is something like:

      post {
        always {
          // do some stuff to collect junit reports
        }
        success {
          // push the tags
        }
        unsuccessful {
          sh "mvn nexus-staging:drop"
        }
      }

      Where the unsuccessful steps would run at the end. The sequence of execution would thus be:

      • always (first because it might affect the build result)
      • success (the result cannot get better, so none of the following blocks can turn the result to a success)
      • unstable (because we might have some steps that escalate the unstable to a failure, or get aborted because they take too long)
      • failure (once the result is failure, it cannot get better)
      • aborted (the failure block could be aborted)
      • unsuccessful (a catch-all for any of the previous error modes)

      With perhaps a finally condition at the end that always runs

        Attachments

          Issue Links

            Activity

            Hide
            reinholdfuereder Reinhold Füreder added a comment -

            In the meantime there are also:

            • "cleanup", which is presumably the suggested "finally" ("Always run after all other conditions, regardless of build status")
            • "regression, but this will not be run anymore if it keeps to be unsuccessful ("Run if the current builds status is worse than the previous builds status")

            However, I was also looking for an "unsuccessful" to be able to notify for broken build (a) independent of "unstable"/"failure"/"aborted" and (b) also keep notifying if it is still broken (so not just on first broken build, which would be supported by "regression")

            A little bit related sounds JENKINS-53889?

            An alternative approach that I guess might also be not easy to support could be a let's call it "multi-<something>":

            post {
              always {
                // do some stuff to collect junit reports
              }
              success {
                // push the tags
              }
              unstable|failure|aborted {
                sh "mvn nexus-staging:drop"
              }
            }

             

            => So agreeing with Stephen Connolly, maybe the "unsuccessful" might be the easiest to implement and use!?

            Show
            reinholdfuereder Reinhold Füreder added a comment - In the meantime there are also: "cleanup", which is presumably the suggested "finally" (" Always run after all other conditions, regardless of build status ") "regression, but this will not be run anymore if it keeps to be unsuccessful (" Run if the current builds status is worse than the previous builds status ") However, I was also looking for an "unsuccessful" to be able to notify for broken build (a) independent of "unstable"/"failure"/"aborted" and (b) also keep notifying if it is still broken (so not just on first broken build, which would be supported by "regression") A little bit related sounds JENKINS-53889 ? An alternative approach that I guess might also be not easy to support could be a let's call it "multi-<something>": post { always { // do some stuff to collect junit reports } success { // push the tags } unstable|failure|aborted { sh "mvn nexus-staging:drop" } }   => So agreeing with Stephen Connolly , maybe the "unsuccessful" might be the easiest to implement and use !?
            Hide
            abayer Andrew Bayer added a comment -

            Yeah, a condition that fires whenever the status is not SUCCESS or null seems reasonable.

            Show
            abayer Andrew Bayer added a comment - Yeah, a condition that fires whenever the status is not SUCCESS or null seems reasonable.
            Hide
            abayer Andrew Bayer added a comment -

            This'll be in 1.3.4.

            Show
            abayer Andrew Bayer added a comment - This'll be in 1.3.4.
            Hide
            reinholdfuereder Reinhold Füreder added a comment -

            Thanks Jose Blas Camacho Taboada and Andrew Bayer: this was very quick!

            Show
            reinholdfuereder Reinhold Füreder added a comment - Thanks Jose Blas Camacho Taboada and Andrew Bayer : this was very quick!
            Hide
            jorhett Jo Rhett added a comment -

            It would be really awesome if the documentation at https://jenkins.io/doc/book/pipeline/syntax/#post-conditions mentioned which states unsuccessful includes, so that we don't have to search to find this issue

            Show
            jorhett Jo Rhett added a comment - It would be really awesome if the documentation at  https://jenkins.io/doc/book/pipeline/syntax/#post-conditions  mentioned which states unsuccessful includes, so that we don't have to search to find this issue
            Hide
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

            Show
            bitwiseman Liam Newman added a comment - Bulk closing resolved issues.

              People

              • Assignee:
                jtaboada Jose Blas Camacho Taboada
                Reporter:
                stephenconnolly Stephen Connolly
              • Votes:
                2 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: