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)

    XMLWordPrintable

    Details

    • Similar Issues:
    • Sprint:
      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

            Activity

            Hide
            michaelneale Michael Neale added a comment -

            bumping this one as more people are complaining about this now.

            Show
            michaelneale Michael Neale added a comment - bumping this one as more people are complaining about this now.
            Hide
            michaelneale Michael Neale added a comment -

            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)

            Show
            michaelneale Michael Neale added a comment - 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)
            Hide
            tscherler 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

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

            Old syntax

            Show
            tscherler Thorsten Scherler added a comment - Old syntax
            Hide
            tscherler Thorsten Scherler added a comment -

            Michael Neale 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)

            Show
            tscherler Thorsten Scherler added a comment - Michael Neale 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)
            Hide
            michaelneale Michael Neale added a comment -

            good analysis Thorsten Scherler. 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?

            Show
            michaelneale Michael Neale added a comment - good analysis Thorsten Scherler . 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?
            Hide
            michaelneale Michael Neale added a comment -

            Thorsten Scherler 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!

            Show
            michaelneale Michael Neale added a comment - Thorsten Scherler 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!
            Hide
            tscherler Thorsten Scherler added a comment -

            Agree Michael Neale, further that code will be rewritten by Ivan and me some time soon, so maybe then this issue is no problem anymore.

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

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

            Show
            michaelneale Michael Neale added a comment - Thorsten Scherler 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).
            Hide
            tscherler Thorsten Scherler added a comment -

            Michael Neale 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

            Show
            tscherler Thorsten Scherler added a comment - Michael Neale 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
            Hide
            tscherler Thorsten Scherler added a comment -

            Michael Neale 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?

            Show
            tscherler Thorsten Scherler added a comment - Michael Neale 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?
            Hide
            jamesdumay James Dumay added a comment -

            Will be released in Blue Ocean 1.1

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

              People

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

                Dates

                Created:
                Updated:
                Resolved: