-
Bug
-
Resolution: Duplicate
-
Minor
Desired behaviour
- Duration should be 20s for the whole pipeline.
- ed1 node duration should be 20s
- ed2 node duration should be 10s
Undesired behaviour
- Duration should be 20s for the whole pipeline.
- ed1 node duration should be 20s
- ed2 node duration should be 10s but is reported as 20s
Example
def map = [:] map['ed1'] = { node() { sleep 20 } } map['ed2'] = { node() { sleep 10 } } stage('Stage 1') { parallel map }
Original request
Hi,
the execution time of a stage containing two parallel jobs shows, after the first job has finished, only the execution time of the first job, as long as the second job is running.
After the second job has finished, the displayed time is updated to the right runtime.
It would be nice if the time could be right during the execution of the job as well.
- blocks
-
-
- Closed
-
- duplicates
-
-
- Open
-
- is blocked by
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
- relates to
-
JENKINS-43746 Update step heading to include selected parallel and live duration
-
- Closed
-
- links to
[JENKINS-38536] Execution time of parallel blocks of in-flight jobs wrong
Cornelius Riemenschneider
created issue -
Sam Van Oort
made changes -
| Component/s | New: pipeline-graph-analysis-plugin [ 21693 ] | |
| Component/s | Original: pipeline-stage-view-plugin [ 21139 ] |
Sam Van Oort
made changes -
| Component/s | New: pipeline-stage-view-plugin [ 21139 ] |
Sam Van Oort
made changes -
| Priority | Original: Minor [ 4 ] | New: Major [ 3 ] |
Sam Van Oort
made changes -
| Component/s | New: workflow-api-plugin [ 21711 ] | |
| Component/s | Original: pipeline-graph-analysis-plugin [ 21693 ] |
Sam Van Oort
made changes -
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Code changed in jenkins
User: Sam Van Oort
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/workflow/graphanalysis/ForkScanner.java
src/test/java/org/jenkinsci/plugins/workflow/graphanalysis/ForkScannerTest.java
http://jenkins-ci.org/commit/workflow-api-plugin/2ac612a4de00f0cf26bcad66bd2fd3a6eb5c120e
Log:
Test and fix for wrong order for in-progress parallels JENKINS-38536
Sam Van Oort
made changes -
| Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
| Link |
New:
This issue blocks |
cri You are correct, I have reproduced this. It appears we have a small bug with the handling of partially-completed parallels: we explore branches in order of declaration (the next update to workflow-api reverses this behavior to be consistent with the order of iteration).
Dense implementation details following:
I think the fix is a subtle one in the workflow-api visitSimpleChunk method (which stage view consumes downstream) or in stage view itself: for the last stage, if there are multiple heads (currently in-scope nominally running FlowNodes, i.e. branches of a parallel), set the last node to whichever of the nodes is really still executing (not just the BlockEndNode denoting the end of the parallel). Then status & timing computations for the stage will use the right end node and return correct timing.