Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
-
pacific, atlantic, indian, arctic, tasman, iapetus, 1.0, Blue Ocean 1.0-rc3, Blue Ocean 1.0-rc4, Blue Ocean - 1.1-beta-1, Blue Ocean - 1.1-beta2
Description
Some times if the step listing takes a while to show, the pipeline results screen can show "There are no steps" empty state incorrectly, before being replaced with the step listing...
This requires some more investigation as at the moment when it shows no steps when a pipeline is completed this is a problem. When it is running (karaoke) the current behavior is fine. This is just for when a user is clicking around a completed pipeline.
Attachments
Issue Links
- blocks
-
-
- Closed
-
-
-
- Closed
-
-
JENKINS-36133 Animate in steps when stage node is clicked
-
- Resolved
-
- is duplicated by
-
-
- Closed
-
- relates to
-
-
- Reopened
-
-
-
- Closed
-
-
-
- Closed
-
Activity
as discussed - only need to prevent this happening when viewing a completed pipeline (in which case we know that a fetch is in progress, and don't need to show it, or can show a loading animation)
I am trying to get my head around how to prevent the flicker.
The basic problem is to determine when the component is still "waiting" for the step fetch to finish and return the result of the fetch. Or whether that fetch has finished and there are no steps related with the stage.
One observation in "block" pipeline is that empty nodes are not clickable anymore. I could use the same logic though. Will test whether that behaviour is as well the same in the classic pipeline syntax
michaelneale looking into this deeper it shows a bit of bigger underlying issues.
The basic problem is that the logic is bound to the RunDetailsPipeline.jsx which is "managing" three different usecases in the the same view.
The usecases are:
- freestyle log view (plain view on the log, no nodes, no steps)
- no stages just steps
- stages with steps
for the last 2 usecase we do a second call in the actions.js AFTER getting the information on the nodes to the backend. If that action is ended we can determine for sure that e.g. a stage has no steps. However since we are doing the call async in the backend we are using ATM 4 react update lifecycle to render the view and determine that we have/or not steps to display.
We need to add a new event or trigger to inform our component that there are no steps AFTER the fetch is done and THEN we can render the NoSteps/steps. However that would have the consequence that we would introduce a "spinning" wheel until we have done all our fetching (even in a already finished run)
good analysis tscherler. Yes I have noticed that there are kind of 3 different modes (as often they have distinct bugs).
1 could almost be separated code wise from 2 & 3. Ideally 2 is a special case of 3 but that isn't really how it works it seems (as we don't really know we have no stages, the stage view has a similar problem, of course it shows no steps).
So this sounds potentially like a bit more work than anticipated. I wonder if we can adjust the wording to not say "no stages", then it wouldn't be so misleading, and be a tiny change - would that help clarify things?
tscherler have pulled this one out of the sprint - let's leave it for the new year. We need to talk it over more, and it isn't critical or blocking any one. So leave it for now!
Agree michaelneale, further that code will be rewritten by Ivan and me some time soon, so maybe then this issue is no problem anymore.
tscherler have postponed this one again a bit, hope you don't mind (just as it does seem like a bunch of work, correct be if wrong).
michaelneale well we have now more sse-events to rely on, but I agree, we need to refactor karaoke to use mobx anyway and I hope with that we can fix the problem right away
michaelneale we should use this one to refactor the karaoke code to adopt to the core-js approach of services and managers. Further we would drop the dependency on redux for karaoke. WDYT?
bumping this one as more people are complaining about this now.