Closed Bug 1136385 Opened 9 years ago Closed 8 years ago

schedule talos e10s on trunk branches in forced coalescing mode

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(e10s+)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
e10s + ---

People

(Reporter: jmaher, Unassigned)

References

(Blocks 1 open bug)

Details

right now we only run talos e10s on mozilla-central pgo.  This isn't useful and the sheriffs will hide it because it doesn't meet their tier 1 status.

I would like to schedule talos e10s on all trunk branches, but force it to be coalesced (as we do for debug tests - and possibly soon osx 10.10 / SETA stuff).

This would let the e10s data be run every few builds (ideally once/hour or as needed) to help conserve resources.
I don't think the coalescing implemented in bug 1056787 has been implemented for talos.  So it might make sense to implement this as part of SETA work since this code is currently being refactored.
current state of things- we run talos e10s on linux/win pgo builds on mozilla-central only (hidden).  In addition for all osx 10.10, we run e10s jobs on m-c as well.

The question is- what do we want to get out of more coverage?  Right now we get alerts on e10s (although they are identical to the non-e10s) from m-c.  This gives us tracking.  Ideally we care about finding a regression without bisecting 120 changesets- at least on linux/windows we are not seeing anything different than non-e10s.
I'm pretty sure this bug is no longer valid, we've been running talos e10s alongside the non-e10s jobs for a while now. Re-open if I'm wrong.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.