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

FlowInterruptedException cause is not available in post condition

      With the use of declarative pipeline, it is impossible to add logic to a post condition to determine or perform logic on the cause of the failure. We only have access to the current build result.

      I am trying to differentiate when the build was interrupted because of a timeout from when a build was aborted for other reasons such as a manual intervention, an upstream or downstream build that was aborted, etc.

      I initially tried to use the build actions and the InterruptedBuildAction class, but it seems like this action won't be set when we are in the post conditions. The handle method https://github.com/jenkinsci/workflow-step-api-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/FlowInterruptedException.java seems to be called after the whole build. https://github.com/jenkinsci/workflow-job-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java#L604

      The only possible way I found to work around this problem is to convert to scripted pipeline and wrap the whole pipeline in a try/catch to catch FlowInterruptedException and perform the logic on it. Another way with declarative pipelines would be to use catchError and a try/catch inside each stage to set a global error variable that could be accessed in the post condition.

       

      Possible fix ideas:

      In the code below, I would like to be able to differentiate a DownstreamFailureCause from a TimeoutStepExecution$ExceededTimeout in the post condition.

      pipeline {
      options {
        timeout(time: 5, unit: 'SECONDS')
        skipDefaultCheckout()
      }
      
      agent { label 'master' }
          stages {
              stage("Build Failure or Timeout") {
                  steps {
                      script {
                          build(
                            job: 'failing-job',
                            parameters: [],
                            propagate: true,
                            wait: true
                          )
                      }
                  }
                  post {
                    unsuccessful {
                      script {
                          getInterruptionCause(currentBuild)
                      }
                    }
                  }
              }
          }
      }
      
      def getInterruptionCause(def build)
      {
        def directCause = null
      
        def rawBuild = build
        if (build instanceof org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper) {
          rawBuild = build.getRawBuild()
        }
      
        def actions = rawBuild.getActions(jenkins.model.InterruptedBuildAction)
        for (action in actions) {
          def causes = action.getCauses()
          for (cause in causes) {
      
            // Print the causes and their root causes BFS style.
            println "Interruption Cause: " + cause.getShortDescription()
            directCause = cause
      
            // Received when the upstream build was cancelled.
            if(cause instanceof org.jenkinsci.plugins.workflow.support.steps.build.BuildTriggerCancelledCause) {
              def upstreamCause = build.getCause(hudson.model.Cause$UpstreamCause)
              if (upstreamCause) {
                getInterruptionCause(upstreamCause.getUpstreamRun())
              }
            }
      
            // Received when a job triggered a build that failed with propagate: true.
            if(cause instanceof org.jenkinsci.plugins.workflow.support.steps.build.DownstreamFailureCause) {
              getInterruptionCause(cause.getDownstreamBuild())
            }
          }
        }
      
        return directCause
      }
      

          [JENKINS-62257] FlowInterruptedException cause is not available in post condition

          Alexandre Gaudreault added a comment - - edited

          The "cleanest" workaround I found is to define a method and wrap the script closure in it. This seems to work so far. I have this defined as `vars/interruptibleScript.groovy` in my pipeline library.

          /**
          * interruptibleScript seamlessly catch FlowInterruptionException and handles them so the InterruptedBuildAction is available in the post conditions
          *
          * TimeoutStepExecution$ExceededTimeout and DownstreamFailureCause will never be available in the post conditions otherwise.
          *
          * Required until there is a fix for https://issues.jenkins-ci.org/browse/JENKINS-62257
          *
          * Examples:
             stage('Build') {
               steps {
                 script {
                   interruptibleScript {
                     // Any code here
                   }
                 }
               }
             }
          * Parameters:
          *
          * @param script (Required, Closure) The code to execute.
          *
          * @category step
          * */
          
          def call(Closure script) {
            Exception caught = null
          
            // Keep the status to SUCCESS/SUCCESS. A FlowInterruptionException will update them based on the CauseOfInterruption.
            catchError(buildResult: 'SUCCESS', stageResult: 'SUCCESS', catchInterruptions: true) {
              try {
                script.call()
              } catch (Exception ex) {
                // Save the error in memory and let catchError handle it correctly
                caught = ex
                throw ex;
              }
            }
          
            // rethrow the initial error like nothing happened.
            if (caught) {
              throw caught;
            }
          }
          

          Alexandre Gaudreault added a comment - - edited The "cleanest" workaround I found is to define a method and wrap the script closure in it. This seems to work so far. I have this defined as `vars/interruptibleScript.groovy` in my pipeline library. /** * interruptibleScript seamlessly catch FlowInterruptionException and handles them so the InterruptedBuildAction is available in the post conditions * * TimeoutStepExecution$ExceededTimeout and DownstreamFailureCause will never be available in the post conditions otherwise. * * Required until there is a fix for https: //issues.jenkins-ci.org/browse/JENKINS-62257 * * Examples: stage( 'Build' ) { steps { script { interruptibleScript { // Any code here } } } } * Parameters: * * @param script (Required, Closure) The code to execute. * * @category step * */ def call(Closure script) { Exception caught = null // Keep the status to SUCCESS/SUCCESS. A FlowInterruptionException will update them based on the CauseOfInterruption. catchError(buildResult: 'SUCCESS' , stageResult: 'SUCCESS' , catchInterruptions: true ) { try { script.call() } catch (Exception ex) { // Save the error in memory and let catchError handle it correctly caught = ex throw ex; } } // rethrow the initial error like nothing happened. if (caught) { throw caught; } }

          Andrew added a comment -

          agaudreault thanks for this discussion. This is precisely what we're trying to do, too. Seems like it would be convenient to have a directive added to Jenkins. Something like this maybe?

          options {
              onTimeout myFunction
          }
          

           

          Andrew added a comment - agaudreault  thanks for this discussion. This is precisely what we're trying to do, too. Seems like it would be convenient to have a directive added to Jenkins. Something like this maybe? options {     onTimeout myFunction }  

          Alexandre Gaudreault added a comment - - edited

          I update my previous comment with the updated code I am using. I have this defined as `vars/interruptibleScript.groovy` in my pipeline library.

          Alexandre Gaudreault added a comment - - edited I update my previous comment with the updated code I am using. I have this defined as `vars/interruptibleScript.groovy` in my pipeline library.

          Andrew added a comment -

          Thanks for sharing the updated version!

          Andrew added a comment - Thanks for sharing the updated version!

          Please be careful with this interruptibleScript step. It can cause delays between steps in which it is used. We were able to see steps just idling in catchError instead of finishing. And this was not due to an exception or something else being handled.

          Daniel Steiert added a comment - Please be careful with this interruptibleScript step. It can cause delays between steps in which it is used. We were able to see steps just idling in catchError instead of finishing. And this was not due to an exception or something else being handled.

            Unassigned Unassigned
            agaudreault Alexandre Gaudreault
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: