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

workflow-basic-steps: retry does not abort when input or milestone try to abort build

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • workflow-basic-steps-plugin
    • None
    • Jenkins 2.46.2 LTS
      workflow-basic-steps 2.4

      The 'retry' step was updated in 2.4 to handle exceptions correctly when a user aborts a build.

      However, when an 'input' step is included within the 'retry' block, clicking 'Abort' on the input prompt does not abort the build; the input prompt reappears, per the number of retries set.

      node('linux') {
    stage('one') {
        sleep 5
    }

    stage('two') {
        retry(3) {
            input 'proceed?'

            sleep 5
        }
    }
}

      This issue also occurs when a milestone step from a subsequent/newer build (user OKs the input for the pipeline to proceed) causes a FlowInterruptedException. The retry still catches this, and re-prompts the input:

      node('linux') {
    stage('one') {
        sleep 5
    }
    milestone()

    stage('two') {
        retry(3) {
            input 'proceed?'

            sleep 30
        }
    }
    milestone()

    stage('three') {
        sleep 5
    }
    milestone()
}

      Here's the relevant console log of build #8, which is waiting for input, when the input on build #9 is OKed:

      [Pipeline] input
proceed?
Proceed or Abort
Superseded by PIPELINE_retry-abort-test#9
[Pipeline] }
ERROR: Execution failed
org.jenkinsci.plugins.workflow.steps.FlowInterruptedException
	at org.jenkinsci.plugins.workflow.support.steps.input.InputStepExecution.doAbort(InputStepExecution.java:225)
	at org.jenkinsci.plugins.workflow.support.steps.input.InputStepExecution$1$1.run(InputStepExecution.java:97)
	at hudson.security.ACL.impersonate(ACL.java:243)
	at org.jenkinsci.plugins.workflow.support.steps.input.InputStepExecution$1.run(InputStepExecution.java:95)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Retrying
[Pipeline] {
[Pipeline] input
proceed?
Proceed or Abort
Click here to forcibly terminate running steps

          [JENKINS-44379] workflow-basic-steps: retry does not abort when input or milestone try to abort build

          Scott Russell added a comment -

          Here's an example of a workaround for implementing the desired logic without using the pipeline retry step:

          node('linux') {
    stage('one') {
        sleep 5
    }
    milestone()

    stage('two') {
        retrier(3) {
            input 'proceed?'
            sleep 5
        }
    }
    milestone()

    stage('three') {
        sleep 5
    }
    milestone()
}

def retrier(int retries, Closure body) {
    for(int i=0; i<retries; i++) {
        try {
            body.call()
            break
        } catch (org.jenkinsci.plugins.workflow.steps.FlowInterruptedException fie) {
            throw fie
        } catch (Exception e) {
            echo "${e}"
            continue
        }
    }
}

          Scott Russell added a comment - Here's an example of a workaround for implementing the desired logic without using the pipeline retry step: node( 'linux' ) { stage( 'one' ) { sleep 5 } milestone() stage( 'two' ) { retrier(3) { input 'proceed?' sleep 5 } } milestone() stage( 'three' ) { sleep 5 } milestone() } def retrier( int retries, Closure body) { for ( int i=0; i<retries; i++) { try { body.call() break } catch (org.jenkinsci.plugins.workflow.steps.FlowInterruptedException fie) { throw fie } catch (Exception e) { echo "${e}" continue } } }

          Jesse Glick added a comment -

          Yes arguably all FlowInterruptedException should be thrown up.

          Jesse Glick added a comment - Yes arguably all FlowInterruptedException should be thrown up.

          Andrew Bayer added a comment -

          PR up at https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/57 that changes retry to handle all FlowInterruptedException.

          Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/57 that changes retry to handle all FlowInterruptedException .

          SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          pom.xml
          src/main/java/org/jenkinsci/plugins/workflow/steps/RetryStepExecution.java
          src/test/java/org/jenkinsci/plugins/workflow/steps/RetryStepTest.java
          http://jenkins-ci.org/commit/workflow-basic-steps-plugin/bc294db775cdd854e3447a061111d375dcc90837
          Log:
          [FIXED JENKINS-44379] Don't retry for any FlowInterruptedException

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pom.xml src/main/java/org/jenkinsci/plugins/workflow/steps/RetryStepExecution.java src/test/java/org/jenkinsci/plugins/workflow/steps/RetryStepTest.java http://jenkins-ci.org/commit/workflow-basic-steps-plugin/bc294db775cdd854e3447a061111d375dcc90837 Log: [FIXED JENKINS-44379] Don't retry for any FlowInterruptedException

          Andrew Bayer added a comment -

          Fixed in the upcoming workflow-basic-steps 2.7 release.

          Andrew Bayer added a comment - Fixed in the upcoming workflow-basic-steps 2.7 release.

            abayer Andrew Bayer
            amundsenjunior Scott Russell
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: