I think this issues is a valid improvement request. The default behavior of node() cannot be changed of course, but it may be potentially doable via additional Pipeline closures or additional node closure parameters
No such feature exists for any other job type, and in general it is not a good idea. You could probably write a Pipeline library which implements it if you really wanted. Of course simply wrapping everything in timeout would work.
From Jesse Glick: `ExecutorStepExecution.CancelledItemListener` could check `User.current` and if not null, print a message indicating what user cancelled the item, thus resulting in the build failure. Not sure it would help anything, but would at least be very easy to implement!
We are facing this issue currently on our builds as well on occasion as we migrate jobs from one jenkins server to another which is accompanied with associated node relabeling and addition of new nodes. What I thought made sense was if the timeout could be applied to the pipeline as a whole and not just a step.
This option is a high valuable option for organizations using a main jenkins server handling jobs for various development and integration groups.
this way, a job waiting for execution would be automatically removed from the build queue after a pre-defined time for machine provisioning and the built queue will stay "clean". a notification with the reason should also be viewable in the console output of the execution (though it was not executed at all...).
I wonder why this is still not yet implemented. This clogged our whole build-pipeline over the weekend because one agent was down, which was needed for specific tests.
I totally agree with Marcus Schulmann, sometimes there is a uniqe agent (with specific hardware, for instance) used for tests. I wonder what can we do in order to bump this issue's importance and handling?