When using the test report feature of Gitlab CI, the width of the popover showing test output is far too low to read properly.
Steps to reproduce
Publish a build.artifacts.reports.junit report and click on a failed test in the Merge Request panel. This pops up a window that is very narrow. Especially when looking at java stacktraces, a lot of linebreaking occurs, making the trace unreadable.
What is the current bug behavior?
The width of the output window is at most 800px. This is too narrow for many types of build output.
What is the expected correct behavior?
Scale the build output window to atleast 80% of the viewport width.
Relevant logs and/or screenshots
Possible fixes
Set the max-width and the width CSS properties to 100%.
Technical proposal
We can do a small change to make this take the full width. Instead of doing two columns, one for the title and one for the system output, we can do one single column and have they title be above the output. Similar to the following screenshot:
@shampton & @gdoyle - What do you think about this proposal? We continue to see growth in usage of the feature so better support for large output may be nice?
@jheimbuck_gl@shampton I like this proposal! I think it will definitely help improve readability. It also seems like we removed the dark background behind the system output... I think it might be worth thinking about bringing that styling back especially if we make the screen larger. WDYT?
I didn't know that feature existed @jheimbuck_gl so I'm glad you pointed that out! I agree that keeping the focus on the size of the output is best. Do we want to stick this in this epic &5200 ?
@jheimbuck_gl@gdoyle Currently the design is basically we have two column. One large column is the property name (in this case System output) and the other column is the value (in this case the test output trace). I think we could probably redesign this to not use two columns so that the output could take up the full width of the modal. Something like the following screenshot but obviously designed better:
@shampton That looks better to me. What do you think about making this fluid so users with larger screens can benefit from the extra screen real estate?
@jheimbuck_gl We can switch the modal size (768px) from the default size to the large size (990px), then have the system output be fluid width relative to that width. We'd have to come up with a better overall design for this modal though.
@gdoyle@rkenney2@shampton@mfluharty - It might be worth a milestone of FE work to just close these issues out while we're implementing the new MR widget framework? WDYT?
@jheimbuck_gl Seeing all the related issues, yeah I think that's a good idea - I think these are all dependent on the design for #342564. I can take that in 14.6 and drop #33418 (closed)
Based on this related (duplicate) issue, we should also consider how we handle long lines. Right now we are wrapping, but that ends up causing some really hard to read logs. Example: