Paul Biggar Reporter
	Description • 14 years ago

Spidermonkey shell builds can't be run on tryserver, probably because they only run on tryserver. Is there any way to allow this?

	Aki Sasaki (not active)
	Comment 1 • 14 years ago

(In reply to comment #0)
> Spidermonkey shell builds can't be run on tryserver, probably because they only
> run on tryserver. Is there any way to allow this?

I'm sorry, could you please clarify?
I'm going to guess "...can't be run on tryserver, probably because they only run on tryserver" contains a typo.

	Paul Biggar Reporter
	Comment 2 • 14 years ago

(In reply to comment #1)
> (In reply to comment #0)
> I'm going to guess "...can't be run on tryserver, probably because they only
> run on tryserver" contains a typo.

I'm sorry, that should be:

"Spidermonkey shell builds can't be run on tryserver, probably because they only
run on TRACEMONKEY. "

Apologies for the confusion.

	Chris Cooper [:coop] (he/him)
	Comment 3 • 14 years ago

Nearly had a conniption when I thought we were adding SeaMonkey to try. Changing the summary.

	Paul Biggar Reporter
	Comment 4 • 14 years ago

SM is the annotation that tbpl uses, apologies for the confusion.

	Phil Ringnalda (:philor)
	Comment 5 • 14 years ago

Hmm, wonder who decided to use that on tbpl, and whether or not he is known for amusing himself in just this sort of way?

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 6 • 13 years ago

This is a lot more work than just adding syntax to trychooser. The Spidermonkey builds are project builds that run against the Tracemonkey repo and are quite separate from the creating and scheduling of try builds which mimic the mozilla-central setup. So that means this bug requires a lot more time and effort which - given current resources and project plans/bug priorites - means that I'm putting this at a P5 for now since it is a "great to have" and certainly a project worth doing but not actively on my plate right now.  I will keep my name attached to it (unless someone else volunteers to work on it sooner) so that it doesn't get lost completely. Will revisit again when time permits.

	Paul Biggar Reporter
	Comment 7 • 13 years ago

Seems about right - thanks.

	Phil Ringnalda (:philor)
	Comment 8 • 13 years ago

Did this get a whole lot easier in the post bug 686578 world, now that SpiderMonkey builds are already being run against more than one repo?

Also, not sure how much of the difficulty comes in trychooser, but there's really no need to add them to it - just like with mozilla-inbound, any push that touches js/src/ ought to trigger them on any platform it asks for, so if it's easier to implement having -b d -p linux automatically trigger all the debug Linux SM builds if the push touches js/src/, that's actually better than requiring that people realize they should ask for them.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 9 • 12 years ago

Moving this to a RelEng mentored bug (or something to be fixed by RelEng as time and resources permit).

	Steve Fink [:sfink] [:s:]
	Comment 10 • 12 years ago

I'm interested in the answer to philor's question in comment 8. I can believe it might be more than a simple configuration change, but if so, I'd like to understand why?

Is there a way to experiment with this? I'll take a crack at doing this if possible.

	Steve Fink [:sfink] [:s:]
	Comment 11 • 12 years ago

From IRC:

<lsblakk> so it should be easy to turn on a spidermonkey_try project and have that report to try
<lsblakk> however, that means all pushes to try will use those resources on every push
<lsblakk> and that's something for releng to determine the pros/cons of

Ok, good. So here's my specific justification for this:

We are implementing a moving garbage collector. It requires a substantial change to the much of the code in the JS engine, and it's something that is difficult to get right and easy to accidentally break. Some of this breakage will be caught immediately by the compiler, but to catch as much of the rest as we can we've come up with a dynamic rooting analysis that will check most uses of the modified API at runtime, during the regular JS tests. We need that running regularly and visibly to prevent regressions, so we want to be visible by default.

But making it visible by default means that it's effectively a "tier 1 test", so it really needs to be available on the try server to avoid the situation where someone pushes to try, gets a fully green run, and then gets backed out when it burns the tree. Not to mention that the developer would then need to figure out the proper flags to explicitly test it on the tryserver, too.

That's the benefit side. The cost argument is that because this is platform-independent and debug-only, we only need it to run on one configuration. So we would only be adding a single linux64-debug test job per push. (linux-debug, or any other debug build, would work just as well.) If there's some way to restrict these builds to only happen when js/src is touched, as seems to be the case with the other spidermonkey jobs, that would be even better.

Note that Gecko code that uses the JSAPI will also need to be updated and kept correct, but we're not there yet and this change does not cover that case.

I am changing the bug title to reflect the restricted scope.

	Steve Fink [:sfink] [:s:]
	Comment 12 • 12 years ago

Oops, sorry. I forked off bug 775355 for the specific build we want (rooting analysis), since that is much more limited than this bug, and I don't want to redefine this one. Comment 11 was intended for the new bug.

	Steve Fink [:sfink] [:s:]
	Comment 13 • 12 years ago

I believe at this point you can run whatever JS shell builds you want on try, if you add the correct magic incantations to the config file. If not, CC me on a new bug and I can probably help you fix it.