Also adjust artifacts based on dep_kind, and make build-notarization-part-1
a build-signing dependency.
Differential Revision: https://phabricator.services.mozilla.com/D57738
--HG--
extra : moz-landing-system : lando
We should move beetmover-geckoview to the multi_dep loader. Until then, this should un-break us when we adjust build-signing deps. Unknown deps will still lead to declarative artifacts bustage.
Differential Revision: https://phabricator.services.mozilla.com/D57732
--HG--
extra : moz-landing-system : lando
The single-locale group_by function works for tasks with a single locale each, but doesn't work when we want to maintain the same l10n chunks as our parent task. Because we want to make nightly-l10n-signing multi_dep, we'll need to group_by chunk-locales.
Differential Revision: https://phabricator.services.mozilla.com/D57730
--HG--
extra : moz-landing-system : lando
First, let's add {only,not}-for-attributes to multi_dep so we can switch single_dep kinds over more easily. Second, let's put it into its own helper function, so we don't have to copy the same set of if blocks in each grouping function.
Differential Revision: https://phabricator.services.mozilla.com/D57729
--HG--
extra : moz-landing-system : lando
This patch adds all Fenix pageload tests to raptor-browsertime. To handle how the task is specified (specifying run-on-projects by raptor-test) the raptor.py taskgraph transforms had to be modified.
The transform modifications change a couple things. First, the `raptor-subtests` is now the first thing to have it's keyed-by entries handled because it's values are used as keyed-by entries on other fields such as run-on-projects. Once it's values are resolved, we immediately split/clone the task into one per subtest entry (adding a `chunk-number` field that is used for more setup in the next transforms). After this, the rest of the fields have their keyed-by entries resolved.
Differential Revision: https://phabricator.services.mozilla.com/D63222
--HG--
extra : moz-landing-system : lando
This patch adds a scenario that ends up syncing the generated profile into FxSync.
Differential Revision: https://phabricator.services.mozilla.com/D53789
--HG--
extra : moz-landing-system : lando
This patch adds a scenario that ends up syncing the generated profile into FxSync.
Differential Revision: https://phabricator.services.mozilla.com/D53789
--HG--
extra : moz-landing-system : lando
The hard limit prevents program to set a value higher than the soft
limit for themselves, and it turns out Firefox does that.
Also, keep the soft limit to its original value if it was already less
than 1024.
Differential Revision: https://phabricator.services.mozilla.com/D63623
--HG--
extra : moz-landing-system : lando
Avoid intermittent task timeouts by increasing the max-run-time for tsan xpcshell.
These tasks are unbalanced (wide variance in run time from one chunk to the next)
apparently because the tsan times vary significantly on a test-by-test basis when
compared with normal xpcshell tasks on the same base platform. Rather than go to
extraordinary measures to balance this particular set of tests, increase the max
run time so that timeouts are avoided when one chunk runs particularly long.
Differential Revision: https://phabricator.services.mozilla.com/D63741
--HG--
extra : moz-landing-system : lando
Installing the necessary build dependencies end up being impossible on
Debian 9 because of lack of multiarch support for libfreetype. It would
be possible to do it by upgrading to Debian 10, but on the other hand,
it's also possible to build Wine without freetype, and even without X
for that matter, and that we don't need X support.
Following the build procedure from https://wiki.winehq.org/Building_Wine#Shared_WoW64
(which forgets to talk about where `make install` goes, but apparently,
it's needed in both places)
Differential Revision: https://phabricator.services.mozilla.com/D63636
--HG--
extra : moz-landing-system : lando
This patch disables browsertime tests on all windows 2017 reference hardware variants (matched with .*-ref-hw-2017/.*) and prevents them from running anywhere by default.
Differential Revision: https://phabricator.services.mozilla.com/D63694
--HG--
extra : moz-landing-system : lando
This patch allows us to use the enable/disable charging commands for power tests, and moves the android power tests onto the primary perf bitbar devices. It also removes the use of the --host argument that was previously required to run power tests. Disabling charging occurs when the device is being setup, and when the device is being setup within raptor (to accomadate different entry points). Enabling charging occurs when the mach command finishes, or during the clean_up stage in raptor in normal, passing executions. In case any errors occur within raptor, and due to the multiple entry points, charging is enabled where those errors are caught as well.
Differential Revision: https://phabricator.services.mozilla.com/D42373
--HG--
extra : moz-landing-system : lando
The script was not executable, and apparently it is not happy with
anything other than clang.
Differential Revision: https://phabricator.services.mozilla.com/D63447
--HG--
extra : moz-landing-system : lando
This build artifact is only built on platforms that don't use cross
compilation, because the result of the build is used to generate
the artifact. This means the process doesn't work on at least OSX.
Normandy capabilities do not currently vary by platform, so it is
reasonable to not have this on every platform.
Differential Revision: https://phabricator.services.mozilla.com/D57848
--HG--
extra : moz-landing-system : lando
We set it here, rather than depending on taskcluster script to set it, so that
we can use it to construct the objdir we will use.
Differential Revision: https://phabricator.services.mozilla.com/D62481
--HG--
extra : moz-landing-system : lando
We use the shell to expand this, rather than substituting the value here,
because `GECKO_PATH` will be set in the `run_task` transform (after the rest of this
stack lands).
Differential Revision: https://phabricator.services.mozilla.com/D62480
--HG--
extra : moz-landing-system : lando
while allowing it to be tweakable without editing run-task each time
(rebuilding all docker images as a consequence)
Differential Revision: https://phabricator.services.mozilla.com/D62701
--HG--
extra : moz-landing-system : lando
'fixed' because Talos reports FPS and I'm not sure how to change it.
'30000' because so long as we're over ~3fps, we should get solid perf
data. (and Chrome hits 60fps for me on 10k, but ~30fps at 30k, and we
want room to grow)
Differential Revision: https://phabricator.services.mozilla.com/D63011
--HG--
extra : moz-landing-system : lando
This removes the no-longer-supported Node8 stuff from the taskcluster configuration and the repack script.
Depends on D62782
Differential Revision: https://phabricator.services.mozilla.com/D62783
--HG--
extra : moz-landing-system : lando
Depends on D62781, which upgrades NodeJS to 10.19.0. This patch merely changes the -node aliases so that we now default to Node 10.
Differential Revision: https://phabricator.services.mozilla.com/D62782
--HG--
extra : moz-landing-system : lando
NodeJS 8.x is End-of-Lifed and is no longer receiving security fixes. 10.19.0 is now the oldest Long Term Support version of NodeJS, and it has just been released with several HTTP security fixes.
Differential Revision: https://phabricator.services.mozilla.com/D62781
--HG--
extra : moz-landing-system : lando
This patch adds a v80 chromedriver for chrome. It also removes old chromedrivers (v76, and v77) from the fetch tasks.
Differential Revision: https://phabricator.services.mozilla.com/D62897
--HG--
extra : moz-landing-system : lando
As opposed to what was intended, the directories weren't eliminated
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D62700
--HG--
extra : moz-landing-system : lando
Provides denylisted attributes to copy over in the fusing of chunked portions of the taskgraph. Without
denylisting these we have changes on these related kinds in json, due simply to ordering of total tasks.
Differential Revision: https://phabricator.services.mozilla.com/D62637
--HG--
extra : moz-landing-system : lando
GCE instances use Ubuntu 18.04, which is known to cause issues in
valgrind builds (Bug 1545094), while EC2 uses Ubuntu 14.04.
Move valgrind builds back to GCE to avoid perma fail of these jobs.
Differential Revision: https://phabricator.services.mozilla.com/D62552
--HG--
extra : moz-landing-system : lando
In GCP we have the double the number of core compared to AWS
counterparts, but we use the same amount of memory. Request the builds
to be less parallel to avoid OOM.
Differential Revision: https://phabricator.services.mozilla.com//D62514
Accepting an argument to specify a tarball of browsertime results was an
artifact of the previous split between the (now removed) visual-metrics and
visual-metrics-dep job kinds. Now that we are always providing the browsertime
results as a fetch task, can retrieve it directly from `MOZ_FETCHES` directory.
Differential Revision: https://phabricator.services.mozilla.com/D62364
--HG--
extra : moz-landing-system : lando
Raptor was previously generating two artifacts for the `run-visual-metrics.py`
script to consume: `jobs.json` and `application.json`. These artifacts have
been merged.
Differential Revision: https://phabricator.services.mozilla.com/D62363
--HG--
extra : moz-landing-system : lando
In bug 1601414, the JSON parsing and validating code was refactored into a
single method. However, the `return 1` in case of error was carried over. That
was correct in the previous version because that 1 was being passed to `exit()`
later on. However, we were now returning 1 to callers of `read_json` when the
schema did not match, resulting in an opaque unrelated error (`TypeError: 'int'
object is not subscriptable`).
Now `read_json` is correctly raising an exception so its callers know when it
fails.
Differential Revision: https://phabricator.services.mozilla.com/D62361
--HG--
extra : moz-landing-system : lando
The `extraOptions` key in the Perfherder output was only required until Bug
1593198 landed.
Differential Revision: https://phabricator.services.mozilla.com/D62360
--HG--
extra : moz-landing-system : lando
The `run-visual-metrics.py` script was intended to consume a `jobs.json` file
containing one `browsertime.json` per video. However it was not being used as
such and was continuously re-processing the first video specified in the
`browsertime.json` file. If a job were submitted with a `browsertime.json`
containing 15 videos and 15 different videos, only the first would be
processed. This leads to us having incorrect metrics because over all runs all
the metrics will be identical.
Now we only specify the `browsertime.json` in the `jobs.json` file and extract
the paths to videos from there. Also because we are never downloading inputs
this way, we get to remove some dead code and our dependency on `requests`.
Differential Revision: https://phabricator.services.mozilla.com/D62320
--HG--
extra : moz-landing-system : lando
We are migrating the worker used by builds from AWS to GCP. We have had tier- 3 GCP builds for initial testing. We are replacing those with tier-3 AWS builds to ensure they keep working so we are able to switch back.
Differential Revision: https://phabricator.services.mozilla.com/D60042
--HG--
extra : moz-landing-system : lando