In order to speed up builds. This is on the schedule for Q1 build system work.
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.
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.
You shouldn't hit different code paths if you, at the same time, make the zip archives use the same directory structure.
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.
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.
You need to log in before you can comment on or make changes to this bug.