It will be relanded once these are complete. This prevents from those tasks
getting scheduled for every push until the initial ones have been completed.
This change introduces a "github-sync" component into tools,
which aims to support synchronizing both wgpu and WebRender with github.
~~It also features a "cargo test" job for standalone wgpu (bug 1596127)~~
The code is ported from "gfx/wr/scripts/wrupdater" folder. Changes are:
1. remove explicit WR parts and make them configurable by command line params
2. detect "mozilla-xxx" tags and use them in addition to the commits
As a follow up, wrupdater will be removed in favor of github-sync.
Status:
- [x] get the CI test job working
- [x] get @kats to fork "wgpu" github for "moz-gfx" bot
- [x] remove the wgpu testing CI job (into separate PR)
- [x] create new secret and reference it
Differential Revision: https://phabricator.services.mozilla.com/D57057
--HG--
extra : moz-landing-system : lando
We've long handled chunks by defining the total number of chunks in our CI
configuration, and then passing that value down into the test harnesses at task
runtime (via the '--this-chunk' and '--total-chunks' parameters). The test
harness then runs an algorithm to determine which tests should be run in "this"
chunk.
There are several problems with this approach, but by far the biggest is that
we can't use test information in our scheduling algorithms. The information
simply isn't available yet. This patch switches things around such that we
determine which tests go in which tasks during the taskgraph generation. This
means we have perfect information around which tasks are running which tests,
and if e.g a ccov or machine learning algorithm deems a particular test
important, we can make sure to *only* schedule the tasks that contain that
test.
I'm planning to enable this a couple suites at a time so we don't accidentally
stop running tests. This specifically only enables this mode for
'mochitest-media', 'mochitest-browser-chrome' and 'mochitest-devtools-chrome'.
I chose these suites because they are the ones that are already using the
'chunk_by_runtime' algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D52729
--HG--
extra : moz-landing-system : lando
Handles 'env' and 'chemspill-prio' configs in the transforms. The 'rebuild'
task config is purposefully excluded from the full_task_graph and instead
handled at the target_tasks stage. Otherwise if a user ran '--rebuild 20' then
retriggered one of those tasks, they'd instead get another 20 which is almost
certainly not what we want.
Differential Revision: https://phabricator.services.mozilla.com/D51417
--HG--
extra : moz-landing-system : lando
This patch enables the iris test suite to run in CI against Windows and Linux shippable builds on mozilla-central and try. The framework is in place for Iris to run against MacOS in CI, but it is currently disabled while bootstrapping issues are sorted out.
Linux uses a new docker image based on the debian10-test parent image that installs preinstalls most of Iris's dependencies. Windows installs a few dependencies using the scoop package manager. Both then install the rest of the python dependencies via pip.
This adds a new toolchain artifact to fetch the iris_firefox git repo without touching the outside network.
Differential Revision: https://phabricator.services.mozilla.com/D41638
--HG--
extra : moz-landing-system : lando
This new task fetches the visualmetrics.py script from the
github.com/mozilla/browsertime repository and runs it in parallel for the
specified jobs. Jobs are specified in a JSON blob passed through to the task in
an environment variable. A follow up patch specifies a command line argument to
make this configuration available to `./mach try {fuzzy|chooser}`
Differential Revision: https://phabricator.services.mozilla.com/D41052
--HG--
extra : moz-landing-system : lando
This new task fetches the visualmetrics.py script from the
github.com/mozilla/browsertime repository and runs it in parallel for the
specified jobs. Jobs are specified in a JSON blob passed through to the task in
an environment variable. A follow up patch specifies a command line argument to
make this configuration available to `./mach try {fuzzy|chooser}`
Differential Revision: https://phabricator.services.mozilla.com/D41052
--HG--
extra : moz-landing-system : lando
Duplicating the old bouncer submission task and having it point to Nazgul in both stage and prod.
Differential Revision: https://phabricator.services.mozilla.com/D42171
--HG--
extra : moz-landing-system : lando
Sign language packs via Autograph instead of AMO.
Differential Revision: https://phabricator.services.mozilla.com/D38148
--HG--
rename : taskcluster/ci/release-sign-and-push-langpacks/kind.yml => taskcluster/ci/release-push-langpacks/kind.yml
extra : moz-landing-system : lando
Sign language packs via Autograph instead of AMO.
Differential Revision: https://phabricator.services.mozilla.com/D38148
--HG--
rename : taskcluster/ci/release-sign-and-push-langpacks/kind.yml => taskcluster/ci/release-push-langpacks/kind.yml
extra : moz-landing-system : lando
Bug 1563711 changed MOZ_FETCHES_DIR to make the MOZ_ANDROID_FAT_AAR_*
environment variables absolute paths. Unfortunately, the replacement
relies on non-osx/windows tasks to run in docker-worker, which is not
necessarily true, and that makes the MOZ_FETCHES_DIR wrong in
non-osx/windows generic-worker tasks. Apparently, that currently works,
but that's not guaranteed to stay this way.
The MOZ_ANDROID_FAT_AAR_* environment variables don't need to be
absolute paths, though. MOZ_FETCHES_DIR is normalized by run-task, and
MOZ_ANDROID_FAT_AAR_* can be set relative to that, which we do here.
Differential Revision: https://phabricator.services.mozilla.com/D40334
Our datadog contract is coming to an end. Soon we'll add influxdb data collection
Differential Revision: https://phabricator.services.mozilla.com/D38086
--HG--
extra : moz-landing-system : lando
