1234645 - Run mochitests from the source dir locally

Status: NEW

(Firefox Build System :: General, defect)

Description

[Chris Manchester (limited bugmail, email directly)]

In order to speed up builds. This is on the schedule for Q1 build system work.

Comment 1

[Chris Manchester (limited bugmail, email directly)]

I have a version of this for browser-chrome tests in https://treeherder.mozilla.org/#/jobs?repo=try&revision=760b341a6864 (the red builds are just a check test that needs updating).

This takes the approach mentioned in bug 1234728 of leaving the test packages as-is and considering this an improvement for those running tests locally. Getting a checkout of m-c on the testers and just running |./mach mochitest| from there is a worthy goal, but we may consider this patch a worthy intermediate step.

The patch is pretty simple:

* When running locally, the topsrcdir is registered as a chrome directory, available under "chrome://mochitest-tests/", and tests are loaded from that prefix.
* Support files are still installed to the objdir and available from "chrome://mochitests/", and tests locating them with chrome-harness.js:getRootDirectory are directed back to "chrome://mochitests/". This will help keep tests from assuming they have arbitrary sourcedir files available -- they will not when they're running from the test package!
* Test files are packaged in test_archive.py based on the contents of all-tests.json (doing a diff, the before/after packages are identical).
* A couple of checks are added to the js and python harnesses to munge paths when we're running locally.

And everything else stays the same. Tests finding files based on their test path can still get into trouble when running locally, we'll need to update each of these (toolkit/mozapps/extensions/test/browser/head.js is one I noticed and fixed in the initial patch). Pretty much anything using gTestPath without going through getRootDirectory will have this problem, but this isn't that many tests.

Something similar for plain should work -- it looks like we can register each test in the sourcedir as a path with httpd.js when running locally, and keep support files served from the objdir.

Comment 2

[Chris Manchester (limited bugmail, email directly)]

A reservation I have with this approach beyond requiring modifications to an unknown number of test files is that by introducing a different code path for those running locally, we are opening the door for this code path to regress for certain tests or local configurations without detecting it in automation. And once we reach the state of running from a source tree we'll need to tear all of this out anyway. A more straightforward stop-gap in the direction of optimizing install manifest processing may be effort better spent.

Comment 3

[Mike Hommey [:glandium]]

You shouldn't hit different code paths if you, at the same time, make the zip archives use the same directory structure.

Comment 4

[Chris Manchester (limited bugmail, email directly)]

I suppose we could have a special directory in the test archive containing all the tests available from "chrome://mochitest-tests/" in the scheme from comment 1, and the code paths would be very close.

Comment 5

[Chris Manchester (limited bugmail, email directly)]

Here's comment 4 on automation: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c861d1981cf5

Only linux has completed so far, ~2 tests per chunk need fixing.