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.

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.

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

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.

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

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

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

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
            }
        }

Yeah, the appropriate way to do this is

timeout(5) {
  input ...
}

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.