1430554 - Spidermonkey jobs run on too many try jobs

Status: RESOLVED DUPLICATE of bug 1528427

(Firefox Build System :: Task Configuration, task)

Description

[James Graham [:jgraham]]

e.g. https://treeherder.mozilla.org/#/jobs?repo=try&revision=c97ee59050cbbe0f046edf0f0d84d85bea916451 is running a bunch of sm* jobs, despite the fact that there are no spidermonkey related changes in the commits. Some of these jobs are very long-running (the windows builds seem to  take up to 3 hours). These should be scheduled more conservatively.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

Agreed!  There's not a lot of optimization configured for SM jobs.  sfink, is that something the new SCHEDULES-based optimization would enable?

https://firefox-source-docs.mozilla.org/taskcluster/taskcluster/optimization-schedules.html

Comment 2

[James Graham [:jgraham]]

FWIW I am currently working around this by deleting all ridealong-builds in the try commit. Which is obviously not ideal if something actually useful is added there in the future (and happens to make the yaml lint fail, so hopefully I also never need to care about that).

Comment 3

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

(In reply to Dustin J. Mitchell [:dustin] from comment #1)
> Agreed!  There's not a lot of optimization configured for SM jobs.  sfink,
> is that something the new SCHEDULES-based optimization would enable?
> 
> https://firefox-source-docs.mozilla.org/taskcluster/taskcluster/optimization-
> schedules.html

Uh, maybe? I read through that page. I got the general gist, but I'm fuzzy on the details.

The spidermonkey jobs are currently optimized only with the 'when' file-based rules.

If we were to switch to the SCHEDULES stuff, then I guess the spidermonkey jobs would be "inclusive", and js/src/** would set SCHEDULES.inclusive += ['spidermonkey']. So far so good. Do those now get intersected with the platforms selected with the try -p option? I know the platforms are considered to be exclusive partitionings, but I don't understand how that works in practice.

I thought the intended current behavior was that you wouldn't get spidermonkey builds if you pushed with -p all, only if you pushed with -p linux64 or -p win32, and you would only get them in any case if you touched the right files. In looking at the current state, that does not seem to be what's happening? It appears that -p all currently gives you all of the spidermonkey builds if you touch relevant files, and -p linux64 gives you the spidermonkey builds even if you don't touch the relevant files.

Which is great, if I'm really getting this all right, because that makes me think that SCHEDULES stuff would be a pure improvement over our currently-regressed state! I'm ok with -p all continuing to run spidermonkey builds if you touch spidermonkey files, and with -p linux64 no longer running spidermonkey builds if you don't touch spidermonkey files.

Ah! And I see that the jerk who broke -p all so that it runs the unwanted ridealongs in bug 1304775 is that sphink guy. Honestly, I don't know why you let him mess with any of this stuff, he clearly doesn't know what he's doing and can't keep his story straight for more than a few minutes at a time. In that bug, I argued that -p all running the ridealongs is clearly expected. Ok, fine, sphink-now reluctantly agrees with sphink-then and the current implementation. sphink-then did bring up the point that we might now want to trigger lower-tier jobs like sm-tsan, but given that we are now (intentionally) running that job on every mozilla-inbound push, I think sphink-then should put a sock in it. It's fine for these to only be file-based.

That's a long-winded way of saying that I think you're right, SCHEDULES is the right thing to use today. I suppose I still want -p linux64 to run spidermonkey builds, so this is kind of independent of the ridealong mechanism. So this bug should be for replacing the current 'when' file list with SCHEDULES.includes += ['spidermonkey'].

One wrinkle might be that the current file list is pretty broad, and we want to be removing some of the dependencies. It's easy to procrastinate on that while it's just a list in the spidermonkey kind.yml, but I'm doubtful that build peers will allow polluting random things with SCHEDULES.includes additions that shouldn't really be there (but currently are because there is a true but unwanted dependency.) So that work may be a prerequisite.

Hm... it would be cool if the ridealong configuration allowed SCHEDULES components in addition to platforms, so I didn't have to list every new spidermonkey job there in addition to the kind.yml file. But... no, ridealongs are probably weird enough already. Keeping them as "intra-build platform dependencies" is probably better. Perhaps make virtual platforms "sm-linux64" and "sm-win32" and make the actual jobs like sm-plain be sort of like test jobs that depend on those? I don't think anyone's actually using -p sm-plain today.

Meh, that's for another bug, if it even makes sense.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

The try selection and when/schedules bits are unrelated processes. The former is target task selection, the latter is optimization.  So basically try syntax decides what is of interest, and then optimization decides, on a task-by-task basis, whether the task will provide useful information.

Try syntax is deprecated because it's clunky and doesn't work too well.  Ridealong biulds are part of that "not very well" and don't exist in tryselect.  But more importantly, for try syntax there is no way to say "definitely run task X no matter what": even if you include the task in the try syntax, optimization may later remove it.  By contrast, for regular pushes and for tryselect, if a task is explicitly selected in the target task set, it will never be optimized (optimize_target_tasks = False).  So if you pick an SM job in `mach try fuzzy`, it will definitely run regardless of optimization.

Comment 5

[Tom Prince [:tomprince]]

This was fixed in Bug 1528427.