-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.401.1
Pipeline Basic Steps 1017.vb_45b_302f0cea_
When a sh step, wrapped into a timeout step exits with code 0 when it receives a SIGTERM or SIGINTER signal, the job will continue to run and not abort.
I expected that when the timeout expires, the job terminates, independent from the exit code of the process that was terminated by the timeout.
This breaks the timeout functionality for processes that behaves badly (exit with wrong signal) or ignore the signal but terminate soon afterwards.
How to reproduce:
pipeline { agent any stages { stage("Test") { steps { timeout(time: 3, unit: 'SECONDS') { script { def rc = sh( script: '''#!/bin/bash trap 'exit 0' INT TERM while true; do echo "Sleeping..." sleep 1 done ''') } } echo "echo after TIMEOUT, job still running" } } } }
I believe this is a user misunderstanding or a gap in the documentation. When an sh step returns status, it is assumed that the Pipeline that called the sh step will set the job status based on that result.
The following abbreviated Pipeline shows the same:
Even though the shell step exits with a non-zero exit code, the Pipeline script continues to run because it is expected that the Pipeline script will decide if it should stop the Pipeline or continue.
If you are using returnStatus: true with the sh step, then I believe it is assumed that you'll also mark the job as unstable or failed as appropriate based on the status returned by the sh step.