Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38523

Stage listing flashes "no steps" when loading a stage for the first time (Karaoke repair)

    • 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

      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.

          [JENKINS-38523] Stage listing flashes "no steps" when loading a stage for the first time (Karaoke repair)

          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

          Thorsten Scherler added a comment - 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

          Old syntax

          Thorsten Scherler added a comment - Old 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)

          Thorsten Scherler added a comment - 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)

          Michael Neale added a comment -

          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?

          Michael Neale added a comment - 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?

          Michael Neale added a comment -

          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!

          Michael Neale added a comment - 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.

          Thorsten Scherler added a comment - Agree michaelneale , further that code will be rewritten by Ivan and me some time soon, so maybe then this issue is no problem anymore.

          Michael Neale added a comment -

          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).

          Michael Neale added a comment - 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

          Thorsten Scherler added a comment - 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?

          Thorsten Scherler added a comment - 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?

          James Dumay added a comment -

          Will be released in Blue Ocean 1.1

          James Dumay added a comment - Will be released in Blue Ocean 1.1

            tscherler Thorsten Scherler
            michaelneale Michael Neale
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: