-
Bug
-
Resolution: Fixed
-
Major
-
None
The Javadoc says
Enumerates active running StepExecution s in the system.
It is not specified exactly what "active" or "running" mean in this context, but at any rate I have found that StepExecutionIteratorImpl only includes innermost steps, not their containing block steps, because it calls FlowExecution.getCurrentExecutions which is documented to behave that way.
This means that it is impossible to find a StepExecution of a block-scoped step unless it is not currently running its body. (Before or after running the body, it seems to work.) If this behavior is intentional, it needs to be documented more clearly, and I would request some way to get even enclosing executions.
- is blocking
-
JENKINS-25570 Wait-for-condition step
-
- Resolved
-
-
-
- Resolved
-
- is related to
-
-
- Resolved
-
-
-
- Closed
-
- links to
[JENKINS-26163] StepExecutionIterator omits outer executions
Alternately it would suffice to have something @CheckForNull StepExecution StepExecution.getParent() that would return an enclosing step if there is one.
Code changed in jenkins
User: Jesse Glick
Path:
CHANGES.md
http://jenkins-ci.org/commit/workflow-plugin/20af35a04a92c839f0289ce339f1667167c8c4c6
Log:
JENKINS-26163 Noting internal bug as well as known user-visible effects.
Code changed in jenkins
User: Jesse Glick
Path:
CHANGES.md
aggregator/src/test/java/org/jenkinsci/plugins/workflow/CpsFlowExecutionTest.java
aggregator/src/test/java/org/jenkinsci/plugins/workflow/DynamicEnvironmentExpanderTest.java
aggregator/src/test/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepTest.java
aggregator/src/test/java/org/jenkinsci/plugins/workflow/steps/WaitForConditionStepTest.java
api/src/main/java/org/jenkinsci/plugins/workflow/flow/FlowExecution.java
api/src/main/java/org/jenkinsci/plugins/workflow/flow/FlowExecutionList.java
basic-steps/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java
basic-steps/src/main/java/org/jenkinsci/plugins/workflow/steps/RetryStepExecution.java
basic-steps/src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java
basic-steps/src/main/java/org/jenkinsci/plugins/workflow/steps/WaitForConditionStep.java
cps/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java
cps/src/main/java/org/jenkinsci/plugins/workflow/cps/steps/LoadStepExecution.java
step-api/src/main/java/org/jenkinsci/plugins/workflow/steps/AbstractStepExecutionImpl.java
http://jenkins-ci.org/commit/workflow-plugin/fb3e89a3126665cb909b4113f41a306c0fb56380
Log:
Merge pull request #161 from jenkinsci/StepExecutionIterator-JENKINS-26163
JENKINS-26163 Fixed handling of AbstractStepExecutionImpl.onResume
Compare: https://github.com/jenkinsci/workflow-plugin/compare/fe932961dc7b...fb3e89a31266
Code changed in jenkins
User: Jesse Glick
Path:
aggregator/src/test/java/org/jenkinsci/plugins/workflow/DynamicEnvironmentExpanderTest.java
http://jenkins-ci.org/commit/workflow-job-plugin/913943e1d90807703813c579d61e3bb7436640e1
Log:
Merge pull request #161 from jenkinsci/StepExecutionIterator-JENKINS-26163
JENKINS-26163 Fixed handling of AbstractStepExecutionImpl.onResume
Originally-Committed-As: fb3e89a3126665cb909b4113f41a306c0fb56380
Currently blocking some tests of the waitUntil step: there is no reliable way to get a handle on the StepExecution from the test, since there is only a short period of time during which its body is not being run.
From the implementation of that step itself, this problem does not arise, since we only need to find the StepExecution (to work around the missing API noted in
JENKINS-26148) between body invocations.