1238452 - Need explicit try syntax to trigger or suppress SpiderMonkey builds.

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Tooru Fujisawa [:arai]]

Currently SpiderMonkey builds are triggered if pushed changesets touch files under js/src (am I correct?)

in bug 1237993 I want to run talos test without running SpiderMonkey builds, to avoid consuming unnecessary server resource.

there could be 2 solutions
  1. trigger SpiderMonkey builds only if explicitly specified  (maybe -p sm-warnaserr etc is it?)
  2. add new try syntax to suppress SpiderMonkey builds

solution 1 will affect SpiderMonkey engineer's workflow tho, it might be clearer.

Comment 1

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

It's a bit of a mess, since the spidermonkey builds are somewhere in the process of transitioning from buildbot to taskcluster. The taskcluster builds have platform strings (eg sm-warnaserr); the buildbot ones do not, they are "underneath" a regular platform like linux64.

I suspect #1 would not work. People generally want try to be a superset of what runs on mozilla-inbound, and complain loudly if something breaks after a green try push.

#2 would work fine for the buildbot jobs (which is currently most of them). But the try syntax parsing is done completely separately for taskcluster jobs, and there's a bunch of work to do on those for other reasons. So it'd be tough to do this for the taskcluster stuff.

For buildbot, the only real issue is that currently there really isn't anything sort of tag for the spidermonkey shell builds in the try syntax, and so we'd need to add some complexity to an already excessively complex (and insufficiently powerful) system. And it's to the part that is quickly becoming "legacy". But I still think it's doable (as in, not too hard to implement, not too much additional craziness as long as you can do it in a way that moves us towards a better final situation, and probably not *too* hard to convince the gatekeepers that it's useful enough to warrant the added complexity.)

On the other hand -- for your particular usage scenario, what if you pushed with -p none (or -p turtles or something, if it complains about -p none) and then added your talos job? I think that's supposed to automatically add in the prerequisite build job. So it would still be manual, but perhaps only a single step?

Comment 2

[Tooru Fujisawa [:arai]]

thanks.

how the situation will be changed when the transition to taskcluster done?
will we use same syntax, or different syntax for getting same set of builds?
If there's explicit syntax and it solves the unintentional resource consumption, it's okay for me to wait for it and just clicking treeherder buttons manually for now :)

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

FWIW, recently, my patch in bug 1325351 was backed out because of build failure on SpiderMonkey Compacting GC Shell Build on Windows (bug 1325351 comment 14).

This was not caught by a try build because try build doesn't trigger SM(cgc) build by default (because my patch touches only mfbt, nothing in js/src), and actually it seems there is no way to trigger that explicitly either according to comment 0.

I suggest we at least trigger SpiderMonkey builds when mfbt changes in addition to what we currently do. That should make it easier for people to work on mfbt.

Comment 4

[Emanuel Hoogeveen [:ehoogeveen]]

If changes to libs that SM depends on should trigger Try builds as well, then I think that means mfbt, nspr and mozglue, right? Used to be just mfbt and nspr, but I'm pretty sure we use some mozglue things these days. These areas don't change very often, so I don't think it would add a lot of load.

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #4)
> If changes to libs that SM depends on should trigger Try builds as well,
> then I think that means mfbt, nspr and mozglue, right? Used to be just mfbt
> and nspr, but I'm pretty sure we use some mozglue things these days. These
> areas don't change very often, so I don't think it would add a lot of load.

I'm not sure about the dependency, but I think that sounds like a good idea. But I guess it should be in a separate bug. Filed bug 1325936.

Comment 6

[Aki Sasaki (not active)]

Try syntax has been deprecated by ./mach try fuzzy.