Employ mozharness for Puppeteer tests
Categories
(Remote Protocol :: Agent, task, P3)
Tracking
(Not tracked)
People
(Reporter: ato, Unassigned)
References
Details
We do not currently use mozharness when running the Puppeteer tests. This means we can’t use TaskCluster test tasks.
Instead we use a source task that calls ./mach puppeteer-test directly:
https://searchfox.org/mozilla-central/rev/053826b10f838f77c27507e5efecc96e34718541/taskcluster/ci/source-test/remote.yml#21-29
This has the downside of using shippable Firefox builds with PGO enabled instead of the normal non-PGO builds. This means we often build Firefox twice when testing the remote debugging protocol: once for browser-chrome tests (B) and once for remote(pup) in Bpgo(B).
There are also some TaskCluster niceities available to test tasks that we don’t have access to, such as test variants for running Fission and so on.
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
Personally I'd like to move away from mozharness and more towards a model like the puppeteer tests use. I find mozharness is needlessly complex for what it is doing (basically just downloading and extracting artifacts). So if it were up to me I'd prefer you not solve this bug :).
I do realize this puts extra burden on you and your team as things like enabling fission haven't been proved out yet. So I won't stop you from going through with this :).
|
|
Reporter | |
Comment 2•5 years ago
|
||
I’m obviously very happy not to do any work (-;
The reason I didn’t do the mozharness work originally is the amount of quite fragile boilerplate it involves writing. If we are eyeing a future where the actual shell script commands are defined right there in the TaskCluster configs, it would make me very happy.
Description
•