1095102 - Allow removing builds from similar jobs list

Status: RESOLVED WONTFIX

(Tree Management :: Treeherder, defect, P5)

Description

[Steve Fink [:sfink] [:s:]]

This depends on bug 1095100 changing things first. (I was filing this one first, but realized that it wasn't doing what I thought it was doing.)

Feature request: when I am using the Similar Jobs tab, I often find a bunch of other different failures that I don't care about. It would be nice to be able to throw those out of the list to focus on the relevant ones. This would also let me not care as much about the two panes scrolling together.

Comment 1

[Steve Fink [:sfink] [:s:]]

Oh, and my ultimate interface for this would be a list of checkboxes with keyboard commands (j and k) to move up and down the list, x to select, (or d to mark for deletion?), y (or something) to purge.

Comment 2

[Ed Morley [:emorley]]

In which cases would you like to remove/hide jobs? Just wondering if there's another way to filter to make the workflow more useful (eg "failures only").

Comment 3

[Steve Fink [:sfink] [:s:]]

(In reply to Ed Morley [:edmorley] from comment #2)
> Just wondering if there's
> another way to filter to make the workflow more useful (eg "failures only").

Sometime that would work, and it would be nice to have a way to "add/remove by filter" (as in, you have a set of interesting jobs, and you want to add more in according to a filter, or remove a subset according to a filter.) But that starts to feel complicated and sophisticated. I was going more for something manually controlled where I don't have to think about any data model or anything else.

> In which cases would you like to remove/hide jobs?

The most common case for this is when I'm looking at an intermittent orange, and the signature is a little vague or the log parsers don't have enough to go on so multiple failures get lumped into one. I want to focus in on a couple of instances of the *right* failure, and this is specifically in cases where the automated filtering isn't working. So I would open up a bunch of logs, using this list to record which of them were the right failure and which were something else. (Sometimes this is to get an idea of the variation.)

Come to think of it, an even more common case is when I'm looking at a failure, and I want to compare good runs to bad runs. Similar to the above, I want to look at their logs and figure out what is normal variance (in terms of differing log output) and what is unique to the failed runs. So I end up juggling a bunch of tabs, but I quickly get confused about which are from the good collection and which are from the bad collection.

It maybe sounds like an edge case, but I seem to end up doing something like this for the majority of the times I use the related builds pane.

As an aside, I've been vaguely thinking that I'd kind of like the whole TH UI to be centered around the related jobs stuff. The current view is just a special case of a set of related jobs, it's the ones that are related by virtue of being consecutive pushes to a particular tree. That is the most common thing to want, but many times it isn't. If I'm looking at jobs burned via a releng change, then I kind of want all jobs for a builder or set of builders ordered by start time, regardless of what tree or even what push they came from. Or jobs for a particular slave. Or jobs that took more than x minutes. Or jobs for my pushes.

I think of these as the criteria determining what shows up in the main display, not as filters on top of a single underlying pushlog.

</tangent>

Comment 4

[Ed Morley [:emorley]]

Thank you for the insight there - agree there are several other use-cases that could be better served - though wondering if they are better covered by:
* New Orangefactor/the big data project that could track intermittent failures more accurately
* An improved log viewer that compares a good vs bad job (particularly once we have supported for using the machine readable log output)
* A test-centric view/mode for treeherder.

Comment 5

[Ed Morley [:emorley]]

Wontfix since I don't think we'll be working on this any time soon (now we're only a team of 2) and for the reasons in comment 4 I think other solutions would be preferable.