The default value for run-on-projects is "all." Many of the tasks
changed in this commit were defining "run-on-projects" to
integration+release, which is essentially all (notably missing "try"). I
can't think of a good reason to not schedule these lint tasks on all
repos by default. So just do that.
MozReview-Commit-ID: EowUGNzC7K3
--HG--
extra : rebase_source : 563abb0059e833881c8d484113aa9ee773b9af27
These are integration tests for testing the mochitest framework itself.
MozReview-Commit-ID: Jqyhbj7nC6z
--HG--
extra : rebase_source : 484405796e02015bcb500b096c02b310fafb9da4
To date we have variously specified both worker-type and worker-implementation,
often manually coordinated. We also embedded a few awkward assumptions such as
that the native engine only runs on OS X.
But a worker type has one and only one implementation, and that implementation
is stable over time (as changing it would require simultaneous landings on all
trees).
Instead, this change makes worker-type the primary configuration, and derives
both a worker implementation (defining the payload format) and worker OS
(determining what to include in the payload) from that value. The derivation
occurs when deciding how to implement a particular job, where the run_using
functions are distinguished by worker implementation.
The two-part logic to determine how and where to run a test task based on its
platform is combined into a single transform, `set_worker_type`.
This contains some other related changes:
- MOZ_AUTOMATION is set in specific jobs, rather than everywhere docker-worker
is used
- the URL to test packages is factored out into a shared function
- docker-worker test defaults are applied in `mozharness_test.py`
- the WORKER_TYPE array in `task.py`, formerly mixing two types of keys, is
split
- the 'invalid' workerType is assigned an 'invalid' implementation
- all tasks that do not use job descriptions but use docker-worker, etc. have
`worker.os` added
Tested to not produce a substantially different taskgraph for a regular push, a
try push, or a nightly cron.
MozReview-Commit-ID: LDHrmrpBo7I
--HG--
extra : rebase_source : 4cdfe6b8d9874b0c156671515b213d820b48482f
Automation is now largely using Mercurial 4.1 with some lagging
components still on 3.9 and a very small sliver of random parts
still on 3.7.3. Let's update the mozharness tests to match what
automation is using.
FWIW, the Mercurial tests still pass on 3.9.
MozReview-Commit-ID: BgZVDcx29mf
--HG--
extra : rebase_source : edb8516491fe9ef616b1ad797be2fc02a89c2829
Editors generally look for configurations at the top level of a project. For ESLint, they also look for the specific binary in node_modules before defaulting to the system binary. Whilst you can override the location, generally it doesn't work well when switching between projects.
The custom in-tree libraries make setup of a system ESLint more difficult as well.
Therefore to make it simple for developers to pick up the ESLint integrations with Editors, by moving the package.json and associated node_modules to the top-level directory.
MozReview-Commit-ID: 1pQpd7hTQ61
--HG--
rename : tools/lint/eslint/npm-shrinkwrap.json => npm-shrinkwrap.json
rename : tools/lint/eslint/package.json => package.json
extra : rebase_source : 9d69d791f86b5c55b1fcd5f6449f0ab84e56b05c
b2gtest uses *.xlarge instances, so it seems a reasonable substitution.
MozReview-Commit-ID: Ev6tnNpx13c
--HG--
extra : rebase_source : 87184b182d1428f041a5ae36e465d72dee6f7621
This fixes a regression introduced in Bug 1335873, which changes the mozbase
packages.txt to call mozlog's setup.py. Calling setup.py registers the
pytest_mozlog plugin for marionette-harness tests.
Instead, we can register the pytest-mozlog plugin via command-line arguments
to pytest, which are set in pytest.ini for the marionette-harness tests.
As a result, we can revert the mozbase packages.txt to not refer to mozlog's
setup.py
I'm leaving the pytest entry-point in mozlog's setup.py so that external
consumers don't have to register the pytest_mozlog plugin manually.
MozReview-Commit-ID: I5wNq5H1x3X
--HG--
extra : rebase_source : 614a47995bc1655f36053d2a05b08f94bfdbe476
Instead of using a class's static method, use a simple function, specified by
the `loader` key.
MozReview-Commit-ID: IeOl9qiSCXf
--HG--
extra : rebase_source : 72e0a9dd8385b250a46c9f4adf8a8a0e5b01c156
This clears up some confusion and undocumented behavior around platforms in
source-tests (and available to any job).
With this change, the attributes come out like this:
"source-test-mozbase-linux64/opt": {
"attributes": {
"build_platform": "linux64",
"build_type": "opt",
"kind": "source-test",
"run_on_projects": [
"integration",
"release"
]
},
MozReview-Commit-ID: HN1Zi8YUf0
--HG--
extra : rebase_source : 552bffc4646a3eec46e7edb508d8eb4d2a8e2e03
This formats the marionette-harness python tests to be a regular |mach python-test| suite. Though
we add subsuite=marionette, this is just for automation purposes. The new preferred way to run the
marionette harness tests locally is:
./mach python-test testing/marionette
They will also run if running the full suite.
The mozbase packages.txt file modifies mozlog to use 'setup.py' instead of 'pth'. The reason for
this is that the marionette-harness tests use the pytest_mozlog pytest plugin for formatting
their results (converts pytest format into something resembling the standard tbpl logging format).
In order for this plugin to get picked up however, mozlog's setup.py file needs to be processed.
MozReview-Commit-ID: Ata99evHxbd
--HG--
extra : rebase_source : 22382e3d65ce8454a1682cfced0d03477762e8fe
This formats the marionette-harness python tests to be a regular |mach python-test| suite. Though
we add subsuite=marionette, this is just for automation purposes. The new preferred way to run the
marionette harness tests locally is:
./mach python-test testing/marionette
They will also run if running the full suite.
The mozbase packages.txt file modifies mozlog to use 'setup.py' instead of 'pth'. The reason for
this is that the marionette-harness tests use the pytest_mozlog pytest plugin for formatting
their results (converts pytest format into something resembling the standard tbpl logging format).
In order for this plugin to get picked up however, mozlog's setup.py file needs to be processed.
MozReview-Commit-ID: Ata99evHxbd
--HG--
extra : rebase_source : 16ed70edd38a53c3279d8632d7cba3df4d5216c3
Currently 'run_task' tasks have no easy way to depend on a build task. For example, some
python unittests need a Firefox binary for their tests, like the mozrunner tests and future
test harness selftests (like mochitest tests).
This patch allows kinds to add a new key to the kind config which maps test platforms to
build-labels. Then 'run_task' jobs can add a 'requires-build': true field to get a build
dependency automatically added. The build artifact url will also be stored in the
$GECKO_INSTALLER_URL environment variable on the test host.
MozReview-Commit-ID: Jqyhbj7nC6z
--HG--
extra : rebase_source : 2f44b6c94f35a0d2e11464cf773e821ae6fe8538
The name 'source-check' is a bit of a misnomer, because it already includes a bunch
of tasks that are proper unittests, not lints. Some of these unittests will soon
depend on a build task, which makes 'source-check' feel even more wrong.
They still have a lot in common with the lint tasks though, so it's probably not
worth splitting this into two separate kinds. Instead, let's just rename this kind
to 'source-test', which means, any task that tests stuff and is run from the source
directory (instead of a tests.zip). I think both lints and python-tests fall squarely
under this definition.
MozReview-Commit-ID: K0gZ5rVLyeD
--HG--
rename : taskcluster/ci/source-check/doc.yml => taskcluster/ci/source-test/doc.yml
rename : taskcluster/ci/source-check/kind.yml => taskcluster/ci/source-test/kind.yml
rename : taskcluster/ci/source-check/mozlint.yml => taskcluster/ci/source-test/mozlint.yml
rename : taskcluster/ci/source-check/python-tests.yml => taskcluster/ci/source-test/python-tests.yml
rename : taskcluster/ci/source-check/webidl.yml => taskcluster/ci/source-test/webidl.yml
extra : rebase_source : a683b5b6e243849de57f2681993046c776d6a8f2