feat(core): add one click details information popover for failed pipeline stage

[RodEsp]

Copy of #8322, but rebased on and PR'ed against master.

feat(execution/ExecutionMarkerInformationPopover) Adds 1-click access to the actual error at the last level pipeline

• New feature can be enabled/disabled via executionMarkerInformationPopover in the settings.js spinnakerSettings:feature section
• ExecutionMarker.tsx now loads the new component and for a stage with status 'terminal', type 'pipeline' and will add an font-awesome information circle icon to the stage
• When information icon is clicked modal will load and traverse through the execution => terminal stage(pipeline) until the last instance is found then report that actual error stage and execution allowing for quick access and viewing
• ExecutionMarkerInformationPopover component adds/removes listeners for the window.resize and '.all-execution-groups' scroll events to allow for updating it's position and 'nubbin' position, scrolling the clicked stage as it hit the stop container will close
• ExecutionMarkerInformationPopoverState caches and validates api calls returning cached versions for quicker access since there can be many calls made to the same execution/pipelineConfigs etc
• Lists the execution history in reverse order as clickable rows
• Has secondary area for showing history again in reverse order using the spinnaker PipelineGraph component

[spinnakerbot]

The following commits need their title changed:

• e86839c: Adds 1-click access to the actual error at the last level pipeline

• a7320d8: Add executionId to the IExecutionViewState interface.

Please format your commit title into the form:

<type>(<scope>): <subject>, e.g. fix(kubernetes): address NPE in status check

This allows us to easily generate changelogs & determine semantic version numbers when cutting releases. You can read more about commit conventions here.

[maggieneterval]

🎉 I built your branch locally and played around with this a bit, and it looks 💯! Thanks for the excellent work!

Besides several questions and codestyle nits I've left inline, my biggest concern is around the fragile logic in ExecutionMarkerInformationPopover for adjusting the modal based on resize/scroll events. Given that other modals in Spinnaker are not responsive in this way, I'm hesitant to add a lot of complexity to this one particular component that seems likely to unexpectedly break if someone were to, for example, refactor its CSS. Do we feel this would be usable without such resize/scroll responsiveness?

Thanks again for the great contribution!

[sseale-zz]

@maggieneterval I fixed up issues in commit f508b64 and added some inline comments to help with the "why's" of some of the code let me now what you think.

@RodEsp

[maggieneterval]

Thanks so much, @sseale and @RodEsp!

Apologies for not thinking of this right away, but how would you feel about removing the custom resize/scroll handling and instead placing this component inside Deck's existing Modal component? I think it would be preferable in terms of visual consistency as well.

The other pre-existing component Deck has for opening content in the foreground above the main view is the HoverablePopover. This also handles placement in relation to the anchor element, but automatically opens/closes on hover start/end, so likely would be less than ideal for a large component like this from which you expect users to need to click into other elements.

Let me know what you think!

[maggieneterval]

And one final minor issue I just discovered while running the latest version of your branch is the following warning about non-unique keys:

Warning: Each child in a list should have a unique "key" prop.

Check the render method of `ExecutionMarkerInformationPopover`.

[RodEsp]

Heya @maggieneterval, will definitely take care of that unique key warning.

I was playing around last week with re-implementing this not with the HoverablePopover because "hover" won't work for our usecase but with the react-boostrap OverlayTrigger and Popover components (which is what HoverablePopover uses) and I was having a lot of trouble trying to get things to line up properly with the anchor element.

Thanks for the Modal suggestion! I'm going to try that and keep playing around with this a little more. I'll get back to you in a day or two and let you know if it works or what my findings were if it doesn't.

[sseale-zz]

@maggieneterval @RodEsp we can try to play around with the modal and just have it open and not worry about all the event handlers. Each stage is already a Tooltip component so not sure how well wrapping a tooltip with a tooltip/popover works. Sorry i thought i added the new key in to fix that but realized i added it to our custom version in 1.19. We will get that fixed as well.

[sseale-zz]

@maggieneterval this is now using the Modal

[sseale-zz]

@maggieneterval i have made some changes but have not figure out anything with the ui router component wrapped around an tr as i mentioned above. i added in a service spec but skipping the two tests for now.

[sseale-zz]

@maggieneterval i believe i have all the issues addressed now

[maggieneterval]

Pending resolution of a few remaining comments, would love to merge this by end of day Friday so it makes it in time for the 1.21 release.

If anyone else who saw this demo'd at the UI SIG (@caseyhebebrand @erikmunson @gcomstock) wants to take a pass as well before we merge, please feel free!

[RodEsp]

Thank you so much with all your help on this Maggie!

[gcomstock]

Thanks for the demo and all your work on this, @RodEsp ! I don't have any feedback that should bar this from being merged. I would be happy to pass along how users receive it over at netflix though, and once I see a lot of real data flow through it, I might pop back around with the design feedback if needed. Thanks again!

[RodEsp]

Sounds great, thanks @gcomstock, although @sseale did the vast majority of the work here :)

Would love to get feedback on what Netflix thinks!