snippet should be hidden by default, description should be primary

[berrange]

Describe the bug

I had a build failure on one of my centos stream packages. Log detective posted its summary of the problem in a comment.

The comment started with a huge wall of text - the "Snippet" information was 50 lines long and reading that was harder than reading the original build.log.

Following that wall of text there was then the "Description" section, where log detective provided a concise 4 line summary of the problem that was entirely accurate and useful. This "Description" text, however, was formatted in the gitlab comment so that it was collapsed / hidden until you clicked on it.

Assuming the description is reasonably accurate, tThis is the opposite of what should be done from a usability POV.

To Reproduce
Steps to reproduce the behavior:

1. Run a dist-git build in centos stream that fails
2. Wait for log detective to post its comment
3. Observe the comment formatting/layout

Expected behavior
The "Description" should be the very first thing in the comment, and visible by default. The "Snippet" showing the detailed analysis should be second, and collapsed / hidden unless the dev wants to confirm details.

Screenshots
Look at

https://gitlab.com/redhat/centos-stream/rpms/linux-sgx/-/merge_requests/10#note_2897047623

The wall of text

(the other 50 lines removed to keep the screenshot small)

vs the following description which is collapsed hidden by default:

but when expanded shows a useful & accurate root cause

If we assume that description text is intended to be an accurate root cause analysis, this should have been the very first bit of the comment.

[jpodivin]

Thanks for the feedback. I believe it makes sense to change the way we display results.

[lachmanfrantisek]

Hi @berrange and thanks for writing down all the details.

I'll try to provide a bit of historical context since this is actually the original behaviour of Log Detective... 😁 This was changed after receiving a bunch of UI suggestions from a designer. (Maybe this wasn't properly understood.)

Since Jiří mentioned to me that multiple users have been asking about this and the reasoning makes sense, let's revert the change. (I hope this is quite clear and we won't receive many requests for reverting the reverting of the change...;)

(Creating internal LD-211 Jira tickets so the team can take a look.)

[lachmanfrantisek]

(Removing the bug usage since this is more of a UX/UI problem than a real bug.)