-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
Jenkins 1.651.1, up-to-date pipeline and workflow plugins (list attached), IBM JRE 1.7.0, Linux
Pipeline/ workflow DSL: timeout() does not work as expected when a withEnv() is introduced inside the (same) timeout + node blocks and over the (same) shell command.
Specifically, without the withEnv block, the timeout actually interrupts the shell command.
With the withEnv block, the timeout does not interrupt the shell command; yet, the build still ends reporting that it was interrupted/ aborted.
- is duplicated by
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
-
- Closed
-
-
JENKINS-39072 timeout step should include more logging/diagnostics information
-
- Resolved
-
- links to
[JENKINS-34637] pipeline DSL: timeout() does not work if withEnv() is enclosed
Confirmed with code below for another example without "withEnv".
def disableClusterRoutingAllocation(node){
timeout(time: 10, unit: "SECONDS"){
waitUntil{
try {
sh "curl -XPUT -sS http://$node/_cluster/settings -d '{ \"transient\" : { \"cluster.routing.allocation.enable\" : \"none\" } }' | grep \"acknowledged\":true"
return true
} catch(exception){
return false
}
}
}
}
Domingo K
added a comment - - edited Confirmed with code below for another example without "withEnv".
def disableClusterRoutingAllocation(node){
timeout(time: 10, unit: "SECONDS" ){
waitUntil{
try {
sh "curl -XPUT -sS http: //$node/_cluster/settings -d '{ \" transient \ " : { \" cluster.routing.allocation.enable\ " : \" none\ " } }' | grep \" acknowledged\ ": true "
return true
} catch (exception){
return false
}
}
}
}
Yes the bug is not in timeout or withEnv, it is more general. I am working on it.
Steve Prentice
added a comment - Not sure if this is a different issue or another manifestation of the issue with CpsBodyExecution, but passing a submitter into input is enough to trigger this issue with timeout for me.
timeout(time: 3, unit: 'SECONDS') { // input will hang forever. input submitter: 'user' }
timeout(time: 3, unit: 'SECONDS') { // will timeout as expected input() }
If this is a different issue, let me know and I'll submit a new issue.
Steve Prentice
added a comment - Not sure if this is a different issue or another manifestation of the issue with CpsBodyExecution , but passing a submitter into input is enough to trigger this issue with timeout for me.
timeout(time: 3, unit: 'SECONDS' ) {
// input will hang forever.
input submitter: 'user'
}
timeout(time: 3, unit: 'SECONDS' ) {
// will timeout as expected
input()
}
If this is a different issue, let me know and I'll submit a new issue. Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/workflow/cps/CpsBodyExecution.java
src/main/java/org/jenkinsci/plugins/workflow/cps/CpsStepContext.java
src/test/java/org/jenkinsci/plugins/workflow/cps/CpsBodyExecutionTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/6933a4925a47b07206eaf059484b37c069aebe62
Log:
[FIXED JENKINS-34637] CpsBodyExecution.cancel was failing to interrupt the innermost execution, and block-scoped StepExecution.stop does not generally kill its body (JENKINS-26148).
getCurrentExecutions was also in direct violation of its Javadoc, though it does not appear to have ever been called, much less tested.
Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/workflow/cps/CpsBodyExecution.java
src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowDefinition.java
src/main/java/org/jenkinsci/plugins/workflow/cps/CpsStepContext.java
src/main/java/org/jenkinsci/plugins/workflow/cps/CpsThread.java
src/main/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStep.java
src/test/java/org/jenkinsci/plugins/workflow/cps/CpsBodyExecutionTest.java
src/test/java/org/jenkinsci/plugins/workflow/cps/CpsThreadDumpTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/bee2879e1e133bc05d3f127b7221a08529fdcb1e
Log:
Merge pull request #76 from jglick/timeout-block-JENKINS-34637
JENKINS-34637 Failure to kill bodies from timeout
Compare: https://github.com/jenkinsci/workflow-cps-plugin/compare/b5c8ca8c7118...bee2879e1e13
Code changed in jenkins
User: Christopher Orr
Path:
src/test/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepRunTest.java
http://jenkins-ci.org/commit/workflow-basic-steps-plugin/55488ff554d7edfd966b73ee11b35c4ab2d8811b
Log:
Add test case to reproduce JENKINS-34637.
Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/test/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepRunTest.java
http://jenkins-ci.org/commit/workflow-basic-steps-plugin/ae8b586e824294f687ebdf40cadddff599c597bc
Log:
JENKINS-34637 Verifying behavior of timeout step around other block-scoped steps.
Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java
src/test/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepRunTest.java
http://jenkins-ci.org/commit/workflow-basic-steps-plugin/5d2b2327b7ae5daec98bf747520c2960c8685f0c
Log:
Merge pull request #24 from jglick/timeout-block-JENKINS-34637
JENKINS-34637 Test for timeout bug
Compare: https://github.com/jenkinsci/workflow-basic-steps-plugin/compare/f541cd2cda5f...5d2b2327b7ae
Indeed the problem is in CpsBodyExecution, not timeout.