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
