This fixes the fallout from the mach command not being updated for 69c60c8fc528d8d038e22a2ae62f5ff7b1131231.
MozReview-Commit-ID: 7WZ8wW4gnCY
--HG--
extra : rebase_source : 36caffb4a8631ea478ec6f8d509a82c01016eeb5
This fixes the fallout from the mach command not being updated for 69c60c8fc528d8d038e22a2ae62f5ff7b1131231.
MozReview-Commit-ID: 7WZ8wW4gnCY
--HG--
extra : rebase_source : 887b386480b9cb69c8b7e0196851862fceec2dfe
These scripts are included by hazard-analysis.sh. That's their only
reference in repo.
We could probably inline these scripts. But let's start by moving them
out of mozharness since no active mozharness based task is using them.
MozReview-Commit-ID: 13oen42Txmh
--HG--
rename : testing/mozharness/scripts/spidermonkey/build.browser => taskcluster/scripts/builder/hazard-browser.sh
rename : testing/mozharness/scripts/spidermonkey/build.shell => taskcluster/scripts/builder/hazard-shell.sh
extra : rebase_source : 782f7b3f3537cfefb51b0e5f1b459c8ad0daca5b
With migration of talos machines from buildbot to Taskcluster, we need a
way to run jobs in Taskcluster without affecting production.
We accomplish this task by using the same approach we use for Linux:
when we give the --taskcluster-worker flag, decision task switches from
buildbot-bridge to Taskcluster Windows work-type.
MozReview-Commit-ID: LU5oaGCZ8uz
--HG--
extra : rebase_source : d32d3fa85027bb50726c6f4631716016c91ebb45
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 : 2d23e0e0c51a61e50acf24123b316bdbb0b579ff
extra : source : a721890f7573140ca6a926e722bd3538c732dae7
The mochitest and reftest selftest tasks are excluded because they also
schedule several builds as dependencies which is likely going to be unexpected
behaviour.
MozReview-Commit-ID: 9eoVJ5qpAMO
--HG--
extra : rebase_source : 469521feff3ba42506ffb54bfe8f009bf9ab9da6
Tasks that have the 'always_target' attribute set will be always be included
in the target_task_graph, regardless of target task filtering.
Furthermore, if they were only added because of this attribute (i.e, the
filters would have excluded the task), then the task will be a candidate for
optimization even if the 'optimize_target_tasks' parameter is False.
MozReview-Commit-ID: 9eoVJ5qpAMO
--HG--
extra : rebase_source : 9635002720d088ca9870649f3143d6293c666610
This adds the R.txt files produced by the build -- timestamped, so
they are kept in order -- to the Task Cluster artifacts, for later
comparison.
MozReview-Commit-ID: 3hj6XjFDIE4
--HG--
extra : rebase_source : 04c1bcd2bf62fd193541fa92dd8841db102f6b5a
extra : source : 5a00c3642c972385cd212fe8b15240bce6acef50
As we transition to Gradle (and only Gradle) Fennec builds, we're
turning the Gradle builds (Bg) into non-Gradle builds (Bng). It's not
worth the effort to rename "gradle" to "non-gradle", so this is a
confusing looking patch that turns on GeckoView tests for everything
but Bng (which has kept the "gradle" name).
MozReview-Commit-ID: C1PlsehRwJf
--HG--
extra : rebase_source : f8bfc730ab963833f43d2f19b11027db8e49a06a
extra : source : 50006730ade8dd1a12ec0eec7113f802e6b8497d
This also turns the tier 2 job B(n)g into tier 1, since moz.build is
still tier 1. It also pushes a lot of GeckoView related tasks into
the main builds, since they should run as part of Gradle builds.
This also removes unused tooltool manifests; the jobs that used these
manifests use only toolchain tasks now.
MozReview-Commit-ID: 2GmnJ7joCTT
--HG--
extra : rebase_source : 75cd2dfb51e0e1b510f5e618c2dc881cf5f22bf2
extra : source : 6b95b09d6afbb83ba89c47b237dfce6e15587bbe
mdc1 Linux machines can't find tooltool with this config.
MozReview-Commit-ID: 3CnfqcSbO0K
--HG--
extra : rebase_source : 13d4b76bafda17a82659927afee38320f91d0f93
Building with "Linux x64 JSDCov", each suite of tests will produce a list of JSDCov artifacts (.json). This patch compresses all JSDCov artifacts into 1 zip file for each suite upon tests completion.
MozReview-Commit-ID: DaNLOQuW2lc
--HG--
extra : rebase_source : cceb912d0fe16f9921e1d13fe85d53af2abcb29c
Previously, the CI task invoked 2 mach commands and performed manual
gzip compressed. This was sub-optimal for a few reasons:
* Redundant moz.build evaluation made execution slower
* Potential for shell expansion to interfere with wildcards
* Made it harder to change exit code
By moving all logic into a mach command, we eliminate all the issues
around using shell.
Behavior of the new command and the CI task should be backwards
compatible.
MozReview-Commit-ID: HUFvLteKLOO
--HG--
extra : rebase_source : 85a49fc45eeaaac71dfb97fc22900a81ca9efa4b
This patch adds the `release_deps` transform, which adds every
kind-dependency task that has the same product as a task dependency
(with some exceptions).
This patch made it clear that we need a standard way of defining
product.
MozReview-Commit-ID: 4xOJRQSCTgF
--HG--
extra : rebase_source : 4b98b040ac5d8777394cff6f3249ab354fff641b
This patch adds the `release-notify-promote` and `release-notify-publish` kinds. It also genericizes all the notifications, and updates the kinds that use those notifications.
MozReview-Commit-ID: 9ymXKzthVF4
--HG--
extra : rebase_source : 6d7db48afa14e4124834321784da65e8d1e84c98
This patch adds the beetmover-cdns kind, and adds it to
`publish_fennec`.
This was the first non-buildbot-bridge, non-dummy relpro task, so this
needed a new transform.
This patch also updates the `previous_graph_kinds` and updates the
beetmover scopes in scriptworker.py.
MozReview-Commit-ID: 3rpkjuLjjXz
--HG--
extra : rebase_source : d491f1ce5d10ee8f2602698236106007e203c358
This patch adds per-task pulse notifications, as well as general support
to handle them.
Longer term we may move away from pulse-notifications, but this allows
us to proceed with pulse-notifications until that time.
MozReview-Commit-ID: 1uB4X682yLT
--HG--
extra : rebase_source : 360938e4682e3d7ae0874b4a50e41d5f97bf98bb
We currently use `previous_graph_kinds` as a pointer to use a previously
built graph's task instead of generating a new task. We were re-running
`release-bouncer-sub` in the `publish_fennec` release promotion flavor
because we hadn't specified `release-bouncer-sub` as a
`previous_graph_kind`; this patch fixes that error.
MozReview-Commit-ID: 92MAVsG8Jrk
--HG--
extra : rebase_source : cf8411d017de20ef05ba9ac547e94797c88901dd
We were building some Android nightly platforms on push, because we
didn't add them explicitly to the remove list.
I think longer term, we'll want to have `product` and
`release_promotion_action` attributes set in a standard manner, that we
can use to filter these things more intelligently.
MozReview-Commit-ID: KNZ7vxc3gRo
--HG--
extra : rebase_source : dd0c87fe8d050b226db6ba97d22c9089f7bb9430
This patch adds the initial `release-version-bump` kind, and adds it to
the `publish_fennec` `target_tasks_method`.
It also adds support for `next_version`.
MozReview-Commit-ID: 9YRswddeuZ3
--HG--
extra : rebase_source : 991cbf89b40c4ef980c42251001e81be5cedaf00
This patch adds the initial `release-uptake-monitoring` kind, and adds
it to the `publish_fennec` `target_tasks_method`.
MozReview-Commit-ID: 3RDMNGrbBwD
--HG--
extra : rebase_source : f504c8e173337d45bc9f374bd0349c6823b50ffb
This patch adds the initial `release-bouncer-aliases` kind, and adds it
to the `publish_fennec` `target_tasks_method`.
It also adds the ability to specify the `tuxedo_server_url`
`by-project`.
MozReview-Commit-ID: 9I4IaUlbCCD
--HG--
extra : rebase_source : d0ed88a687ef6fb9f97dc67c0f04742bbfeb201d
This patch adds the initial `release-mark-as-shipped` kind, and adds it to
the `publish_fennec` `target_tasks_method`.
MozReview-Commit-ID: F8AYscJQWlh
--HG--
extra : rebase_source : 9522b95f65b5b373a54bc0fc01a20c72adbee0cb
This patch adds the first releasetask as a new kind. To support this, we
added a new `release-promotion` flag in the buildbot job. If this is
set, we use the new `bb_release_worker` function; otherwise we fall back
to the `bb_ci_worker` function (this is the old behavior, factored out
into a separate function).
We also added `build_number` and `release_promotion` attributes in the
task definition. Finally, `build_number` now defaults to 1, allowing us
to create the task graph locally without forcing us to set
`BUILD_NUMBER` in the environment.
MozReview-Commit-ID: 8vNMHJemqAG
--HG--
extra : rebase_source : c8816d3e7b2f5358ea51ee8d5fb12585e67e9853
This hooks up the `target_tasks_method`s and the
`release_promotion_flavor`s for these four release promotion flavors.
We also add some maple support and add `version_display.txt` to the
decision task sparse checkout so we can read the version number during
decision/action task time.
MozReview-Commit-ID: CdxUUXZtXO0
--HG--
extra : rebase_source : 99e4f060a964d34a377aea6a6e36fbcef66c6aec
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
I don't think (the output of) this script is used anywhere.
MozReview-Commit-ID: DwMFtpozjNL
--HG--
extra : rebase_source : 36b3cbe1a6a9e5cd163782c1c13653be8558a03a
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 : 062bca8c65556f0f46e9c9cc6cd81eb04cf2b522
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 : 4f032650baaa49537ffd894b34e936af2141a330
The goal of this approach is to tell Gradle to not connect (or allow
it to connect) to the network when fetching dependencies. No Android
automation tasks should fetch from the network, except the toolchain
tasks (which are specially intended to do so).
It's difficult to arrange this without including the `--offline` flag
everywhere. It _should_ be possible to set offline using an
environment variable -- which would allow us to get rid of these
dotgradle-* files -- but offline isn't an option in
https://docs.gradle.org/4.2.1/userguide/build_environment.html#sec:gradle_configuration_properties
(and certainly not in earlier versions either). Therefore,
environment variable that points to an init.gradle file in automation.
Before this patch, the files telling Gradle whether to start offline
were fetched from tooltool. That's just a layer that doesn't need to
be there.
None of this impacts local developers.
MozReview-Commit-ID: LAXktbBu1Az
--HG--
extra : rebase_source : d23801643d32135a87d410bf5e8508da556ef9be
This is just one flavor of the "reftets" suite, so we need to add a distinct
scheduling component for it.
MozReview-Commit-ID: AtKuvuUCk1l
--HG--
extra : rebase_source : 3f316f0293e8d1245fc6e891bbcd044586ab6c06
This approach allows to specify the `docker-image` and set of
`toolchains` to the l10n leaf jobs using the `by-platform:` override
mechanism. We don't support anything but in-tree docker images at
this time, and the schema will warn if a different type of docker
configuration block is used. It wouldn't be hard to grow the
additional blocks, but let's reduce duplication for now.
It might be considered better to inherit the `docker-image` and set of
`toolchains` from the underlying `dependent-task`, but we don't do
that for two reasons. The main reason is that it's an explicit goal
to be able to "cross repack": to repack, say, a Windows binary on a
Linux worker. In that situation, the docker-image and toolchains
differ between the builder and the repack worker.
A smaller technical obstruction is that by the time the l10n transform
sees the dependent task, the docker image and set of toolchains have
been processed. The l10n transform would have to "reconstitute" the
docker image changes and the set of toolchains; it would be very
fragile.
Taken together, it's better to be explicit, reduce unexpected
interactions, and repeat the information in the l10n leaf tasks.
MozReview-Commit-ID: TmgJyYU5dx
--HG--
extra : rebase_source : 9aae494165d9a7c70de0f5fe4849ec219e28a20c
This is a work-around until Bug 1405889 is deployed. Using the /bewit
endpoint does have the advantage of avoiding another issue in
taskcluster-proxy, namely that the /bewit approach streams. Fetching
through the proxy does not stream from the upstream resource; the
upstream resource is fetched and stored in taskcluster-proxy's memory,
increasing operational costs.
MozReview-Commit-ID: 8yS7zKLALhd
--HG--
extra : rebase_source : 23e1bc683248f69f6e4c90204e9bc0701f4a778a
There's code that carefully uses `setdefault('artifacts', [])` in the
same file, but then stomps on 'artifacts' before that's invoked. This
allows tasks to change where public/build is sourced from, and to add
additional artifact locations (including private locations).
MozReview-Commit-ID: JqyHew5bGv5
--HG--
extra : rebase_source : 420f1e062583d315faa413181b1ac17c0e55249e
With this in place, all `-j`obs will not run by default on try. This will omit
such jobs in most try pushes even if files-changed matches. This is
unfortunate, but better than running them unconditionally. Fuzzy selections,
and later `just try it` pushes, are the ultimate solution here.
With this change, a push with no try syntax or try_task_config.json will schedule
no tasks at all.
MozReview-Commit-ID: FGjqlDW1FT6
--HG--
extra : rebase_source : 727ceafb1b6d24f83c0c7382b6a877ecb65863ab
Specifically, this avoids setting optimize_target_tasks to True unconditionally
for non-try branches.
MozReview-Commit-ID: HSJFLmqbMmZ
--HG--
extra : rebase_source : 459e65c0d423d091846134da011b0e201ff8da99
When adding sccache toolchain jobs in bug 1381772, building with gcc
failed, and building with clang worked, so I just went with the path of
least resistance. That's however a suboptimal position in the dependency
graph, so it's still preferable to use gcc if possible.
Looking exactly how it fails, it turns out it's because without CC being
set, ring wants to build with "cc", which ends up being the system gcc
instead of ours (our gcc archive doesn't provide "cc", only "gcc"), and
it is too old to support the compiler flags ring uses.
So setting CC does the trick.
--HG--
extra : rebase_source : 4c657664957dff1f7aebe470e0440a52c9e280e5
New upstream stable release.
Maintain rust-1.19 builds for verifying the minimum-supported
version, and because we have network failures when we build
sccache with rust 1.20 or 1.21.
MozReview-Commit-ID: 5qi8JDTjfzj
By the schedule we would have bumped the minimum-supported rust
version to 1.20.0 some weeks ago, just before Firefox 57 went to
beta. However, that was blocked on a couple of compatibility
issues with sccache and dsymutil. See bug 1396884.
Now that 1.20.0 is working in our automation builds, require
it for all builds to unblock servo and webrender upgrades.
Also update our integration test to verify building with
the new minimum.
MozReview-Commit-ID: 8otdix6f45f
--HG--
extra : rebase_source : 7d2550e8ddc772b45602bd488f174fc180e91484
for: Run buildbot's periodic_file_update job scheduled via taskcluster.
I messed up thinking this was filter-out not filter in the target task method.
I'm also renaming the target_task method in order to avoid these decision jobs
from needing to contact balrog for partial data (because it had 'nightly' in the
target task name.
MozReview-Commit-ID: 3uetnWG4vnW
--HG--
extra : rebase_source : 82dc838d23e02ae2ea515416a29bb0b491c053b9
At this point, we could tear out the `ignore-locales` attribute, since
l10n-bumper supplies that information. However, we may want to use flatfiles
for something; `ignore-locales` allows for that.
MozReview-Commit-ID: 8mD4iav3bKx
--HG--
extra : rebase_source : abe2075503838223a2c150676b9c72a1aa74df59
Diffing `target-graph`s was difficult because the locales kept shuffling.
This patch will keep the locales in alphabetical order.
MozReview-Commit-ID: GvGYF7j9ftq
--HG--
extra : rebase_source : 6a9aef0efd61c4f1aa7df48ca513311da203ccdb
Stop hardcoding `android`, since we want to use this for desktop too.
We could potentially remove the `android` platform from the bumper configs
at this point.
We strip `-nightly` from the `build_platform` before comparing against the
`l10n-changesets.json` platform list. If we want to support different sets
of ci and nightly locales, we could either:
- point at a second changesets file for ci. This could either be a flatfile
or json; either works. or,
- explicitly name `win32-nightly` etc. in the platform list, and stop removing
the `-nightly` from the `build_platform` before comparing. This means some
locales may have up to 10 different platforms listed. This may get unwieldy,
but would be explicit.
MozReview-Commit-ID: Fvpby92cXdg
--HG--
extra : rebase_source : 503ce9bd455d9845d6598ce2e06c4a355e737053
This also migrates the vcs.py test to mozversioncontrol and adds a new task for
it.
MozReview-Commit-ID: 9jTRkjNupVA
--HG--
extra : rebase_source : 400f27498e00ea45234ad7c951770b098e916b8e
