1272212 - Make the "add new jobs" mode more intuitive to use

Status: NEW

(Tree Management :: Treeherder, defect, P3)

Description

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

This shouldn't be *too* confusing, I think:

Normally, if you click a push's "pin all" button, it adds all of the visible jobs for that push to the pinboard.

I propose that we overload that function so that if a push is in the "add new jobs" mode (where all jobs get shown as selectable to be triggered), the "pin all" button selects all of the visible jobs for the "add new jobs" mode, not to the pinboard.

This would make it easy to do something like:
1. Filter to only show Android jobs from the filter bar.
2. Put a push into "add new jobs" mode.
3. Click the "Pin all" button.
4. Click the "Trigger new jobs" button.

And have all of the android jobs get triggered with just three clicks rather than dozens/hundreds.

Comment 1

[Armen [:armenzg]]

This is a great idea! Hopefully I can work on it this coming quarter.

Comment 2

[Ed Morley [:emorley]]

Morphing this bug to be about improving the overall UX of the "add new jobs" feature, which may include make the change suggested in comment 0 amongst others :-)

Comment 4

[:Gijs (he/him)]

It doesn't help that filtering clears the selection. So if I do:

1. add new jobs
2. filter for "linux mochitest x64"
3. select all the mochitests I want
4. filter for "linux xpcshell x64"
5. select all the xpcshell tests I want
6. clear the filter and hit enter, to check what I've done

ER: all selected mochitests/xpcshell tests are marked as selected and can be triggered

AR: none of them are.

More generally, it'd be nice if we could "select all" based on a filter, or something, to avoid playing "click individual tiny things 100 times". (chunked mochitest plain, mochitest-bc, mochitest-dt, xpcshell, marionette, firefox-ui-functional tests even for just linux64 opt + debug approaches that number)

In the current state it's very tempting to just do a new trypush, but that wastes machine resources (and thus money) in rerunning the build steps.

Could this please be prioritized?

Comment 5

[(not currently active) Ted Mielczarek]

I was just griping about this the other day as well. I think what I'd probably want nowadays is just an equivalent of `mach try fuzzy`. We joked on #ateam about compiling fzf to WebAssembly, but replicating the "filter the list of tasks by name using regexes" behavior is probably not super complicated if you have a nice web framework at hand. Clicking the individual job icons is tedious, and even with filtering finding the set of tasks you're interested in can be a bit difficult.

Comment 6

[Ed Morley [:emorley]]

(In reply to Ted Mielczarek [:ted] [:ted.mielczarek] from comment #5)

I was just griping about this the other day as well. I think what I'd
probably want nowadays is just an equivalent of mach try fuzzy.

Bug 1517700 is in progress to add exactly this in fact :-)