Closed
Bug 647405
Opened 14 years ago
Closed 12 years ago
Run SpiderMonkey shell builds on Try
Categories
(Release Engineering :: General, enhancement, P5)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: paul.biggar, Unassigned)
Details
(Whiteboard: [tryserver][mentor=lsblakk])
Spidermonkey shell builds can't be run on tryserver, probably because they only run on tryserver. Is there any way to allow this?
Updated•14 years ago
|
Component: Tinderbox → Release Engineering
Product: Webtools → mozilla.org
QA Contact: tinderbox → release
Version: Trunk → other
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.
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.
Updated•14 years ago
|
Comment 3•14 years ago
|
||
Nearly had a conniption when I thought we were adding SeaMonkey to try. Changing the summary.
Summary: Add trychooser syntax for SM builds → Add trychooser syntax for Spidermonkey builds
Reporter | ||
Comment 4•14 years ago
|
||
SM is the annotation that tbpl uses, apologies for the confusion.
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?
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.
Severity: normal → enhancement
Priority: P3 → P5
Reporter | ||
Comment 7•13 years ago
|
||
Seems about right - thanks.
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.
Comment 9•12 years ago
|
||
Moving this to a RelEng mentored bug (or something to be fixed by RelEng as time and resources permit).
Assignee: lsblakk → nobody
Component: Release Engineering → Release Engineering: Developer Tools
QA Contact: release → lsblakk
Whiteboard: [tryserver] → [tryserver][mentor=lsblakk]
Updated•12 years ago
|
Summary: Add trychooser syntax for Spidermonkey builds → Run SpiderMonkey shell builds on Try
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.
Updated•12 years ago
|
Updated•12 years ago
|
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.
No longer blocks: 773059
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.
Updated•12 years ago
|
QA Contact: lsblakk → hwine
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Assignee | ||
Updated•7 years ago
|
Component: Tools → General
You need to log in
before you can comment on or make changes to this bug.
Description
•