more fine tuning of web interface

[bill-paxton]

Some more fine tuning of the interface. when i select a particular inlist specific column, the code currently automatically turns on lots of things that are not usually of interest (redos, solver iterations, solver calls made, solver calls failed, log rel run E err). it would be better if those were off be default leaving only runtime, steps, and retries on by default.

And, by default we now carry forward total num retries for the run from one part to the next. So the output I get on the terminal shows cumulative number of retries, not just the number in that particular part. however, that doesn’t match what is being shown for “retries” on the web page. perhaps you are taking the extra step of subtracting off the starting value in order to show only the number of retries that happened in the step (logical thing to do for consistency with steps, etc). in this case, logic be damned, please give me the cumulative total retries so i can easily compare to current values shown on terminal.

i never have felt any need to look at redos, solver iterations, solver calls made, solver calls failed. it would be great to have a way to tell the test hub to skip those when showing me the options. currently they just waste a lot of space on the page and make it look unnecessarily messy. perhaps some sort of “preferences” to indicate which to show?

that might also be a solution to the issue of which things in the list should be on by default when select the particular inlist to show. you could just start with everything on that is included in the preferences.

for me, you could even take it the next step and get rid of the ability to turn particular items on or off on the webpage. i’ll just set preferences to show what i want. then it is only at the inlist level that we’d have an on/off choice, not for the individual items. That would make the interface much simpler (i like simpler). if you don’t like having it that simple, you could provide an “experts only” extra interface for you to enjoy with lots of buttons and bells and whistles! i’ll stick to the simple one.

And — importantly — only show the information for the inlists that are actually selected! currently it fills up the page with all of them whether selected or not.

[wmwolf]

Here's a proposal for you, @bill-paxton

First, some terminology. The commit view is the page that displays information for one single commit, but all test cases, like https://testhub.mesastar.org/main/commits/head. The test case commit view shows all information for one test case on one particular commit, like https://testhub.mesastar.org/main/commits/head/test_cases/star/1M_thermohaline. This is in contrast to the test case history view, which shows data about one test case over time, either as a function of commit, or as a function of individual instances from a single computer, like https://testhub.mesastar.org/main/test_cases/star/1M_thermohaline.

I propose doing some heavy work on the test case commit view, as it has never really been "done", since it can't show details from individual inlists. We replace the table of instances with a list group similar to what we find on the commit view, with only minimal information shown. Each item in the list group can then be clicked, and rather than taking you to a test instance view, it will uncollapse an attached table for that test instance that shows each inlist as a row for that instance. What particular data is shown for the inlists will be controlled by a hideable set of checkboxes, albeit simpler than those in the history view, since all inlists will be shown in their own rows (or perhaps we could restrict which inlists are shown, too, but that seems less helpful when they each get their own row). The initial state of these checkboxes will be determined by sensible defaults which can be overridden by user preferences, and then finally overridden in the view itself by showing the checkboxes and manipulating them.

I like this approach because you can get lots of information in one view without playing clicky clicky to compare different instances, and you won't have to go as deep in the testhub "tree" to get to the data you want. The inlist data is already loaded by the server in requests for the test case commit view, so we might as well use them there.

We can talk about changes to the history view later.

[wmwolf]

New submissions now record the order of inlists. And now, the test case commit view for multi-inlist test cases will show pill-style navigation above the data table, which will show data for each specific inlist in order.

This actually works for older submissions, but there's no guarantee that the inlists will be in the proper order. And furthermore, the individual inlists will mostly report as failing, since their "passage status" is determined by the existence of the "next inlist", which for unordered inlists, will always show up as failing. Nevertheless, I think this is a huge improvement.

No change to the history view yet, so I'll leave this issue open.