This uses the email provided by mozilla-taskcluster to find who to
email about failed decision tasks. It also adds some validation of
the try syntax that we've previously ignored.
Any platforms or build types specified in try sytax that don't exist
in the full task graph will throw an error.
MozReview-Commit-ID: JOKkLle7hEe
--HG--
extra : rebase_source : 65299c95c60bcb3c6a295b1f8f2f18477c2852db
this patch:
- adds linux{32,64}-nightly/opt test platforms that mirror the non-nightly test platforms.
- adds an `include_nightly` per-project parameter; this is refered to in the default `target_task_method`. It's still possible to launch custom `target_task_method`s to trigger nightlies against, say, try.
- adds a `filter_for_project` method in `target_tasks.py` that allows for `include_nightly` and `run_on_projects` filtering in the various `target_task_method`s.
- adds nightly filtering into the `TryOptionSyntax` object. By default, this will be off. To trigger nightly tests on try, either submit a new decision task with a different `target_task_method` (e.g. `nightly_fennec`) or flip the `include_nightly` flag to True.
- adds the `nightly` attribute to tests if their builds have that attribute.
MozReview-Commit-ID: DttIZH0BHS2
--HG--
extra : rebase_source : d8acbe4c741f570b2e8d33a8e6a7f5c791b24ff6
This fixes the ability to run mozbase via `-j mozbase`, with the
added advantage that it will obey `-p` too.
MozReview-Commit-ID: 1zkitUephXk
--HG--
extra : rebase_source : 0ebb65363d5f5813bc7ccb379768df54310d39c1
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
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
-w, --taskcluster-worker: schedule taskcluster-worker jobs.
This is necessary to relieve the load of the small pool of data center
machines.
MozReview-Commit-ID: IiOLHUs2ALi
--HG--
extra : rebase_source : 96acbbd40aef856f68c7ab94ae23bcee4f2f078d
We parse_message needs to return an args object even if try commit
message is empty.
MozReview-Commit-ID: BPWvzjAyjHX
--HG--
extra : rebase_source : 57a699e95e55eabaad3e6a7596086c7f06248e91
We add the following command line options to Taskcluster try syntax:
--spsProfile - enable profile mode.
--rebuild-talos <N> - retrigger talos tests N times.
--setenv <VAR>=<val> - add extra environments variables.
--tag <TAG> - run tests only the tag TAG.
--no-retry - doesn't retry failed jobs.
We have a chicken-egg problem, as we first generate the full task graph
and then parse the try message. But the graph generation step needs to
know the try message to process the aforementioned options. The
solution is to parse the message before graph generation and then
pass the command line options to the transforms. Then, each transform
can look at the option that interests it and process it accordingly.
The message parse function is configured in kind.yml, which gives some
flexibility for future implementations of alternative syntaxes.
MozReview-Commit-ID: GPFdi0FD6Vn
--HG--
extra : rebase_source : b992786158851f1099aedfce8669a163228edc51
We add the following command line options to Taskcluster try syntax:
--spsProfile - enable profile mode.
--rebuild-talos <N> - retrigger talos tests N times.
--setenv <VAR>=<val> - add extra environments variables.
--tag <TAG> - run tests only the tag TAG.
--no-retry - doesn't retry failed jobs.
We have a chicken-egg problem, as we first generate the full task graph
and then parse the try message. But the graph generation step needs to
know the try message to process the aforementioned options. The
solution is to parse the message before graph generation and then
pass the command line options to the transforms. Then, each transform
can look at the option that interests it and process it accordingly.
The message parse function is configured in kind.yml, which gives some
flexibility for future implementations of alternative syntaxes.
MozReview-Commit-ID: DMwRjuV2vpf
--HG--
extra : rebase_source : 211ecf52694078986caf290c5b0cca35c775da61
We add the following command line options to Taskcluster try syntax:
--spsProfile: enable profile mode.
--rebuild-talos <N>: retrigger talos tests N times.
--setenv <VAR>=<val>: add extra environments variables.
--tag <TAG>: run tests only the tag TAG.
--no-retry: doesn't retry failed jobs.
We have a chicken-egg problem, as we first generate the full task graph
and then parse the try message. But the graph generation step needs to
know the try message to process the aforementioned options. The
solution is to parse the message before graph generation and then
pass the command line options to the transforms. Then, each transform
can look at the option that interests it and process it accordingly.
The message parse function is configured in kind.yml, which gives some
flexibility for future implementations of alternative syntaxes.
MozReview-Commit-ID: EQlE6q5E8z7
--HG--
extra : rebase_source : 4b7323cd915e8ef9820816015b4b45524811eaf1
While we don't have physical machines running taskcluster-worker, we
want to schedule talos tests on Taskcluster and run them on buildbot.
buildbot-bridge acts as a worker that runs its tasks in buildbot
machines. Any talos task is redirected to buildbot-bridge.
MozReview-Commit-ID: Im9IhhT0Mr1
--HG--
extra : rebase_source : ede38a683abdf411612e885f6985c79b0532cb46
This commit introduces support for performing build and test variations
with Stylo enabled.
From a high level, this is similar to the e10s/non-e10s variations that
we currently run. However, it is different in that Stylo is a build
time (not run time) flag. So, we need to perform separate builds for
Stylo.
In the current implementation of the task graph, we can either
introduce a new platform or a new build type/configuration. I've
chosen to introduce a new platform if nothing else so the Treeherder
results clearly separate Stylo from non-Stylo. This decision can be
revisited in the future once Stylo becomes more stable and visible
outside the "stylo" repository.
Stylo functionality is limited to layout functionality and Stylo
developers aren't very interested in many tests not related to layout
at the moment. So we introduce a new test set running a limited
functionality of tests in Stylo builds.
In the current state of this commit, Stylo builds will permafail.
This is because Stylo builds require a vendored copy of Servo. Logic
for pruning the task graph of Stylo/Servo related tasks will be
implemented in subsequent commits.
MozReview-Commit-ID: JivhkpXDjIw
--HG--
extra : rebase_source : fdc9a5300c0bfa27133478fc456bc618f26fb9b2
Job tasks are tasks that are not tied to a specific build or test. As such, they cannot be scheduled
with the regular -p/-u try syntax options. There exists a -j try syntax option, to schedule them, which
defaults to running "all" of them if not specified.
However, there is a bug here where they will only default to "all" if a try syntax exists in the commit
message. They will not be considered if a developer pushes to try without a try syntax. This happens
because self.jobs is initially initialized with '[]' and we use None to determine when to schedule "all"
later on.
I want to move towards a world without try syntax, so we should start improving the UX of the no try
syntax use case.
Note: When I say "schedule" here, I mean added to the target set. They may still be optimized away.
MozReview-Commit-ID: 4TrC84RGiaL
--HG--
extra : rebase_source : 8fd50113c37745bc10181e1311cc62d75485723a
This definitely isn't all of it. But I got the obvious chunks. Still
need to clean up mozharness.
MozReview-Commit-ID: JTZBydP3i2r
--HG--
extra : rebase_source : 782401359036751896ef6c153a81a06cb14031bb
This patch prevents tests which have the 'run_on_projects' attribute assigned to an empty set from running when the try message contains '-p all' and '-u all' together. It also makes the 'match_test' function a little more readable and updates the 'attributes.rst' document to reflect the changes that were made.
MozReview-Commit-ID: IMk0cmSza8U
--HG--
extra : rebase_source : 06d542cbec16bd8091bc282ad1b831fb4671e72a
If you want to run tests on Linux32 and Linux64, you use trychooser syntax like
"-u all[Ubuntu]" which taskcluster supports, but if you also built ASan, and
want tests on ASan, there's no supported documented way to get them. That sounds
like an edge-case, except that to get tests to run on WinXP or Win8 you have to
explicitly list them, so to get tests on every platform you build you have to
list all of them, and if ASan is one of them you have to somehow know to dig
around in the .yml and to know that linux64-asan is the thing to dig out.
MozReview-Commit-ID: 2REf0cUWmK8
--HG--
extra : rebase_source : cb77ff3e016939c94ac05964a6db809fe10aaa1a
The trychooser website advertises 'Android 4.3' as the alias to choose Android
tests in [] syntax, but without support for that in taskcluster, someone who
wants both opt and debug tests would need to guess, with no support or
documentation, that they should use [Android 4.3,android-4.3-arm7-api-15]
MozReview-Commit-ID: 4rEKcvqAfDH
--HG--
extra : rebase_source : 336d3a787569e14e5ae8608902e6e557ef2ce6c3
This leaves a lot of room for improvement, but gets the job done for now.
MozReview-Commit-ID: HmeTxZjOfOb
--HG--
extra : rebase_source : b6f55134c25cb670409e906da1acc7c0bd8d0dc0
This has some notes for future work on the task, but will work for now.
MozReview-Commit-ID: 7J4tQeKj3KJ
--HG--
extra : rebase_source : d171b5393fa340a47927e8b89ece93392ff23e56
