This is useful in order to not have to run linux64/opt on push, especially on autoland/inbound
when we need a source test. It is also required if we remove the linux64-pgo build type entirely.
Differential Revision: https://phabricator.services.mozilla.com/D23124
--HG--
extra : moz-landing-system : lando
I did a bunch of manual testing with this, the biggest uncertainties lie around beta and central/nightly.
We are adding shippable-qr to beta because of replacing nightly too.
Autoland and inbound should have the same sets of tasks.
beta -
- adds mochitest-plain-headless-{1..4} to beta (not currently run)
- adds raptor to run on shippable for beta
- currently runs on opt on beta, and for nightly tasks on beta only webaudio-chrome runs.
- adds talos to shippable tasks, on beta talos only runs against opt.
central -
- adds browser-screenshots to nightly graph
- adds mochitest-plain-headless-{1..4} to nightly graph
- adds browser-instrumentation to shippable
Differential Revision: https://phabricator.services.mozilla.com/D23122
--HG--
extra : moz-landing-system : lando
Effectively back out much of the run on projects from D22710
This also has the added affect of scheduling the shippable builds to run because of dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D22833
--HG--
extra : moz-landing-system : lando
raptor-chrome is Google Chrome and only needs to run once per day, so mozilla-central pushes and try.
raptor-profiling is primarily for devs to have up to date profile information and it too only needs to run once per day.
TODO is to try and find a clean way to make them only run when we trigger Nightlies rather than every m-c push.
Differential Revision: https://phabricator.services.mozilla.com/D22832
--HG--
extra : moz-landing-system : lando
Makes most kinds that reference nightly attribute reference the shippable attribute.
Also makes most transforms that use nightly use shippable
Transfers dependencies/ownership for some things to shippable from nightly where it was harder to support both.
In no particular order, full list:
Send shippable attribute down to dep tasks.
Set tests as shippable attribute
Add new signing routes
Add shippable routes to repackage_routes transform
Adjust target tasks
Add shippable nightly-l10n
Add nightly-signing and as a side affect add repackage and repackage-signing
Add support for proper balrog platforms for shippable
Add shippable to the nightly sccache guard
Fix TC_PLATFORM_PER_FTP in partners.py to use shippable
Add shippable to mozharness_test variants
Only actually used for android which doesn't have shippable at this time.
Add shippable variant to beetmover transforms
Do nightly signing for mars on shippable
Support shippable in partner-repack transform
Support shippable in amo langpacks transform
Use proper signing for shippable tasks in repackage transforms
Set upload symbols to use shippable too
Use shippable as deps for geckodriver extraction
Use shippable as dep for autograph-stage signing
Do not run beetmover-l10n for shippable
Run shippable style jobs for repackage signing
Set build_platform for update verify and uvc to be shippable
Run repackage-msi for shippable
Add shippable to osx partner repack signing
add shippable to emefree repackage
add shippable to emefree repackage signing
add shippable to beetmover checksums
Add shippable to partner repack repackage signing
add partner repack beetmover
Add shippable to mar signing
Add shippable to mar-signing-l10n
add shippable to eme free beetmover checksums
Add shippable to upload-generated-sources
Add beetmover langpacks to shippable
Add repackage-l10n to shippable
Add shippable to partner repack chunk-dummy
Do eme free builds with shippable
Add signing of language packs to shippable
Add snap repackage for shippable
Add shippable for release-eme-free repack signing
Add partials for shippable
Add partner repack repackage for shippable
Add emefree beetmover for shippable
Add checksums-signing to shippable
Switch partner repacks to shippable
Add shippable to beetmover-repackage
Add secondary update verify configs for shippable
secondary update verify for shippable
Differential Revision: https://phabricator.services.mozilla.com/D24699
--HG--
extra : moz-landing-system : lando
Jmaher indicated we do not have the test capacity to incur this as a duplicated set
Differential Revision: https://phabricator.services.mozilla.com/D23382
--HG--
extra : moz-landing-system : lando
This also relates to Bug 1522111 where we turned off opt tests in favor of pgo,
shippable is like the new pgo so do that.
This has a side affect of adding talos-tp6-stylo-threads to inbound for
osx-shippable (previously was only on autoland).
This has no practical affect after D23382 is applied (because of lack of OSX capacity)
Differential Revision: https://phabricator.services.mozilla.com/D23129
--HG--
extra : moz-landing-system : lando
Should there end up being a need we can back out this patch and let them run, but :jmaher indicated
he was happy with dropping them entirely and not duplicating.
Differential Revision: https://phabricator.services.mozilla.com/D23383
--HG--
extra : moz-landing-system : lando
This is useful in order to not have to run linux64/opt on push, especially on autoland/inbound
when we need a source test. It is also required if we remove the linux64-pgo build type entirely.
Differential Revision: https://phabricator.services.mozilla.com/D23124
--HG--
extra : moz-landing-system : lando
I did a bunch of manual testing with this, the biggest uncertainties lie around beta and central/nightly.
We are adding shippable-qr to beta because of replacing nightly too.
Autoland and inbound should have the same sets of tasks.
beta -
- adds mochitest-plain-headless-{1..4} to beta (not currently run)
- adds raptor to run on shippable for beta
- currently runs on opt on beta, and for nightly tasks on beta only webaudio-chrome runs.
- adds talos to shippable tasks, on beta talos only runs against opt.
central -
- adds browser-screenshots to nightly graph
- adds mochitest-plain-headless-{1..4} to nightly graph
- adds browser-instrumentation to shippable
Differential Revision: https://phabricator.services.mozilla.com/D23122
--HG--
extra : moz-landing-system : lando
Effectively back out much of the run on projects from D22710
This also has the added affect of scheduling the shippable builds to run because of dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D22833
--HG--
extra : moz-landing-system : lando
raptor-chrome is Google Chrome and only needs to run once per day, so mozilla-central pushes and try.
raptor-profiling is primarily for devs to have up to date profile information and it too only needs to run once per day.
TODO is to try and find a clean way to make them only run when we trigger Nightlies rather than every m-c push.
Differential Revision: https://phabricator.services.mozilla.com/D22832
--HG--
extra : moz-landing-system : lando
This task runs on wpt metadata changes and uploads an artifact
containing the summarised metadata.
Depends on D24178
Differential Revision: https://phabricator.services.mozilla.com/D24179
--HG--
extra : moz-landing-system : lando
Taskcluster has authorative information about the repository being built, so
pass that to mozharness, rather than have mozharness reconstruct it from
hand-maintained mozharness config.
Differential Revision: https://phabricator.services.mozilla.com/D24561
--HG--
extra : moz-landing-system : lando
Bug 1534522 added win64-aarch64-eme/opt builds, which are artifact builds
that glue together a win64-aarch64/opt build and a win32/opt build.
This enables EME on the corresponding nightlies in a slightly different
way:
- this adds a no-eme build that corresponds to win64-aarch64/opt.
- this turns the existing nightly into an artifact build that glues
together that no-eme build and the win32 nightly.
The no-eme build cannot have the nightly attribute set, first because
the beetmover transform fails in that case, and because that would imply
shipping those builds, but they're not meant to be shipped this way.
It also has run-on-projects set to an empty list so that it doesn't
appear by default in `mach try fuzzy`, while still being triggered when
needed due to being a dependency of the nightly build.
It is preferable to keep the win64-aarch64{,-eme}/opt builds untouched
to make things easier for try (the win64-aarch64 ones being the main
ones to try; also, the -eme builds currently fail with --artifacts).
Ideally, like in bug 1534522, we'd add a diffoscope build to ensure
the variations between the nightly and its base no-eme build are within
control, but currently, that would trigger nightlies on every push,
which is not desirable. Ideally, they'd trigger whenever both their
dependencies are in the target task graph. We leave that to a followup.
Differential Revision: https://phabricator.services.mozilla.com/D23640
The code that actually downloads it is behind a condition that isn't set
anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D24215
--HG--
extra : moz-landing-system : lando
Currently, if the files match and you try to look at the diff, you get
{
"reason": "file-missing-on-worker",
"message": "Artifact \"public/diff.html\" not found at \"/builds/worker/diff.html\""
}
which makes it hard to tell if there was an error generating a diff, or if the files matched.
This changes things to ask diffoscope to always output a diff, to remedy that confusion.
Differential Revision: https://phabricator.services.mozilla.com/D24316
--HG--
extra : moz-landing-system : lando
Searchfox relies on the bugzilla component job running on the same push
as the indexing jobs, but there's nothing that actually guarantees that.
Thus far pushes to m-c pretty much always have source changes so the
bugzilla component job gets run, but on beta/release branches it's
possible to get pushes with just tag changes and no source changes, so
the bugzilla component job would get optimized away. This patch ensures
that the job gets run along with the other indexing jobs that searchfox
needs.
Differential Revision: https://phabricator.services.mozilla.com/D24507
--HG--
extra : moz-landing-system : lando
Without this the shippable builds take >20 seconds to compute the prune through new_as_old_is_high_value, locally. With this it is near instant.
Differential Revision: https://phabricator.services.mozilla.com/D22711
--HG--
extra : moz-landing-system : lando
This sets all of the shippable tests to not run in the places where they would otherwise.
This patch will be effectively undone later in the patchset.
Differential Revision: https://phabricator.services.mozilla.com/D22710
--HG--
extra : moz-landing-system : lando
When we set the nightly attribute the tasks don't run on-push, so we use a new attribute.
Differential Revision: https://phabricator.services.mozilla.com/D22709
--HG--
extra : moz-landing-system : lando
This commit adds a new build for OSX since there is no current PGO build type for OSX.
And calls it shippable, this mirrors that of the nightly.
Differential Revision: https://phabricator.services.mozilla.com/D22225
--HG--
extra : moz-landing-system : lando
This was needed since when we have job-defaults and later on a test set for
``
run-on-projects:
by-test-platform:
...
``
We were ending up with both the list of by-* being extended but also
any array in that list also being extended (like `default: ['a', 'b']`
was getting extended to also have the new values for default)
This is not only usually wrong but very very likely not what the author wanted.
Differential Revision: https://phabricator.services.mozilla.com/D22708
--HG--
extra : moz-landing-system : lando
Bug 1534522 added win64-aarch64-eme/opt builds, which are artifact builds
that glue together a win64-aarch64/opt build and a win32/opt build.
This enables EME on the corresponding nightlies in a slightly different
way:
- this adds a no-eme build that corresponds to win64-aarch64/opt.
- this turns the existing nightly into an artifact build that glues
together that no-eme build and the win32 nightly.
The no-eme build cannot have the nightly attribute set, first because
the beetmover transform fails in that case, and because that would imply
shipping those builds, but they're not meant to be shipped this way.
It also has run-on-projects set to an empty list so that it doesn't
appear by default in `mach try fuzzy`, while still being triggered when
needed due to being a dependency of the nightly build.
It is preferable to keep the win64-aarch64{,-eme}/opt builds untouched
to make things easier for try (the win64-aarch64 ones being the main
ones to try; also, the -eme builds currently fail with --artifacts).
Ideally, like in bug 1534522, we'd add a diffoscope build to ensure
the variations between the nightly and its base no-eme build are within
control, but currently, that would trigger nightlies on every push,
which is not desirable. Ideally, they'd trigger whenever both their
dependencies are in the target task graph. We leave that to a followup.
Differential Revision: https://phabricator.services.mozilla.com/D23640
This introduces a mozharness script, android_emulator_pgo.py, to run the
profileserver suite with the PGO-instrumented Android build, and collect
the profile data and jarlog.
The mozharness script contains some redundancy with
build/pgo/profileserver.py, but the additional requirements for Android
to use adb and existing mozharness classes to control the emulator made
it difficult to share the desktop profileserver implementation.
Differential Revision: https://phabricator.services.mozilla.com/D22825
--HG--
extra : moz-landing-system : lando
This is the first stage of the Android PGO task pipeline to generate an
instrumented build.
Differential Revision: https://phabricator.services.mozilla.com/D22824
--HG--
extra : moz-landing-system : lando
The mozharness.py transform passes in "options" parameters through the
MOZHARNESS_OPTIONS environment variable. This will allow the Android PGO
run task to pass in the mozharness script name to test-linux.sh
Differential Revision: https://phabricator.services.mozilla.com/D22822
--HG--
extra : moz-landing-system : lando
In order to call test-linux.sh with the job-script parameter, it needs
to have executable permissions.
Differential Revision: https://phabricator.services.mozilla.com/D22821
--HG--
extra : moz-landing-system : lando
test-linux.sh defaults to true for NEED_XVFB, while build-linux.sh
defaults to false. If we are using test-linux.sh from mozharness (rather
than mozharness-test), we need to explicitly set NEED_XVFB to false in
order to not use xvfb.
Differential Revision: https://phabricator.services.mozilla.com/D22820
--HG--
extra : moz-landing-system : lando
This adds worker-type alias that has dedicated workers at level-3 for running
instrumented builds, but uses a test worker type at other levels.
Differential Revision: https://phabricator.services.mozilla.com/D23576
--HG--
extra : moz-landing-system : lando
There are a number of ways we want to vary workers over time and jobs, including
- we are working on migrating to gce
- pgo builds have a dedicated worker-type for running the instrumented build
at level 3 but not level 1
Rather than have all tasks know about how the machines are provisioned, this
moves to using short-names for the worker types, and then has a config mapping
those to the actual worker types.
This adds support for aliases, and an initial set of them. Follow up work will
switch the existing uses of these worker types to using the aliases.
Differential Revision: https://phabricator.services.mozilla.com/D22549
--HG--
extra : moz-landing-system : lando
comm-task-env runs before run-task and updates the environment with GECKO_*
variables that are defined in a file at the root of a subproject's repository,
such as "comm-central".
Updates:
- add comm-task-env
- add python 3.5 (run-task dependency)
- add pyyaml
Differential Revision: https://phabricator.services.mozilla.com/D16934
--HG--
extra : moz-landing-system : lando
comm-task-env runs before run-task and updates the environment with GECKO_*
variables that are defined in a file at the root of the comm repository,
".gecko_rev.yml". run-task needs these variables to be set to find the
correct mozilla repository to check out for a particular TB build.
The current pinning method of updating ".taskcluster.yml" with the mozilla
repository and revision to pin tois no longer supported.
Differential Revision: https://phabricator.services.mozilla.com/D16783
--HG--
extra : moz-landing-system : lando
Small updates to the version control documents regarding
upgrading `robustcheckout.py`. I noticed that we still
reference `build-puppet` from it's former home on hgmo
and don't include OpenCloudConfig in our list of places
we need to vendor `robustcheckout` changes.
Differential Revision: https://phabricator.services.mozilla.com/D23742
--HG--
extra : moz-landing-system : lando
We need to install a new enough binutils for both of these jobs and
ensure that it's properly found on the linux job.
Differential Revision: https://phabricator.services.mozilla.com/D23678
--HG--
extra : moz-landing-system : lando
History does not disclose why we needed this, but in the brave new GCC
6-compiled world, deleting these files means that host links can no
longer find libstdc++, which causes problems. Let's put the files back.
Differential Revision: https://phabricator.services.mozilla.com/D22884
--HG--
extra : moz-landing-system : lando
Firefox itself has moved on to GCC 6.x; we can move our toolchains along too.
Differential Revision: https://phabricator.services.mozilla.com/D22883
--HG--
extra : moz-landing-system : lando
We're going to copy an x86_64-unknown-linux-gnu ld into the clang build,
which clang will then use in preference to things on PATH. We therefore
need to ensure that this ld is the same ld as would be used for other
builds, such as PGO. This change is the most expedient way to do that;
future work will make the gcc job(s) depend on linux64-binutils directly.
Differential Revision: https://phabricator.services.mozilla.com/D22882
--HG--
extra : moz-landing-system : lando
(without the dash, because I want *this* push to build)
This filters out all tasks, but that means that several things will still run:
* docker images and tasks they depend on (debian packages)
* always_run tasks (various python-y things)
Differential Revision: https://phabricator.services.mozilla.com/D23020
--HG--
extra : moz-landing-system : lando
Updating clang indicates that 32-bit compilation is substantially longer
than 64-bit compilation, perhaps due to swapping. The compilation
process is hitting the timeout limit shortly before the compilation
process completes (~3681/3695 tasks according to ninja).
We could tweak our clang build process to accommodate this job. But we
don't support building on 32-bit Windows anymore, and we don't produce a
32-bit Windows clang either. So we shouldn't support a 32-bit Windows
clang-tidy job either. Let's get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D23517
--HG--
extra : moz-landing-system : lando
History does not disclose why we needed this, but in the brave new GCC
6-compiled world, deleting these files means that host links can no
longer find libstdc++, which causes problems. Let's put the files back.
Depends on D22883
Differential Revision: https://phabricator.services.mozilla.com/D22884
--HG--
extra : moz-landing-system : lando
Firefox itself has moved on to GCC 6.x; we can move our toolchains along too.
Depends on D22882
Differential Revision: https://phabricator.services.mozilla.com/D22883
--HG--
extra : moz-landing-system : lando
We're going to copy an x86_64-unknown-linux-gnu ld into the clang build,
which clang will then use in preference to things on PATH. We therefore
need to ensure that this ld is the same ld as would be used for other
builds, such as PGO. This change is the most expedient way to do that;
future work will make the gcc job(s) depend on linux64-binutils directly.
Depends on D22881
Differential Revision: https://phabricator.services.mozilla.com/D22882
--HG--
extra : moz-landing-system : lando
A newer clang may require newer binutils than the system provides, so we
should ensure that we provide just such a binutils.
Differential Revision: https://phabricator.services.mozilla.com/D23393
--HG--
extra : moz-landing-system : lando
Linux64/debug mochitest-dt chunks are increased to 16 to provide more capacity in
reasonable run time. For ccov, mochitest-dt-12 sometimes still runs > 90 minutes,
so ccov max-run-time is increased to 2 hours.
Differential Revision: https://phabricator.services.mozilla.com/D23309
--HG--
extra : moz-landing-system : lando
This will allow to use bash constructs in pre-diff-commands, like
`{a,b}`.
Depends on D23075
Differential Revision: https://phabricator.services.mozilla.com/D23076
--HG--
extra : moz-landing-system : lando
This is due to an incompatability somewhere between JaCoCo and
default interface methods.
Depends on D23016
Differential Revision: https://phabricator.services.mozilla.com/D23017
--HG--
extra : moz-landing-system : lando
This task extracts the binary of geckodriver from the
common test package and stores it into its own artifact.
For now this task is only run after Nightly build tasks
on supported platforms..
Differential Revision: https://phabricator.services.mozilla.com/D23094
--HG--
extra : moz-landing-system : lando
These toolchain tasks are the last ones using the historical
download-tools script from build/unix/build-gcc, which invokes gpg to
validate the downloaded tarballs. The consequence is that gpg-agent is
spawned and stays running, preventing a cleanup script from doing its
job, making the tasks fail.
Fetches are the new way to download sources, and can also do gpg
validation without those caveats.
The download-tools.sh script can then be removed as it's not used
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D22682
--HG--
extra : moz-landing-system : lando
Reinsert awscli for partials, which is needed for caching. Also update packages and fix the metrics recording
Differential Revision: https://phabricator.services.mozilla.com/D22942
--HG--
extra : moz-landing-system : lando
Reinsert awscli for partials, which is needed for caching. Also update packages and fix the metrics recording
Differential Revision: https://phabricator.services.mozilla.com/D22942
--HG--
extra : moz-landing-system : lando
In bug 1501776, the `single_dep` and `multi_dep` schemas were aligned, which made both
branch in name_sanity identical. Simplify the code to reflect that.
Differential Revision: https://phabricator.services.mozilla.com/D24109
--HG--
extra : moz-landing-system : lando
This allows the confined snap to interact with Universal 2nd Factor devices, such as Yubikeys.
Differential Revision: https://phabricator.services.mozilla.com/D24147
--HG--
extra : moz-landing-system : lando
This introduces a mozharness script, android_emulator_pgo.py, to run the
profileserver suite with the PGO-instrumented Android build, and collect
the profile data and jarlog.
The mozharness script contains some redundancy with
build/pgo/profileserver.py, but the additional requirements for Android
to use adb and existing mozharness classes to control the emulator made
it difficult to share the desktop profileserver implementation.
Differential Revision: https://phabricator.services.mozilla.com/D22825
--HG--
extra : source : c151ebf303cad175e24bcc0965c800a9d12ecb3b
This is the first stage of the Android PGO task pipeline to generate an
instrumented build.
Differential Revision: https://phabricator.services.mozilla.com/D22824
--HG--
extra : source : b96dd954a456d8088a3ceda66f51d4106f516b4a
The mozharness.py transform passes in "options" parameters through the
MOZHARNESS_OPTIONS environment variable. This will allow the Android PGO
run task to pass in the mozharness script name to test-linux.sh
Differential Revision: https://phabricator.services.mozilla.com/D22822
--HG--
extra : source : 097f141a499d151e167c85dcb57e66aade7c28cb
In order to call test-linux.sh with the job-script parameter, it needs
to have executable permissions.
Differential Revision: https://phabricator.services.mozilla.com/D22821
--HG--
extra : source : 6f5fc0d644dd1eb83294ce41b2b47be44c2d9783
test-linux.sh defaults to true for NEED_XVFB, while build-linux.sh
defaults to false. If we are using test-linux.sh from mozharness (rather
than mozharness-test), we need to explicitly set NEED_XVFB to false in
order to not use xvfb.
Differential Revision: https://phabricator.services.mozilla.com/D22820
--HG--
extra : source : 53d3443e55d95af494d6c8bdc3d2d7a52c5eff1e
Most of our builds use libstdc++ compat, so they don't care much what
the custom toolchains we use are compiled with. The plain builds, on
the other hand, attempt to stick as closely as possible to a "local"
developer experience, and so don't set up libstdc++ compat. Since we
want to transition to our clang binaries being compiled with gcc 6, we
need a base system image that contains gcc 6 runtime libraries by
default. Debian 9 is just such a system.
Differential Revision: https://phabricator.services.mozilla.com/D22393
--HG--
extra : moz-landing-system : lando
Bug 1486071 intended to fix this, but while the tasks are setup to
restart on exit status 100, there are multiple failure cases where
snapshot.debian.org doesn't respond and the exit status is not 100.
One is dget, when downloading package sources from snapshot.debian.org.
Eventually, those should move to fetch tasks, but in the meantime, we
bubble up get errors with an exit code 100.
mk-build-deps wraps a call to apt-get install, but doesn't return the
exit code that apt-get returns when apt-get returns one. It makes it
hard to distinguish the error modes, but mk-build-deps is unlikely to
fail on anything else than apt-get. Not all apt-get failures would be
due to snapshot.debian.org availability, but that's a tradeoff we
decided was okay in bug 1486071.
Differential Revision: https://phabricator.services.mozilla.com/D22269
--HG--
extra : moz-landing-system : lando
Currently the scopes are handled in some test-specific code. However, there is
logic not to be in generic code.
Differential Revision: https://phabricator.services.mozilla.com/D22447
--HG--
extra : moz-landing-system : lando
This slightly decreases the amount of code that needs to know how to determine this.
Differential Revision: https://phabricator.services.mozilla.com/D22446
--HG--
extra : moz-landing-system : lando
Currently the scopes are handled in some test-specific code. However, there is
logic not to be in generic code.
Differential Revision: https://phabricator.services.mozilla.com/D22447
--HG--
extra : moz-landing-system : lando
This slightly decreases the amount of code that needs to know how to determine this.
Differential Revision: https://phabricator.services.mozilla.com/D22446
--HG--
extra : moz-landing-system : lando
As of the update snapshot, stretch-backports contains version 112.
Depends on D22264
Differential Revision: https://phabricator.services.mozilla.com/D22265
--HG--
extra : moz-landing-system : lando
This has the side effect of addressing bug 1524723 for those images.
Depends on D22263
Differential Revision: https://phabricator.services.mozilla.com/D22264
--HG--
extra : moz-landing-system : lando
When the apt snapshot is more recent than the docker image on the docker
hub, some packages may not be up-to-date.
Depends on D22455
Differential Revision: https://phabricator.services.mozilla.com/D22263
--HG--
extra : moz-landing-system : lando
Because the debian9-base apt configuration doesn't install recommended
packages, we end up needing to install more packages than before. We
could pass --install-recommended to apt-get, but that would make the
image larger than it already was after the upcoming changes, because
new versions of diffoscope come with more recommended dependencies.
The side effect is that this makes the image much smaller than it used
to be, while preserving all the useful recommended packages (we don't
actually need all of them).
Differential Revision: https://phabricator.services.mozilla.com/D22262
--HG--
extra : moz-landing-system : lando
I'd like to use the same format for config values, that get evaluated in different contexts, so don't
to mutate the config for that.
Differential Revision: https://phabricator.services.mozilla.com/D22126
--HG--
extra : moz-landing-system : lando
Artifact mozconfigs are not necessarily up-to-date wrt changes to the
nightly mozconfigs, and all in all, shouldn't be much different from
them.
It's just better to use the nightly mozconfigs (or beta on beta, etc.)
and make the mozconfigs themselves handle the few things that need to be
different when the USE_ARTIFACT environment is set (which is now
consistently set by taskcluster)
This does have the side effect of turning builds that actually don't
support artifact builds red when using --artifact on try, instead of
having them silently not be artifact builds as currently happens.
Depends on D21314
Differential Revision: https://phabricator.services.mozilla.com/D21315
--HG--
extra : moz-landing-system : lando
The artifact builds that are automatically derived using the artifact
template set the USE_ARTIFACT environment variable from taskcluster.
After the previous change, --artifact builds from try syntax do that
too.
That leaves us with only the artifact-build build not doing it, so for
consistency, do it there. That makes it not necessary to set
USE_ARTIFACT from mozconfig.artifact.automation anymore.
Depends on D22056
Differential Revision: https://phabricator.services.mozilla.com/D21313
--HG--
extra : moz-landing-system : lando
Currently, all tasks of kind builds are indiscriminately altered to use
artifacts, but only few of them actually support that, and the others
won't actually have the expected result when that happens. E.g. ASAN
builds with artifacts enabled end up being non-ASAN builds.
Effectively, this makes the artifact flag ignored for builds that don't
support artifacts. One could argue that those builds shouldn't happen at
all, but it feels a better use time of developer's time to just do the
full build they asked for. E.g. if they asked for ASAN with artifacts,
they still get an ASAN build, rather than an error or silently having
the task not happen after the decision task. This also allows to mix
artifact and non-artifact builds.
Further changes down the road are also modifying the artifact builds
configuration, which would actively turn those builds that don't support
artifact builds red (e.g. ASAN), so something has to be done anyways.
The alternative would be filter those builds out.
Depends on D21312
Differential Revision: https://phabricator.services.mozilla.com/D22056
--HG--
extra : moz-landing-system : lando
While try syntax is approaching its EOL, the fact that using it to do
artifact builds does some things subtly differently from using try
config is not helpful.
Depends on D22055
Differential Revision: https://phabricator.services.mozilla.com/D21312
--HG--
extra : moz-landing-system : lando
While the morph was changing the treeherder symbol to `Ba` for all jobs,
doing so with a transform fails because of the conflicting symbol check
(as multiple jobs in the same category would end up with `Ba`). So
instead, we append `a` to the existing symbol.
We also change the documentation wrt templates for try pushes, as the
artifact template is now essentially gone (although technically, mach
try will still set params['templates']['artifacts']['enabled'] for now,
and the template still exists, albeit empty).
Differential Revision: https://phabricator.services.mozilla.com/D22054
--HG--
extra : moz-landing-system : lando
We use autograph-prod for our ci, nightly, and release signing. Autograph-stage doesn't have the same guarantees for availability, so pointing, say, dep-signing at autograph-stage would have resulted in occasional tree closures whenever autograph-stage changes configuration or is down.
However, we also want a way to verify autograph-stage is still valid, after the autograph team makes changes. This task is meant to be add-task'ed; a green result means autograph-stage has signed the mar file correctly.
Differential Revision: https://phabricator.services.mozilla.com/D20749
--HG--
extra : moz-landing-system : lando
They appear to be causing tasks to take several hours to complete.
Differential Revision: https://phabricator.services.mozilla.com/D21775
--HG--
extra : rebase_source : a55cfc24527662427bbeccf0d03f97dca047a3cb
extra : amend_source : 5e352a1ff382353460fdd143d7d0ba52251a5b8a
A recent change caused the treeherder platform for several jobs to have an extra `/` in it.
This add a check to ensure that the platform is formatted correctly, and fixes the tasks
with the incorrect format.
Differential Revision: https://phabricator.services.mozilla.com/D21650
--HG--
extra : moz-landing-system : lando
I've set HGPLAIN in the container entrypoint so that people running
the main script interactively still get the nice features.
Differential Revision: https://phabricator.services.mozilla.com/D21343
--HG--
extra : moz-landing-system : lando
This reverts the refactoring in 0734f7d57cd81464053e7ffacc8897fce1a27d61 so only the firefox blob
gets the new platform. This was causing failure in the subsequent release promotion task, as it made
assumptions about the structure of the balrog blob.
Differential Revision: https://phabricator.services.mozilla.com/D21494
--HG--
extra : moz-landing-system : lando
The bulk of this is copy/pasted from a standard android-api-16 debug
build. The only changes are a few extra environment variables in the
taskcluster config, the subconfig file, and the mozconfig, as well as
the --enable-mozsearch-plugin flag in the mozconfig.
Depends on D20766
Differential Revision: https://phabricator.services.mozilla.com/D20767
--HG--
extra : moz-landing-system : lando
Justin Wood
Marian Raiciof
Chris AtLee
Florin Strugariu
Cosmin Sabou
Thomas Daede
Mike Hommey
Julian Descottes
Bogdan Tara
James Graham
Calixte Denizet
Tom Prince
Bastien Abadie
Mihai Tabara
ffxbld
Rob Wood
shindli
championshuttler
Kartikaya Gupta
Andreea Pavel
Mike Shal
Ian Moody
Jesse Schwartzentruber
Rob Lemley
Gurzau Raul
Ionut Goldan
Aki Sasaki
Connor Sheehan
arthur.iakab
Nathan Froyd
Gian-Carlo Pascutto
Nathan Froyd
Dustin J. Mitchell
Chris Hartjes
Geoff Brown
marian.raiciof
James Willcox
Henrik Skupin
Joel Maher
Jason Laster
alexandru.ionescu
Simon Fraser
Olivier Tilloy
Noemi Erli
Chris Manchester
Csoregi Natalia
Narcis Beleuzu
Gregory Mierzwinski
Emilio Cobos Álvarez
Dan Minor
Johan Lorenzo
Brindusan Cristian
Nick Alexander
Nick Thomas
Dorel Luca
Steve Fink
Florin Strugariu
Byron Campen [:bwc]
Ciure Andrei