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
Add a toolchain job description which calls the
repack_rust.py script to package the requested
upstream build of Rust and its standard libraries
for use in gecko builds.
Links are added to these new toolchains for various build
and analysis tasks as appropriate. The base-toolchain
tasks use an explicitly-versioned toolchain since those
can be different from the current release used for most builds.
The corresponding tooltool manifest entries are removed
now that taskcluster artifact versions are available.
This simplifies the update process since new toolchains
can be packaged and used automatically by just updating
the versions in the task descriptions.
A 'linux64-rust' toolchain can be added to other tasks
as a dependency and artifact. It supports linux64-
hosted builds of Rust code targeting linux64 or linux32.
A 'linux64-rust-macos' toolchain targets linux64-hosted
builds of Rust code targeting macOS on x86_64.
A 'linux64-rust-android' toolchain targets linux64-hosted
builds of Rust code targeting various Android architectures.
Two 'win64-rust' and 'win32-rust' toolchain tasks create
similar entries for Windows-hosted builds. All our automation
builds are hosted on win64, so we could use one artifact
with support for both targets, but currently this doesn't
work because of cross-compilation issues in some crates.
This patch maintains the previous separation between
win32 and win64 rust toolchains until that can be addressed.
MozReview-Commit-ID: GRiJml8CtzO
--HG--
extra : rebase_source : 09a3698ce7f9a8b5f2b5d9b5a1fde9c05dc6b540
Copy the repack_rust.py from the rust-build docker container
so it can be used more generally by other taskcluster jobs.
Add --host, --target, and --suffix switches, allowing control
of the packaged toolchain and standard library builds from
the command line.
This drops the previous default behaviour of packaging all
supported platforms and targets.
Add a hard-coded copy of the Rust release signing key to
the script and add it to the running user's gpg config
so we can validate downloaded artifacts from the project
in automation.
Remove the keybase artifact validation since it requires
out-of-project network services and doesn't provide much
advantage in automation.
Calculate the SHA-2 checksum during download and remove
the dependency on shasum/sha256sum command-line tools.
Use more python for filesystem an process interaction
in general.
Create a generic rustc.tar.* package to correctly match
the unversioned unpack dirctory name.
Add support for copying the package to an output directory
if the UPLOAD_DIR environment variable is set. This lets
us hook up the script to taskcluster toolchain jobs without
an external wrapper.
MozReview-Commit-ID: 68LmY3QVU8V
--HG--
extra : rebase_source : f6329056d518ad2cd25faa5c71b22130cbc65c8f
Add an optional 'arguments' key to the yaml description for toolchain
tasks. This is a list of strings to be passed to the script invocation.
This lets us set behaviour, e.g. selecting the version to build or
selecting targets from the task description instead of having to
hard-code those things in the build script itself. Where the same
script otherwise works for multiple configurations, that is easier
to update and simplifies supporting variants.
MozReview-Commit-ID: 30oJYnQaZ7A
--HG--
extra : rebase_source : bdd7bdc5f874d1329ff52d900cd1ac93df23c6dc
Run scripts with a `.py` filename extension through `./mach python`
so the normal enviroment with in-tree python libraries is available.
This is helpful for the Rust upstream release download and repackaging
steps, which are more easily expressed in python than in an sh-based
build script like we use for clang and other tools.
Invocation of `mach python` on Windows-hosted generic workers fails
because of some missing environment pieces. For the purposes of this
bug we can just run the script for Windows targets in a docker-worker
so Python support was left unimplemented for generic workers.
MozReview-Commit-ID: 4XUQ1XrVBc2
--HG--
extra : rebase_source : df81d2da7e70fffb29e96377f16ab22def9e94e0
