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

Pipeline Declarative post unsuccessful block

    XMLWordPrintable

Details

    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

            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 stephenconnolly, maybe the "unsuccessful" might be the easiest to implement and use!?

            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 stephenconnolly , maybe the "unsuccessful" might be the easiest to implement and use !?
            abayer Andrew Bayer added a comment -

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

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

            This'll be in 1.3.4.

            abayer Andrew Bayer added a comment - This'll be in 1.3.4.

            Thanks jtaboada and abayer: this was very quick!

            reinholdfuereder Reinhold Füreder added a comment - Thanks jtaboada and abayer : this was very quick!
            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

            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
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

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

            People

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

              Dates

                Created:
                Updated:
                Resolved: