UI: Suggestion: Make JSON files viewable inline, don't force download

[pfalcon]

Steps to reproduce:

1. Go on a testrun info page like https://qa-reports.linaro.org/pfalcon/zephyr-net/build/c6edfa09/testrun/1016178.1/
2. Click on the "Log file" button and see test file open right in your browser for quick checking.
3. Click on "Tests file", "Metrics file", or "Metdata file", and instead be prompted by dialog to download a file or open it in a random external program. When you choose the latter, you (very likely, default for Ubuntu at least) get JSON shown as a text, i.e. one long line, not human behavior.

Expected behavior: ability to check content of JSON files quickly, right in the browser, without useless extra clicks and in structured, human-readable form.

Potential ways to achieve: Firefox includes builtin JSON viewer: https://developer.mozilla.org/en-US/docs/Tools/JSON_viewer . However, as https://stackoverflow.com/a/32157007/496009 explains, it won't work if the url has "Content-Disposition: attachment" in headers. Let's check:

$ curl -v https://qa-reports.linaro.org/pfalcon/zephyr-net/build/c6edfa09/testrun/1016178.1/metadata 2>&1 | grep attachment
< content-disposition: attachment; filename="pfalcon_zephyr-net_c6edfa09_1016178.1_metadata.json"

Indeed, that appears to be a culprit.

Double-check that "Log file" doesn't have it:

curl -v https://qa-reports.linaro.org/pfalcon/zephyr-net/build/c6edfa09/testrun/1016178.1/log 2>&1 | grep attachment
pfalcon@zenbook:~$ 

Bingo.

[mwasilew]

@pfalcon firstly, my intention is to entirely get rid of 'testrun' page as it just introduces additional 'clicks'. Secondly, what would be the use case for viewing the machine readable file in the browser?

[pfalcon]

my intention is to entirely get rid of 'testrun' page as it just introduces additional 'clicks'

Well, I would consider it's the best practice that every object type in a system has it's own page, where as full as possible information about that object type is provided (of course, bits and pieces of that info may appear on other pages, where it makes sense). In that sense, I'd be saddened by this changes.

Secondly, what would be the use case for viewing the machine readable file in the browser?

Well, "machine readable" shouldn't mean "human unreadable". Behind all these systems are still humans, who need to debug their functioning regularly. One example is this build: https://qa-reports.linaro.org/pfalcon/zephyr-micropython/build/529d3195/ . It's kinda complete, and no useful test(suite) information is shown. So I actually need to go to a page like https://qa-reports.linaro.org/pfalcon/zephyr-micropython/build/529d3195/testrun/1030324/ and check that "test file" is indeed empty, and it's not just a UI glitch. Making such check-ups more user-friendly rather than less is a worthy goal IMHO.

[mwasilew]

Well, I would consider it's the best practice that every object type in a system has it's own page

I don't share this opinion. UI should minimize the number of 'clicks' to get to the information you need. IMHO test run is just an intermediate object that is required to record the test result. It doesn't need any UI representation.

Well, "machine readable" shouldn't mean "human unreadable".

It shouldn't and it's not the always the case for YAML. In your case when there are just handful of results for each job, it's easy. But there are jobs with 500k+ results. The YAML is pretty big and I claim is 'human unreadable'.

To sum up, I can keep this ticket open as a low priority feature request. For the moment I don't think the changes are needed or urgent.

[pfalcon]

But there are jobs with 500k+ results. The YAML is pretty big and I claim is 'human unreadable'.

Folks with such jobs can proceed to right-click and "Download as..." directly, so shouldn't feel left out.

To sum up, I can keep this ticket open as a low priority feature request. For the moment I don't think the changes are needed or urgent.

I fully agree with classification as a low-priority feature request. I just try to record possible improvements I spot, while I'm still a novice with SQUAD, and don't just learned to ignore "rough edges" ;-). I also appreciate allowing this to stay open, indeed, there could be additional votes collected, or some other beneficial outcome, e.g. I start hacking on SQUAD myself and contribute a patch (I don't expect that to happen soon, but hope to happen eventually, and not closing tickets right away is definitely a motivation towards that, not against it).

Thanks.

[pfalcon]

I really appreciate this being addressed, since the original report, I a few times hot the case when I had to poke in those files, and download/find downloaded file/behold dump of such older downloads definitely made it less comfortable than it could be ;-).

[mwasilew]

@pfalcon I'm not sure this is what you expected. Once it's rolled out to production, please share your opinion.

[pfalcon]

@pfalcon I'm not sure this is what you expected. Once it's rolled out to production, please share your opinion.

Sorry for the delay, but this works exactly as expected/proposed: browser (firefox in my case) JSON viewer is opened, which allows me to see data in structured/raw format or save to disk. Thanks again! Small things like that add "polished" and "somebody cares about this stuff" feeling.