Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
Jenkins: 2.32.2 LTS
Blue-ocean: 1.0.0-rc3
-
-
pipeline-graph-analysis 1.10
Description
Scope
- The aborted parallel branches should be marked as aborted.
- The failing branch should be marked as failed
- Ensure that only the failing branch is selected in the UI
Notes
Stepping through the code it looks like the aborted branches are marked as Result.ABORTED but this information is not bubbled up from bismuth. Aborted steps in this scenario are always reported as failed.
Original request
Using a pipeline job like:
pipeline {
agent any
stages {
stage ('parallel with failFast') {
steps {
parallel(
b: {
echo 'died'
sh "exit 1"
},
// make sure this branch takes longer than b
a: { sh "sleep 35"},
failFast: true
)
}
}
}
}
I would expect the failed step to be focused when entering the build page, instead the aborted branch and log is focused.
Also the aborted branch(es) should be visually different than the actual failed branch.
Technically more than one branch could fail before being aborted any any such branch should also be indicated as failed (like today).
I attached an examples of current and expected behavior of how I wish the build page would look for such a failed build. The aborted job indicator could of course be different, I just want it to stand out from an actual failed job.
Fixing this would significantly improve using massively parallel builds.
Data returned from Blue Ocean REST API
[
{
"_class":"io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl",
"_links":{
"self":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/6/"
},
"actions":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/6/actions/"
},
"steps":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/6/steps/"
}
},
"actions":[
],
"displayName":"parallel with failFast",
"durationInMillis":1025,
"id":"6",
"input":null,
"result":"FAILURE",
"startTime":"2017-04-04T14:44:32.809+1000",
"state":"FINISHED",
"causeOfBlockage":null,
"edges":[
{
"_class":"io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl$EdgeImpl",
"id":"10"
},
{
"_class":"io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl$EdgeImpl",
"id":"9"
}
]
},
{
"_class":"io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl",
"_links":{
"self":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/10/"
},
"actions":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/10/actions/"
},
"steps":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/10/steps/"
}
},
"actions":[
],
"displayName":"a",
"durationInMillis":1022,
"id":"10",
"input":null,
"result":"FAILURE",
"startTime":"2017-04-04T14:44:32.812+1000",
"state":"FINISHED",
"causeOfBlockage":null,
"edges":[
]
},
{
"_class":"io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl",
"_links":{
"self":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/9/"
},
"actions":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/9/actions/"
},
"steps":{
"_class":"io.jenkins.blueocean.rest.hal.Link",
"href":"/blue/rest/organizations/jenkins/pipelines/JENKINS-43292/runs/1/nodes/9/steps/"
}
},
"actions":[
],
"displayName":"b",
"durationInMillis":1024,
"id":"9",
"input":null,
"result":"FAILURE",
"startTime":"2017-04-04T14:44:32.810+1000",
"state":"FINISHED",
"causeOfBlockage":null,
"edges":[
]
}
]
Attachments
Issue Links
- is blocked by
-
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-
- relates to
-
JENKINS-39203 All stages show up as UNSTABLE when only one stage should
-
- Resolved
-
- links to
Activity
Sam Van Oort
added a comment - Per discussion with James:
- This tracks overall effort, to be closed when we've verified the changes mentioned above add Abort support for parallels (normal, we don't close tickets until features are verified)
- Leaving both components on there, since the focusing change may need some (hopefully small) front-end work
- This will likely track primarily to the backend work (depending on how much work the focusing is) - still some open questions about if side JIRA issues will be used as well.
Sam Van Oort
added a comment - Per discussion with James:
This tracks overall effort, to be closed when we've verified the changes mentioned above add Abort support for parallels (normal, we don't close tickets until features are verified)
Leaving both components on there, since the focusing change may need some (hopefully small) front-end work
This will likely track primarily to the backend work (depending on how much work the focusing is) - still some open questions about if side JIRA issues will be used as well.
Sean Talts
added a comment - Does anyone have workarounds for this? Ways to convey to the end user which stage failed and why from within a parallel section?
Sean Talts
added a comment - Does anyone have workarounds for this? Ways to convey to the end user which stage failed and why from within a parallel section? Just adding my vote for this issue. We have a pipeline stage with 7 parallels, and every time a build fails we need to click around between the child stages to figure out which one actually failed. This makes the system less usable than Classic, where I can just scroll to the bottom of the combined log and see what actually failed.
Looks like I forgot to update this ticket previously, but this was fixed in Pipeline: Graph Analysis Plugin version 1.10.
svanoort oh there is still UI work we need to do here to ensure the right step is selected.