The existing task's outcome is best achieved with a special purpose
build task, so here it is.
MozReview-Commit-ID: 3gYnAb69TdK
--HG--
rename : mobile/android/config/mozconfigs/android-api-15-frontend/nightly => mobile/android/config/mozconfigs/android-api-15-gradle-dependencies/nightly
rename : mobile/android/config/tooltool-manifests/android-frontend/releng.manifest => mobile/android/config/tooltool-manifests/android-gradle-dependencies/releng.manifest
extra : rebase_source : 252c283553d64bac17c2b922773023a349c297ea
extra : histedit_source : 2d8becbcdfa5d37829552e55b50fb7f9cbf56dea
This container formerly defined a special Gradle project for fetching
dependencies. This patch lays the ground-work to use the in-tree
Gradle project instead. Using the in-tree project looks like first
starting a local Nexus repository to collect downloaded dependencies
(before.sh); then running a build which populates that repository; and
then packaging up the downloaded dependencies (after.sh). The patch
after this will define the build which populates the repository.
Sadly there's no easy way to *inherit* from desktop-build, so this is
a copy-paste-modify clone.
MozReview-Commit-ID: Dd5Hj8hkJVk
--HG--
extra : rebase_source : dcfe245b23eb28e99b1506eebe053142c9e242b3
extra : histedit_source : f21014636de958c5ddf27ca2a1eb156e3c88bd78
This allows for the following syntax:
* -u mochitest-jetpack
Before this patch, jetpack could get scheduled with:
* -u all
* -u mochitest
MozReview-Commit-ID: 5CJnUZ7oSyD
--HG--
extra : amend_source : 6abaaf4eea69a1f607d81cd523aa501ee1a0678a
On a CLOSED TREE because this is Android and TaskCluster only.
MozReview-Commit-ID: Bde5IpY1gkr
--HG--
extra : rebase_source : 52eb5d6c1a5243540783c3ccc47a317857d2a2b7
extra : amend_source : 11d3339d21c75f9ebd8560e836293f211603b49a
Setting GRADLE_USER_HOME in this way ensures all Gradle invocations in
automation have the right flags, rather than just the ones we
remember.
MozReview-Commit-ID: IL53nZVsFuV
--HG--
extra : rebase_source : dafc3c19e75e067481603b6f80692fcea0141b67
This already had review, landed, and got backed out in Bug 1247375.
The backout was just a precaution; this should work fine, and be
scheduled just like android-b2gdroid is scheduled.
MozReview-Commit-ID: C3I7HOrcfFf
--HG--
extra : rebase_source : 015008a664851e93fea102c1515273aa030849cb
extra : source : 9f635a038f2c62eeb2310a81688169c66dcfb097
We can now define a list of "tags" for a task. Specifying "-j <tag>"
in Try syntax will run all tasks having that tag.
MozReview-Commit-ID: Ih9Z0tRZ5VA
--HG--
extra : rebase_source : 5d8bab98c2793ff3b71e36e7a4d14dca60bba46c
Firefox's automation currently tends to run all the jobs all the time.
It is wasteful to do this. For example, running ESLint when the commit
only changes a .cpp file adds no value.
This commit adds support for only running tasks when certain files
change. The new-style tasks introduced by the previous commit have been
taught a "when" dictionary property that defines conditions that should
hold for the task to be executed. We define a "file_patterns" list that
defines lists of mozpack path matching expressions that will be matched
against the set of files changed by the changesets relevant to the
changeset being built. The eslint task has been updated to only run if
files related to it change.
Because conditions may not be accurate, we add a CLI argument to ignore
conditions and force all would-be-filtered tasks to run.
MozReview-Commit-ID: 3OeBSKAQAeg
--HG--
extra : rebase_source : 9a7047c6f366250fc0feaee32b5fb7944dfdc7a7
Currently, tasks are either "build" or "test" tasks. And "test" tasks
are dependent on "build" tasks, so they are effectively an extension of
"build" tasks.
Not everything is a "build" task. Not everything is associated with a
specific platform.
This commit introduces support for defining non-build "tasks" under the
"tasks" top-level element of a jobs YAML file. Interally, they are
treated as "build" tasks but are declared differently.
By default, all these tasks run.
The -j/--job argument has been added to the try syntax parser. It
specifies an opt-in list of these non-build tasks to run. By default, it
runs all of them.
The eslint-gecko "build" task has been moved to this new mechanism.
Documentation for the new task type have been added.
There is definitely some wonkiness in this implementation. For example,
there are references to "build_name," "build_type," and "build_product,"
which arguably are no longer relevant to generic tasks. However, they
appear to be so integrated into task processing (including route names)
that I'm a bit scared to change them.
MozReview-Commit-ID: BY219tLFb6Z
--HG--
extra : rebase_source : 743f46a06404c0b31383de419dd6a8d207bafbb6
It is possible to hook up in-tree documentation to Sphinx. Convert the
one-off README.md to ReStructuredText and add it to the Sphinx docs.
I added a moz.build file under testing/ because I don't think it is
appropriate for the Sphinx directive to live in the root moz.build file.
MozReview-Commit-ID: 90tCb7mA63C
--HG--
rename : testing/taskcluster/README.md => testing/taskcluster/docs/index.rst
extra : rebase_source : 9312445aa17a1a2b03195a4f18442f8a8a0d8fe9
We're about to introduce a mechanism to influence which tasks run based
on what files change. To help debug what's happening, print out the list
of commits that influence the task selection.
MozReview-Commit-ID: Kfj2pf1PSIS
--HG--
extra : rebase_source : f8f76056e34c1ee2a7cf936464f2cd44d4838496
Over in bug 1247802 we deployed a new JSON web API on hg.mozilla.org
that returns JSON metadata for changesets that are relevant for build
automation. It returns a superset of what is returned by the pushlog
JSON API. So we switch to it.
MozReview-Commit-ID: 6X3NANo1mgq
--HG--
extra : rebase_source : 09249a7be3d46eee5c86bb696243b047da424239
In preparation for adding more content that isn't strictly related to
pushlog info.
MozReview-Commit-ID: I4c8KAutUDm
--HG--
extra : rebase_source : 590e940999207e2b20f3921889bf0acee54b1258
Before, we attempted to build and query a URL that potentially had
"None" in it. This printed some wonky messages in the log and may have
contributed to added latency due to the HTTP request that was doomed to
fail.
MozReview-Commit-ID: JrR5PK33vCn
--HG--
extra : rebase_source : 8fcbb2216cf3c6379865b8a2314ead9307175fd2
requests should *always* be used for performing HTTP requests because it
has a better API *and* has sane security defaults compared to the HTTP
request APIs in the Python standard library. Although, Python 2.7.9+
does have slightly saner defaults in the standard library. I still trust
requests more.
MozReview-Commit-ID: GqohpfYYGBw
--HG--
extra : rebase_source : e6850a80818d73205a22ea4ba92be9e0ec43a473
The function will soon query something that isn't limited to pushlog
info. Rename it accordingly.
MozReview-Commit-ID: 68UrMmLYARD
--HG--
extra : rebase_source : 9f63474301f64661fd16e5cef9dd2adfcfc36a40
* e10s to be just before the chunk info (suite_name-e10s-{{chunk}})
* include {{chunk} for chunked jobs
TODO: We need to follow up by making the gecko decision task impose the naming
MozReview-Commit-ID: 77T9q0sAIWg
