This patch creates a new `filter_beta_release_tasks` function. By
pulling this logic out of `mozilla_beta_tasks`, we can reuse it in the
release promotion `target_tasks_method`s.
MozReview-Commit-ID: Kwk3jgtooCS
--HG--
extra : rebase_source : f932f56c40afb39c23233ef885fe7ed45d350e7a
- Building is nightly channel only. Beta and release for Fennec 58 don't build
stylo. It means that the package size for 58 beta/release isn't incremented
by this change.
- The preference for stylo is still turned off Nightly 58. It will be turned on
59 after fixing some bugs for crashtests and etc. Our target to enable stylo
for Android is 59.
- ./mach bootstrap already installs clang etc to build stylo and bindgen.
Developers for mobile won't require additional build options for this change.
MozReview-Commit-ID: CIpYl8I5d7x
--HG--
extra : rebase_source : 6387704e4a94db080d4add10298cf1cc254ddec0
A lot of effort has been spent optimizing VCS operations for peak
performance. But not utilizing caches or volumes for the VCS store
or checkouts can undermine that work.
Let's print a warning when VCS is configured sub-optimally.
I'm pretty sure we still have some rogue tasks not using caches
or volumes. We can convert this to a fatal error once those are
fixed.
MozReview-Commit-ID: C6CT1zViy75
--HG--
extra : rebase_source : 91760250bed263c789b95d16cc0542a53ca2bfbf
This seems like a reasonable thing to enforce.
MozReview-Commit-ID: 3BZQSkwRYeN
--HG--
extra : rebase_source : 8dae62edb35202da0f0e90ddec3eacb212ada371
We introduce a per-cache .cachelog file containing important events
in the cache's history such as creation, requirements adjusting,
and utilization. If cache validation fails, we print the cache log.
If a previous task was responsible for getting the cache in a bad
state, its TASK_ID should be printed, allowing us to more easily
identify mis-configured tasks.
MozReview-Commit-ID: BJun5Hi5w0s
--HG--
extra : rebase_source : f4758741ee294a0de53882b6891b473c01463e28
This is needed to prevent parameter mismatch errors when using |mach try fuzzy|
from an older revision. This can happen if the parameters.yml is being
downloaded from a commit with a recently added parameter.
MozReview-Commit-ID: 4NxCM7i8B4W
--HG--
extra : rebase_source : c47de38ad295e14c80c99806ea430fa641ae2be6
This is needed to prevent parameter mismatch errors when using |mach try fuzzy|
from an older revision. This can happen if the parameters.yml is being
downloaded from a commit with a recently added parameter.
MozReview-Commit-ID: 4NxCM7i8B4W
--HG--
extra : rebase_source : 4d2052aae33292fbd7928a79bfedba76426206b9
moz.configure files are covered by flake8. Earlier today, my push
in bug 1411784 didn't run flake8 and a flake8 failure was uncovered
by a subsequent push that touched a .py file.
MozReview-Commit-ID: HzL8wOQaqRC
--HG--
extra : rebase_source : 1091be0bab2f2a23cdbaaa3d6b52072693f5f356
When first introduced, test-verify was only run when .js/.html/.xul/.xhtml files
were changed. Recently, it seems to run on every push. This is a speculative fix:
There may be confusion between "test-verify" and "test-verification" so I am
using "test-verify" consistently.
We now have a "source" task that produces JSON files with per-file
Bugzilla components and a list of files missing a declared Bugzilla
component. gzip variations are also produced.
The files are published in the index so clients can query e.g.
gecko.v2.mozilla-central.latest.source.source-bugzilla-info/public/components.json
and get the latest metadata. This should help alleviate the need for
querying the moz.build evaluation API on hg.mozilla.org - or at least
facilitate bulk queries of the data from a static source.
MozReview-Commit-ID: 9fAoPSt4bxq
--HG--
extra : rebase_source : bad6912a5e2bf5f4791e97f0d0b2572d70007e9a
Add a release promotion custom action for releng's TC release promotion migration work.
This action generates a graph dependent on previously built tasks. To track these, we add the `do_not_optimize` and `existing_tasks` parameters. The `do_not_optimize` parameter specifies tasks that we want to explicitly exclude from taskgraph optimization. The `existing_tasks` parameter specifies a label-to-taskid map for tasks from previous graphs.
MozReview-Commit-ID: 1vKrNUavM4V
--HG--
extra : rebase_source : b8ba95d270aafe1464c2b3bfc318b9568500a7a1
Single-locale repacks need to run aapt (--without-gradle) or Gradle
(--with-gradle). When running --with-gradle, they need to compile the
Java source code again (in order to produce a fresh R.java with
correct IDs). That compile will be part of the shipping APK, so it
needs to be configured "the same" as the underlying repacked. *This
is a significant change in behaviour, but necessary to support newer
Gradle/aapt versions, which do not maintain R.java ID mappings across
invocations.*
Part of the configuration are the secret keys and features that are
gated on them. This commit makes those secrets available to
single-locale repacks.
MozReview-Commit-ID: 4REPsIb5TgN
--HG--
extra : rebase_source : 9a74ea5f6633d1a4bd52d6116b60edaf974d11eb
extra : source : a721890f7573140ca6a926e722bd3538c732dae7
Many of the 'test' tasks key the entire 'mozharness' section by-test-platform.
This is bad because:
A) Configuration under 'mozharness' can't be shared across platforms
B) We can't use the 'job-defaults' simplification since merging is naive
Instead of keying the entire 'mozharness' section, this change keys only the
specific configuration that needs it.
MozReview-Commit-ID: EaPlOzsESQ3
--HG--
extra : rebase_source : 12d81013fd4e18403799c92df06f855bf7162a05
Every task that uses the desktop_unittest.py or android_emulator_unittest.py
mozharness scripts needs to pass in either --<suite>-suite=<flavor>, or
--test-suite=<flavor> respectively.
In almost all cases, <suite> and <flavor> are identical to the value that is
already specified under the test['suite'] key. This means we can use a
transform to append these command line arguments and reduce the complexity of
the yaml files.
MozReview-Commit-ID: EaPlOzsESQ3
--HG--
extra : rebase_source : 1fc5523323774ab429f1377880204df51d53ccef
This is mostly a refactor, moving shared defaults to the top of the file where
appropriate.
The only change this makes, is modifying a couple of the macosx talos tasks to
use the osx mozharness config. They were previously using the linux config
which was likely a bug.
MozReview-Commit-ID: 2c0muPZrHZ
--HG--
extra : rebase_source : c05f03e812972fa0c237f1dfa5f07c9a47cc30ce
This is a simple refactor into separate files. No task definitions should be
modified by this patch.
Most tasks are moved into suite-specific .yml files. A handful of miscellaneous
tasks are defined directly in kind.yml under the 'jobs' key.
MozReview-Commit-ID: 7piXDA6tGI0
--HG--
extra : rebase_source : a91fbb6d0bf740a28a042470b3f9d4a4e309d1f0
This will allow us to use 'jobs', 'jobs-from' and 'job-defaults' with the test
kind.
MozReview-Commit-ID: 7q66kjSI4b3
--HG--
extra : rebase_source : 46c46b1a02d74a1e953c878de2fbb6cbb1b5dd81
The previous implementation failed to call `f.result()` when creating only one
task, thereby ignoring the error.
MozReview-Commit-ID: 3zv9kFoPZCj
--HG--
extra : rebase_source : c674b0cfe9fc0722046a97253a26b3e539827273
The goal is to use a newer Android-Gradle build plugin version (2.3.3
is latest stable). That requires a modern Gradle (anything 3.3+, but
3.4.1 is the default from my Android Studio), and also a newer
build-tools (25.0.3 is latest stable).
The locations of lint output changed, and we want to use the standard
output location because it's difficult to accommodate variant details
in custom names. We change the location of findbugs output to follow
suit.
This requires either:
- fixing lint errors
- adding to the lint whitelist
- using the new lint baseline
It's best to use the new lint baseline, which will happen in the next commit.
MozReview-Commit-ID: D19FzIDCJrE
--HG--
extra : rebase_source : 12d132c0c3e0dbe2b8873b31360ea96d612de44c
This is simply diagnostic; it's nice to see what the versions of the
Android packages installed are, like:
Installed packages:
Path | Version | Description | Location
------- | ------- | ------- | -------
<snip>
platforms;android-23 | 3 | Android SDK Platform 23 | platforms/android-23/
tools | 26.0.1 | Android SDK Tools 26.0.1 | tools/
This is really useful because it's not possible to pin most packages
to specific versions; that is, we can only install latest "tools", not
"tools;26.0.1".
MozReview-Commit-ID: HgZLGCAObEs
--HG--
extra : rebase_source : 33e5c9f81d05551c9e167eac62009f1de023b410
This adds a new `tc-A` Tree Herder group, similar to the `A` Autophone
(or Android) group. (I don't want to include a `g` for Gradle because
eventually there will be nothing that is _not_ Gradle.)
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1371445#c31, the
sheriffs are satisfied with the test output.
As to the rest of
https://bugzilla.mozilla.org/show_bug.cgi?id=1372075#c0, the
documentation is in place, and |mach try fuzzy| has eclipsed
trychooser, so I think we should not update trychooser.
MozReview-Commit-ID: 2OWDEmGCd11
--HG--
extra : rebase_source : 8c62f958b64c38797e9070e8328cd7f24baa8cc5
The multi-l10n and update mozharness actions are Nightly build
specific. The android-* tasks look like builds but aren't really
builds -- they don't produce APKs, for example. In the past, these
actions immediately returned because the android-* jobs where never
considered Nightly builds and there is a test for "is Nightly" in each
mozharness action. When forcing a build to be a Nightly, these
actions don't immediately return; since they're build specific, this
causes errors.
This commit simply doesn't run these actions, since they're not
appropriate to these tasks.
MozReview-Commit-ID: deJJbBu0eb
--HG--
extra : rebase_source : 8a6b9d69bf7a1cbeb30f84d6e5def41c1af3816c
AFAICT, the last use of the build.sh script was removed in bug 1309593,
and checkout-sources.sh is only used from that script.
--HG--
extra : rebase_source : f89d9071af0e49a168e1eb7c38e291c29ed7119f
Except ASAN builds, which for some reason fail with that version
(bug 1409267).
--HG--
extra : rebase_source : e91bd0f4cd152be57abd5cddb8e15e4af34912bb
I don't think (the output of) this script is used anywhere.
MozReview-Commit-ID: DwMFtpozjNL
--HG--
extra : rebase_source : 005086039f520ba116534ab47ee49616c6958e85
The only tricky piece here is that the resulting toolchain archive is
private, and uses a newly allocated Task Cluster scope
(queue:get-artifact:project/gecko/android-sdk/*) to restrict access to
the archive. All SCM levels (1, 2, 3) have been given the new scope:
see https://tools.taskcluster.net/auth/roles/moz-tree:level:1 and
friends.
MozReview-Commit-ID: CcDqDOHODpe
--HG--
extra : rebase_source : 81dbb065f2a3c4e7733e964be66adb1733db52c6
Not all Docker images are configured for tc-vcs caches: in particular,
android-build is not configured. Until we fully remove tc-vcs, this
will let toolchain tasks use non-tc-vcs caching images.
MozReview-Commit-ID: CYSdn2kpF3S
--HG--
extra : rebase_source : 87dec4fdb32290ef396cda7f92da6bd688bc5b7b
I *think* the modifications to MockedOpen are correct, but I'm not sure..
MozReview-Commit-ID: 6vTZBtdQ1dz
--HG--
extra : rebase_source : 2d2008f87640747ef831d000bf13a4b1b7fcd338
Specifying anything but "toolchain-build" appears to have cache
errors, which I cannot understand. These cache errors can be
addressed in follow-up, if and when toolchain tasks require new sparse
profiles. But specifying `null` avoids the sparse profile details
entirely, which works nicely for `android-gradle-dependencies`, which
is build-like and requires a fairly complete checkout.
MozReview-Commit-ID: L3R8UIDjgqW
--HG--
extra : rebase_source : 096a180238d1b5eeffbb0e2d9d538def162e877f
