Post stages currently have a defined order in which they run. This limits certain use cases (especially in regards to clean up procedures). It would be nice to be able to specify certain post stages have to run before others.

      Jenkinsfile
      pipeline {
        agent { label 'label' }
        stages {
          stage('stage') {     
            steps {
              echo "stage"
            }
            post {
              success {
                echo "Success"
              }
              always {
                  echo "Always"
                  //deleteDir()
              }
            }
          }
        }
      }
      
      [Pipeline] {
      [Pipeline] stage
      [Pipeline] { (stage)
      [Pipeline] echo
      stage
      [Pipeline] echo
      Post stage
      [Pipeline] echo
      Always
      [Pipeline] echo
      Success
      [Pipeline] }
      [Pipeline] // stage
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      

      In the example Jenkinsfile, I want success to run before always. In my production use case, I want to stash some artifacts for a future stage. The future stage is set up to run on certain conditions, so clean up cannot be delayed.

      How order should be determined is open ended. To me, running in the Jenkinsfile order is more intuitive for a user, but there may be cases where you want to change that.

          [JENKINS-41519] Post stages should have well defined order

          Andrew Bayer added a comment -

          I think I have something that may help with this over in a PR for JENKINS-41239 - a new post condition, currently called cleanup (because I couldn't call it finally due to that being a reserved word in Groovy), which is like always (as in it'll run regardless of build status), but it runs after all other post conditions. So with this, always is the first post condition to run, and cleanup is the last, regardless of build status. So you can do things like deleteDir() etc in cleanup without problems.

          Does that sound like it'd do the trick here?

          Andrew Bayer added a comment - I think I have something that may help with this over in a PR for JENKINS-41239 - a new post condition, currently called cleanup (because I couldn't call it finally due to that being a reserved word in Groovy), which is like always (as in it'll run regardless of build status), but it runs after all other post conditions. So with this, always is the first post condition to run, and cleanup is the last, regardless of build status. So you can do things like deleteDir() etc in cleanup without problems. Does that sound like it'd do the trick here?

          abayer +1 for the cleanup condition, would solve this issue for us since we mostly want to delete workspace

          Stefan Thurnherr added a comment - abayer +1 for the cleanup condition, would solve this issue for us since we mostly want to delete workspace

          Eric Nelson added a comment -

          abayer +1 for cleanup here as well. Solves the issue in most use cases I had in mind.  Thanks! 

          Eric Nelson added a comment - abayer +1 for cleanup here as well. Solves the issue in most use cases I had in mind.  Thanks! 

          Caught by surprise with always not being the last one (it is sort of equivalent to the java finally which runs last, for the same cleanup reasons brought up in several JIRAs).  But cleanup would work around that (/me still prefers always being last).

          Do we have a JIRA for the 'cleanup' addition yet?  Could not find with JIRA search as the word is too common.

          Fernando Nasser added a comment - Caught by surprise with always not being the last one (it is sort of equivalent to the java finally which runs last, for the same cleanup reasons brought up in several JIRAs).  But cleanup would work around that (/me still prefers always being last). Do we have a JIRA for the 'cleanup' addition yet?  Could not find with JIRA search as the word is too common.

          fnasser Have you read the earlier comments in this jira issue? You'll find the jira issue for the 'cleanup' addition in Andrew's comment

          Stefan Thurnherr added a comment - fnasser Have you read the earlier comments in this jira issue? You'll find the jira issue for the 'cleanup' addition in Andrew's comment

          Thanks Stefan, not sure how I missed the JENKINS-41239 one.

           

          Fernando Nasser added a comment - Thanks Stefan, not sure how I missed the  JENKINS-41239 one.  

          Andrew Bayer added a comment -

          I think this is clear enough now. =)

          Andrew Bayer added a comment - I think this is clear enough now. =)

           is.  Many thanks for taking care of this Andrew.

          P.S.: Accordingly to JENKINS-41239  it has been released in Declarative 1.2.9.  But this Jira says fixed-but-unreleased...

           

          Fernando Nasser added a comment -  is.  Many thanks for taking care of this Andrew. P.S.: Accordingly to JENKINS-41239  it has been released in Declarative 1.2.9.  But this Jira says fixed-but-unreleased...  

          Andrew Bayer added a comment -

          Blech, our statuses are annoying. Fixing up.

          Andrew Bayer added a comment - Blech, our statuses are annoying. Fixing up.

          Liam Newman added a comment -

          Bulk closing resolved issues.

          Liam Newman added a comment - Bulk closing resolved issues.

            abayer Andrew Bayer
            rpocase Robby Pocase
            Votes:
            10 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: