1501115 - Runnable jobs query seems to include a lot more jobs than is necessary.

Status: RESOLVED WORKSFORME

(Tree Management :: Treeherder: Frontend, defect, P5)

Description

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

I'm wanting to add a feature to Treeherder similar to the `mach try fuzzy` command, which creates a plain-text list of jobs able to be run for a developer's local checkout of Firefox code. With that list, you can do a fuzzy search [1], and select a number of jobs you want to run, and then it submits the proper information as a push to the try server to run only those selected jobs (plus whatever dependencies are required to be able to run them).

The feature I'd want to add (bug to be filed or searched for; I think I saw a bug for it at one point, but it might have just been chatter on irc) would be to either replace or supplement TH's "Add new jobs" feature. You'd be able to push a button in a push on Treeherder and then something in the UI could pop up and display an interface similar to what `mach try fuzzy` uses, with similar keyboard shortcuts, and then when you're done selecting jobs, it can request/create whatever decision tasks are required to run the selected jobs (plus their dependencies).

But I'm a bit confused about how to get the list of runnable jobs. When I use `mach try fuzzy`, I'm presented with a list of roughly 2,500 jobs, which is a lot, but not a totally unexpected number. 

But when I query the runnable jobs API (right now, just a console.log() in ui/job-view/pushes/Push.jsx right after RunnableJobModel.getList() is called), I see a JSON object with roughly 12,000 items. That's 4-5 times larger than what `mach try fuzzy` gives me, which seems unlikely.

That JSON object has several children for a range of 1000 runnable jobs, and each of those children has 10 children which each lists 100 runnable jobs.


Without looking too closely at it, I'm not sure if the runnable jobs API is giving me an accurate list of items. Is there any filtering done before the runnable jobs are added into the list of jobs in Treeherder's UI for the push? I haven't counted, but I'm pretty sure it's not adding 12,000 job icons into the push.

I'm pretty sure the fuzzy finder can handle 12000 items just as easily as 2500, but I'd rather not show 4x as many jobs as I need to.


1. https://github.com/junegunn/fzf

Comment 1

[Ed Morley [:emorley]]

Now that buildbot is EOL, there isn't really any reason we should be handling the taskcluster runnable jobs on the backend. Bug 1494750 is filed for moving it client-side, which would make debugging here since fewer layers to pick through.

Comment 2

[Cameron Dawson [:camd]]

So, I just chatted with Ed in IRC.  This sounds like something that should be handled on the front-end only.  So please feel free to work on a PR for it and we'll go from there.  :)

Comment 3

[Ed Morley [:emorley]]

Bug 1494750 is for moving this to the front-end.

Comment 4

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

Switch to fetching the uncompressed artifact directly from the UI has landed and hopefully sticks. 

I think the disparity between `mach try fuzzy`list and the runnable-jobs.json list is that mach is using the target-tasks.json file (or at least the same mechanism to generate the list) rather than the runnable-jobs.json.

I took a look at things a bit last night...
Target-tasks.json is an array consisting of only task names, while runnable-jobs.json is an array of job objects including task names, platforms, and job symbols, etc.

For what I was interested in implementing in comment 0, I might be able to get by with just the job names (filling in the rest of the needed metadata from the context of the specific push we queried about). But try pushes made via `mach try empty` also seem to have an empty target-tasks.json artifact, preventing me from being able to use it for those pushes.

I'm wondering if maybe I could get taskcluster to upload the normal target-tasks.json artifact unconditionally and still let everything work as expected (maybe an empty actions.json is enough to let mach try empty start no builds and tests?

Or maybe I should just fetch runnable-jobs.json and then trim it down significantly before attempting to use it (cut out jobs with "beetmover", "balrog", etc)

(I still don't know if Add New Jobs is similarly cutting down the number of runnable jobs before toggling runnable-job visibility. It really does not feel like there are 13,000+ runnable jobs being listed.)

2am rambling status dump over. :)

Comment 5

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

(In reply to Wes Kocher (:KWierso) from comment #4)
> (I still don't know if Add New Jobs is similarly cutting down the number of
> runnable jobs before toggling runnable-job visibility. It really does not
> feel like there are 13,000+ runnable jobs being listed.)
Seems I misspoke here. I did a getElementsByClassname() on the runnable job class, and it returned 13,000+ elements. I guess they just collapse really nicely in the collapsed mode, making them look like much less.

Comment 6

[Ed Morley [:emorley]]

Does comment 5 mean this is worksforme? :-)

Comment 7

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

Yeah, sure. Another option I saw was to take the full-task-graph.json artifact and only use the jobs with certain "kind" attributes ("test" and "build" come to mind, maybe others?) That would cut down the list to like 4000 jobs, which should be much more manageable.