Duplicate compacting GC builds happening on try

NEW
Unassigned

Status

()

Core
JavaScript: GC
P3
normal
a year ago
5 months ago

People

(Reporter: jonco, Unassigned, NeedInfo)

Tracking

({triage-deferred})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
Compacting GC builds are always configured with --enable-debug:

https://dxr.mozilla.org/mozilla-central/source/js/src/devtools/automation/variants/compacting#2

At the moment we do CGC builds for both debug and opt configurations on Windows on try, e.g.:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f5c6ad69203a

This is a waste if they both end up being the same build. 

It seems like we always want to --enable-optimize otherwise the tests take to long.  I guess this is why CGC builds generally appear as part of the opt build series for a platform.

On inbound, we don't seem to do SM builds on Windows or OSX at all, or at least I couldn't see any:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=d9dd5cab64b250cb706e4eb3b1cc8179bb65eb8f

That also seems worrying!

On central we don't do any SM builds on OSX, but we do have a Windows debug CGC build:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=feb1c52ebe9ef8cff09dea275aa06d9441f5fe93

I think we should do all our CGC builds in either the debug or the opt series and be consistent.  We should also remove the CGC builds from Windows debug on try.  (Maybe we should do more SM builds on inbound too, but that's probably outside the scope of this bug).
(Reporter)

Comment 1

a year ago
Steve, I'm needinfoing you because I think you understand how this is set up.  Does the above make sense?
Flags: needinfo?(sphink)
Keywords: triage-deferred
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.