Ryan VanderMeulen [:RyanVM] Assignee
	Description • 8 years ago

Currently, we run Win8 e10s tests on Ash, Try, and the release branches only due to capacity constraints. With WinXP support being dropped in 53+, this gives us the ability to rebalance our test machine pool and significantly increase Win8 capacity. Win8 is a high-value target to run tests on since it's our only supported platform with D2D/DWrite enabled at the moment. Let's get the tests running everywhere.

	Ryan VanderMeulen [:RyanVM] Assignee
	Comment 1 • 8 years ago

While I could have resorted to similar gross hackery for enabling Win8 tests in the same vein as what we've historically done in such situations, I decided it was high time to clean up and refactor the code for scheduling buildbot e10s tests. There are a few somewhat-unrelated changes here which I'll note when I attach the builder diff, but they were mostly made as part of this patch to allow for greater overall simplification of the e10s logic.

	Ryan VanderMeulen [:RyanVM] Assignee
	Comment 2 • 8 years ago

As mentioned in the previous comment, there are a few bonus changes in this diff that were made to simplify the overall e10s part of the patch.

They are:
* Use the chunked mochitest-gl across all branches. We were already using them on 50+, so in practice this only affects esr45.
* Turn off buildbot ASAN tests on Gecko 50+. This was previously being done for 51+ in favor of exclusively running TC jobs. On mozilla-release where Gecko 50 now resides, we still run TC-based builds and tests, albeit as Tier 2. That said, I've gone through the jobs we run and have confirmed that everything we care about is still running on that infra, so I don't foresee any real downsides to this change.
* Split debug e10s reftests into 2 chunks on OSX and Windows. They're currently running ~90min unchunked, so this seems like a worthy change to make anyway.
* Turn off buildbot-based Linux e10s reftests. They're already hidden across all trees anyway due to the GTK3 issues that have since been resolved in Taskcluster. Might as well save the resources and complexity by not bothering to schedule them at all.

One small downside at the moment is that this will also temporarily reduce the number of Linux debug mochitest (non-e10s) chunks from 8 to 5, which isn't great. Same story for some unaccelerated reftests. The logic that was implementing that was unfortunately crammed in with some e10s-related stuff. I could have fixed it in this patch, but decided it would be cleaner to do in a separate bug instead. And esr45 badly needs better Linux debug chunking in a few suites anyway.

	Justin Wood (:Callek)
	Comment 3 • 8 years ago

Comment on attachment 8810688 [details] [diff] [review]
refactor buildbot e10s test scheduling

Review of attachment 8810688 [details] [diff] [review]:
-----------------------------------------------------------------

This is a nice cleaning up, but the builder diff has a *lot* of additions.

I'm slightly concerned on capacity with those additions, ... any way we can get jmaher to speed up gathering of SETA data with regard to these new test sets?

	Ryan VanderMeulen [:RyanVM] Assignee
	Comment 4 • 8 years ago

My intent is to wait until we can rebalance the Win8 pool now that our WinXP testing needs are greatly reduced. I'm thinking we can add at least another 100 machines to the pool, which should alleviate this. We'll still have regular coalescing as needed too.

Probably a bigger concern is if/when we can make Win8 try_by_default again, but I'm happy to kick that can down the road for now!

	Ryan VanderMeulen [:RyanVM] Assignee
	Comment 5 • 8 years ago

Comment on attachment 8810688 [details] [diff] [review]
refactor buildbot e10s test scheduling

https://hg.mozilla.org/build/buildbot-configs/rev/56e5526a318ce0b75fddab322cd93f5314683e91

	Release Engineering SlaveAPI Service
	Comment 6 • 8 years ago

In production: https://hg.mozilla.org/build/buildbot-configs/rev/56e5526a318c

	Ryan VanderMeulen [:RyanVM] Assignee
	Comment 7 • 8 years ago

It's been a bit bumpy (some frequent GPU process assertions and RDM permafail), but everything's settled down now.