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

Developer sees ETAs on hover states for all indicator types

    XMLWordPrintable

    Details

    • Similar Issues:
    • Sprint:
      iapetus

      Description

      In Scope

      • Hovering over each node shows the following tooltip
        • Running – text: "Running for 2 minutes 32 seconds, finishes in 3 minutes 12 seconds"
        • Successful – text: "Passed in 2 minutes and 23 seconds"
        • Unstable – text: "Passed in 2 minutes and 23 seconds but marked as unstable."
        • Failed – text: "Failed in 2 minutes and 23 seconds"
        • Not built – text: "Estimated to start in 2 minutes 32 seconds"
        • Unknown – text: "Unknown"
      • All text must be i18n'able

        Attachments

          Issue Links

            Activity

            Hide
            jamesdumay James Dumay added a comment -

            [~jmcdonald] here's where the indicator implementations being different becomes a problem... I feel like we will be chasing our tails to make sure they behave the same way.

            Show
            jamesdumay James Dumay added a comment - [~jmcdonald] here's where the indicator implementations being different becomes a problem... I feel like we will be chasing our tails to make sure they behave the same way.
            Hide
            sophistifunk Josh McDonald added a comment -

            Yes, we expected it to be a problem at some point. But if we're going to build in complicated hover popups, then uniting them into a shared componet that can function as both (part of a larger SVG) and (a first-class HTML DOM node) will become more complicated, as well.

            Show
            sophistifunk Josh McDonald added a comment - Yes, we expected it to be a problem at some point. But if we're going to build in complicated hover popups, then uniting them into a shared componet that can function as both (part of a larger SVG) and (a first-class HTML DOM node) will become more complicated, as well.
            Hide
            jamesdumay James Dumay added a comment -

            [~jmcdonald] any alternatives?

            Show
            jamesdumay James Dumay added a comment - [~jmcdonald] any alternatives?
            Hide
            sophistifunk Josh McDonald added a comment -

            No, it's not a super-difficult thing, we just need to separate the standalone component into two, an outer that serves to be the SVG container, and an inner that actually represents the geometry. We'll need to make sure the inner can be used by both the standalone one and as part of the pipeline graph, and also make sure the popup-creation code can be used from both "container" components.

            Fiddly, but nothing fundamentally challenging

            Show
            sophistifunk Josh McDonald added a comment - No, it's not a super-difficult thing, we just need to separate the standalone component into two, an outer that serves to be the SVG container, and an inner that actually represents the geometry. We'll need to make sure the inner can be used by both the standalone one and as part of the pipeline graph, and also make sure the popup-creation code can be used from both "container" components. Fiddly, but nothing fundamentally challenging
            Hide
            jamesdumay James Dumay added a comment -

            [~jmcdonald] sounds reasonable. New ticket for that or should it be included in the scope here?

            Show
            jamesdumay James Dumay added a comment - [~jmcdonald] sounds reasonable. New ticket for that or should it be included in the scope here?
            Hide
            sophistifunk Josh McDonald added a comment -

            I'm not sure what the priority is on this, but I think making the renderers shared should probably be done first, as it'd more pain to do after, and much easier to reason about + review without breaking things if done separately rather than together

            Show
            sophistifunk Josh McDonald added a comment - I'm not sure what the priority is on this, but I think making the renderers shared should probably be done first, as it'd more pain to do after, and much easier to reason about + review without breaking things if done separately rather than together
            Hide
            michaelneale Michael Neale added a comment -

            this sounds clever and hard. Is the problem that we want to hover over both SVG things but also dom nodes?

            Show
            michaelneale Michael Neale added a comment - this sounds clever and hard. Is the problem that we want to hover over both SVG things but also dom nodes?
            Hide
            sophistifunk Josh McDonald added a comment -

            The popups will need to be triggered by JS either way, we just need to put some thought into which container they get added to, and how we determine where to put them, in said container's layout space.

            Show
            sophistifunk Josh McDonald added a comment - The popups will need to be triggered by JS either way, we just need to put some thought into which container they get added to, and how we determine where to put them, in said container's layout space.
            Hide
            michaelneale Michael Neale added a comment -

            [~jmcdonald] right, which can have dire consequences if wrong and it pops off the screen ...

            Show
            michaelneale Michael Neale added a comment - [~jmcdonald] right, which can have dire consequences if wrong and it pops off the screen ...
            Hide
            svanoort Sam Van Oort added a comment -

            Comment on this, to consider: parallel blocks (and stages containing them) may have more than one state, I.E. one branch may fail where another passes. How does one represent mixed states?

            Other point: NotExecuted stages/nodes – this can happen when resuming from a checkpoint (the flownodes are created preceding the checkpoint but marked with NotExecutedNodeAction).

            Implementation point: try/catch blocks can generate steps with nodes marked as failed where the overall FLOW still succeeds (error was caught). See https://issues.jenkins-ci.org/browse/JENKINS-34212

            Hopefully by mentioning these issues now, they will avoid tripping you up later (as they have cropped up in stage view and had or are HAVING to be handled).

            Show
            svanoort Sam Van Oort added a comment - Comment on this, to consider: parallel blocks (and stages containing them) may have more than one state, I.E. one branch may fail where another passes. How does one represent mixed states? Other point: NotExecuted stages/nodes – this can happen when resuming from a checkpoint (the flownodes are created preceding the checkpoint but marked with NotExecutedNodeAction). Implementation point: try/catch blocks can generate steps with nodes marked as failed where the overall FLOW still succeeds (error was caught). See https://issues.jenkins-ci.org/browse/JENKINS-34212 Hopefully by mentioning these issues now, they will avoid tripping you up later (as they have cropped up in stage view and had or are HAVING to be handled).
            Hide
            jamesdumay James Dumay added a comment - - edited

            Sam Van Oort you might want to add this comment to the backend ticket - UX-448.

            Usually we have two tickets (frontend and backend) so its clear who is doing what and keep the communication lines clear between the team members.

            Show
            jamesdumay James Dumay added a comment - - edited Sam Van Oort you might want to add this comment to the backend ticket - UX-448 . Usually we have two tickets (frontend and backend) so its clear who is doing what and keep the communication lines clear between the team members.
            Hide
            svanoort Sam Van Oort added a comment -

            James Dumay Ah, good point, thanks – I'll add there too (both ends need to be aware of this since it touches upon the data model used for communications here)

            Show
            svanoort Sam Van Oort added a comment - James Dumay Ah, good point, thanks – I'll add there too (both ends need to be aware of this since it touches upon the data model used for communications here)
            Hide
            michaelneale Michael Neale added a comment -

            Sam Van Oort there are probably a few tickets some of those things are covered.

            In the case of caught errors that result in overall success - I think that is ok. It may look odd and we may need to tweak how it behaves though.

            For parallel: if a branch fails then the "enclosing" stage should probably be shown as a failure.

            I think there will be many more little tickets to flush out these edge cases vs all at once.

            Show
            michaelneale Michael Neale added a comment - Sam Van Oort there are probably a few tickets some of those things are covered. In the case of caught errors that result in overall success - I think that is ok. It may look odd and we may need to tweak how it behaves though. For parallel: if a branch fails then the "enclosing" stage should probably be shown as a failure. I think there will be many more little tickets to flush out these edge cases vs all at once.
            Hide
            svanoort Sam Van Oort added a comment -

            [~mneale] Yes, a failure on a branch indicates a failure for the stage... this is also true for successes across all branches. The other states are less well-defined though (we should consider providing some sort of "fuzzy" option where there are different values).

            For now, I'd be happy seeing something that covers the 90% of cases but isn't going to fall over totally with the other 10%, but I want to make sure they're noted so they don't come up as a surprise.

            Show
            svanoort Sam Van Oort added a comment - [~mneale] Yes, a failure on a branch indicates a failure for the stage... this is also true for successes across all branches. The other states are less well-defined though (we should consider providing some sort of "fuzzy" option where there are different values). For now, I'd be happy seeing something that covers the 90% of cases but isn't going to fall over totally with the other 10%, but I want to make sure they're noted so they don't come up as a surprise.
            Hide
            jamesdumay James Dumay added a comment -

            This ticket has been redefined in JENKINS-40929. Please watch this ticket instead.

            Show
            jamesdumay James Dumay added a comment - This ticket has been redefined in JENKINS-40929 . Please watch this ticket instead.

              People

              Assignee:
              tscherler Thorsten Scherler
              Reporter:
              jamesdumay James Dumay
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: