Hide Forgot
Description of problem: Results are no longer structured into levels as were in RHTS: job -> recipe -> task. When job results are opened, all information from job id to the least significant debug log attached to some unimportant task are visible. Compare these two jobs - same setup, one in rhts one in beaker: RHTS (un-fold the recipe) http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=151215&type=single BEAKER https://beaker-stage.app.eng.bos.redhat.com/jobs/527 The one from beaker is 3 times longer and contains lots of task-run details that are not important for general overview of a run. Now imagine scenario with 5 recipes, each around 160 tasks, many of those tasks having subtests (a.k.a BaseOS QE TestTiers). That would be one helluva result page. RHTS had this solved pretty well with different levels of details 1)recipe overview - to quickly spot which machine aborted, which is still running,... RHTS: http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=151215&type=single 2) recipe details - task results - list of tasks with results & score (and maybe times), nothing more. To quickly find particular task and its results RHTS: the above link after clicking the triangle 3) task details - log, attachments, all available info. For debugging purposes. RHTS: http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=13691896 I wouldn't mind if the different detail level were implemented using some modern html/javascript magic if all levels remain linkable (for example #2 is not in RHTS) Thanks
I've made some changes on beaker-stage that incorporate some of the things you mention. Can you look and see if that is a step in the right direction? Just so you know, People complained about the levels that they had to open in the old rhts. Hopefully I can strike some middle ground where everyone is somewhat happy.
I think it will be hard to make everyone happy. How about letting users set preferences so their default view unrolls as they like?
I agree. (In reply to comment #1) > I've made some changes on beaker-stage that incorporate some of the things you > mention. Can you look and see if that is a step in the right direction? It is, thanks. The new collapsed recipe view corresponds to view#1 from comment#0 > > Just so you know, People complained about the levels that they had to open in > the old rhts. I see. Than there probably isn't one result page layout to satisfy all users and I'd go with the configurable level of details Kevin mentions: * levels of details as described in comment#0 * default level configurable via preferences * controls on result page - the ones currently present (per-recipe) and a global one - expanding/collapsing all recipes at once * level of details embedded in URL so that links can be sent for a particular detail level What do you think?
I haven't had any complaints since the new layout change. and Today's update loads the task results as an ajax call, this should resolve the performance issues. Can I close this?
The non/all detail level are satisfied by collapsing/expanding individual recipes of a job. And for the intermediate level of details (view#2), matrix report (that is, by the way, absolutely awesome) can be used. Only two minor [RFE] remains: - global "[hide|show] [all|failed] results" buttons that will work on all the recipes at once - link the matrix report from job result page (even though one job matrix report probably isn't the major use-case for it, it still is very useful) Should I file those as separate RFEs? Thanks
Ales, Sorry for the very delayed response. If you could file these as seperate RFE's that would be great.