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

Add optional 'timeout' parameter to 'input' step

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            harryjenkins Harry Mallon added a comment -

            I have been trying to emulate the 'continue' mode in pipeline for a while. This is useful to us as I want to use a multibranch pipeline and want it to provide both user-started release builds and user or auto started testing builds. The best way to emulate this seems to be to give a user choice and fall through to default options (testing) on timeout. What follows is my current attempt and it doesn't work as I cannot tell the difference between a timeout and user pressed Abort.

            try {
                timeout(1) {
                    input message: 'Do you want to release this build?',
                          parameters: [[$class: 'BooleanParameterDefinition',
                                        defaultValue: false,
                                        description: 'Ticking this box will do a release',
                                        name: 'Release']]
                }
            } catch (err) {
                def hi = err.getCauses()
                echo "Exception thrown:\n ${hi}"
            
                echo err.getLocalizedMessage()
                echo err.getCause()
                echo err.toString()
                echo err.getClass().getName()
            }
            

            What I am saying is this seems to be a major missing part of pipeline for me, and is blocking me moving from the old style builds.

            Show
            harryjenkins Harry Mallon added a comment - I have been trying to emulate the 'continue' mode in pipeline for a while. This is useful to us as I want to use a multibranch pipeline and want it to provide both user-started release builds and user or auto started testing builds. The best way to emulate this seems to be to give a user choice and fall through to default options (testing) on timeout. What follows is my current attempt and it doesn't work as I cannot tell the difference between a timeout and user pressed Abort. try { timeout(1) { input message: 'Do you want to release this build?', parameters: [[$class: 'BooleanParameterDefinition', defaultValue: false, description: 'Ticking this box will do a release', name: 'Release']] } } catch (err) { def hi = err.getCauses() echo "Exception thrown:\n ${hi}" echo err.getLocalizedMessage() echo err.getCause() echo err.toString() echo err.getClass().getName() } What I am saying is this seems to be a major missing part of pipeline for me, and is blocking me moving from the old style builds.
            Hide
            jglick Jesse Glick added a comment -

            Do not plan to accept the original RFE; should wrap with the timeout step. What Harry Mallon 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.

            Show
            jglick Jesse Glick added a comment - Do not plan to accept the original RFE; should wrap with the timeout step. What Harry Mallon 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.
            Hide
            harryjenkins Harry Mallon added a comment -

            Jesse Glick: 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.

            Show
            harryjenkins Harry Mallon added a comment - Jesse Glick : 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.
            Hide
            jrkoiter Joost added a comment -

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

            Show
            jrkoiter Joost added a comment - Wrapping a timeout block around the input step works for me. Thanks!
            Hide
            stormtau Jason Miller added a comment -

            Joost: 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.

            Show
            stormtau Jason Miller added a comment - Joost : 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.
            Hide
            jrkoiter 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..."
                }
            }
            
            Show
            jrkoiter 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..." } }
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - Jason Miller perhaps you are seeing JENKINS-38380 . Do not discuss it here please.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            flash_1999 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
                        }
                    }
            
            Show
            flash_1999 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 } }
            Hide
            abayer Andrew Bayer added a comment -

            Yeah, the appropriate way to do this is

            timeout(5) {
              input ...
            }
            
            Show
            abayer Andrew Bayer added a comment - Yeah, the appropriate way to do this is timeout(5) { input ... }
            Hide
            stodorov 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. 

            Show
            stodorov 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. 

              People

              • Assignee:
                Unassigned
                Reporter:
                jrkoiter Joost
              • Votes:
                6 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: