Now that Aaron is getting close to getting e10s a11y support ready for widespread testing, we need to get automated tests running in automation. Explicit non-goal for this bug: splitting up non-e10s mochitest-other across all platforms. We should probably consider doing that soon to avoid confusion, but we can take care of this bug without having to do that.
To the people CCed: feel free to add any other deps you want.
Getting this running on Taskcluster is apparently trivial. So that's awesome. https://treeherder.mozilla.org/#/jobs?repo=try&revision=2e09e0469bf62bafe4b72e7bef3f1c6092072ff7
except that is linux only- but a start!
Yeah, good enough for ensuring that they're not completely and utterly broken before I embark on the buildbot end of things.
Ryan, is there anything for my team to do here?
This got held up a bit by questions about how useful M-e10s(a11y) would actually be. I'll try to work on it soon, though.
Finally got Linux working with some hacks. And they're currently busted. https://treeherder.mozilla.org/logviewer.html#?job_id=29806780&repo=try Though I'm still a bit confused about what I'm seeing in the logs. As expected, the beginning of the run shows "runtests.py | Running with e10s: True" in the logs, but at the end of the run, I still see "INFO Mode: non-e10s". Not entirely sure what to make of that :\
After a number of discussions with various accessibility people, the unanimous conclusion is that there isn't any value in trying to stand up M-e10s(a11y). It won't effectively test cross-process things anyway and time is better-spent on adding more browser-chrome tests to the ones that are already there.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.