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

Add optional 'timeout' parameter to 'input' step

      An optional 'timeout' parameter for the 'input' pipeline step would be very nice. In case of no response within specified amount of time, the build would then fail. Or maybe even make that selectable: fail or continue.

          [JENKINS-36235] Add optional 'timeout' parameter to 'input' step

          Jesse Glick added a comment -

          Do not plan to accept the original RFE; should wrap with the timeout step. What harryjenkins was looking for is err.causes, which may be ExceededTimeout, Rejection, or something else like UserInterruption. Currently this is not accessible from a sandboxed script, which is a problem.

          Jesse Glick added a comment - Do not plan to accept the original RFE; should wrap with the timeout step. What harryjenkins was looking for is err.causes , which may be ExceededTimeout , Rejection , or something else like UserInterruption . Currently this is not accessible from a sandboxed script, which is a problem.

          Harry Mallon added a comment -

          jglick: err.causes returns a similar output to err.getCauses(). Both return org.jenkinsci.plugins.workflow.support.steps.input.Rejection@53ed4813 for timeout and abort. I have never seen an Exceeded Timeout cause.

          Harry Mallon added a comment - jglick : err.causes returns a similar output to err.getCauses(). Both return org.jenkinsci.plugins.workflow.support.steps.input.Rejection@53ed4813 for timeout and abort. I have never seen an Exceeded Timeout cause.

          Joost added a comment -

          Wrapping a timeout block around the input step works for me. Thanks!

          Joost added a comment - Wrapping a timeout block around the input step works for me. Thanks!

          Jason Miller added a comment -

          jrkoiter: Does this still work for you? I'm unable to get it working on my instance, using 2.7.2 and the latest pipeline plugins:

          timeout(5) {
            input "waiting..."
          }
          

          The timeout block doesn't seem to work - it just hangs on the input step indefinitely until it's either approved or aborted, just as if it weren't in a timeout block at all.
          If I remove the input step, the timeout works as expected, so it seems like timeout isn't being allowed to abort the input step correctly.

          Jason Miller added a comment - jrkoiter : Does this still work for you? I'm unable to get it working on my instance, using 2.7.2 and the latest pipeline plugins: timeout(5) { input "waiting..." } The timeout block doesn't seem to work - it just hangs on the input step indefinitely until it's either approved or aborted, just as if it weren't in a timeout block at all. If I remove the input step, the timeout works as expected, so it seems like timeout isn't being allowed to abort the input step correctly.

          Joost added a comment - - edited

          The documentation doesn't say what the default unit is. This is working for me:

          node {
              timeout(time: 10, unit: 'SECONDS') {
              input "waiting..."
              }
          }
          

          Joost added a comment - - edited The documentation doesn't say what the default unit is. This is working for me: node { timeout(time: 10, unit: 'SECONDS' ) { input "waiting..." } }

          Jesse Glick added a comment -

          stormtau perhaps you are seeing JENKINS-38380. Do not discuss it here please.

          Jesse Glick added a comment - stormtau perhaps you are seeing JENKINS-38380 . Do not discuss it here please.

          Jesse Glick added a comment -

          Both return org.jenkinsci.plugins.workflow.support.steps.input.Rejection@53ed4813 for timeout and abort.

          Seems like a bug in InputStepExecution.stop; should pass its Throwable on to onFailure rather than having doAbort construct a new FlowInterruptedException. (IOW, factor this code into a new method and revert the impersonate call from the fix of JENKINS-38380.) Could be fixed in conjunction with providing a sandbox-safe accessor for FlowInterruptedException.getCauses and defining an integration test.

          Jesse Glick added a comment - Both return org.jenkinsci.plugins.workflow.support.steps.input.Rejection@53ed4813 for timeout and abort. Seems like a bug in InputStepExecution.stop ; should pass its Throwable on to onFailure rather than having doAbort construct a new FlowInterruptedException . (IOW, factor this code into a new method and revert the impersonate call from the fix of JENKINS-38380 .) Could be fixed in conjunction with providing a sandbox-safe accessor for FlowInterruptedException.getCauses and defining an integration test.

          While in progress the [quite ugly] workaround is

                  long startTime = System.currentTimeMillis()
                  try {
                      timeout(time: timeoutInSeconds, unit: 'SECONDS') {
                          input 'Test'
                      }
                  } catch (err) {
                      long timePassed = System.currentTimeMillis() - startTime
                      if (timePassed >= timeoutInSeconds * 1000) {
                          echo 'Timed out'
                      } else {
                          throw err
                      }
                  }
          

          Vsevolod Kalinin added a comment - While in progress the [quite ugly] workaround is long startTime = System .currentTimeMillis() try { timeout(time: timeoutInSeconds, unit: 'SECONDS' ) { input 'Test' } } catch (err) { long timePassed = System .currentTimeMillis() - startTime if (timePassed >= timeoutInSeconds * 1000) { echo 'Timed out' } else { throw err } }

          Andrew Bayer added a comment -

          Yeah, the appropriate way to do this is

          timeout(5) {
            input ...
          }
          

          Andrew Bayer added a comment - Yeah, the appropriate way to do this is timeout(5) { input ... }

          Steve Todorov added a comment - - edited

          I really don't know why is this marked as "fixed/won't fix". I've opened another ticket about the same issue - https://issues.jenkins-ci.org/browse/JENKINS-56259 

          It would be really great if there was a parameter for the `input` step. You cannot wrap this in a `timeout` when you are using it at a `stage(){ input {} }` level in a declarative pipeline. 

          Steve Todorov added a comment - - edited I really don't know why is this marked as "fixed/won't fix". I've opened another ticket about the same issue - https://issues.jenkins-ci.org/browse/JENKINS-56259   It would be really great if there was a parameter for the `input` step. You cannot wrap this in a `timeout` when you are using it at a `stage(){ input {} }` level in a declarative pipeline. 

            Unassigned Unassigned
            jrkoiter Joost
            Votes:
            6 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated:
              Resolved: