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

Developer sees ETAs on hover states for all indicator types

    • iapetus

      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

          [JENKINS-35849] Developer sees ETAs on hover states for all indicator types

          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

          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

          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?

          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?

          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.

          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.

          Michael Neale added a comment -

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

          Michael Neale added a comment - jmcdonald right, which can have dire consequences if wrong and it pops off the screen ...

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

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

          James Dumay added a comment - - edited

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

          James Dumay added a comment - - edited svanoort 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.

          Sam Van Oort added a comment -

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

          Sam Van Oort added a comment - jdumay 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)

          Michael Neale added a comment -

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

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

          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.

          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.

          James Dumay added a comment -

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

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

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

              Created:
              Updated:
              Resolved: