The bitbar workers do not support taskcluster-proxy, and so tooltool internal downloads
don't work, even though they had been requested.
Differential Revision: https://phabricator.services.mozilla.com//D52480
--HG--
extra : amend_source : f4ad4bec75b30da67d6769cceedb70a7957cb638
generic-worker uses localhost:8080 for the taskcluster proxy. Many jobs,
including raptor also try to use that port. Disable using the proxy
when only public tooltool downloads were requested, since this
was how thing were configured before.
Differential Revision: https://phabricator.services.mozilla.com//D52478
--HG--
extra : amend_source : 375cb2d84a2dcfbb821f18e4858d86f07db0539b
MANUAL PUSH: Initial push to test new firefox-ci taskcluster cluster.
Differential Revision: https://phabricator.services.mozilla.com/D52453
--HG--
extra : histedit_source : 4bcac76e95d5566db7bb892d44830c03a615f78f
Add new test platforms "android-em-7.0-x86_64-qr/opt" and
"android-em-7.0-x86_64-qr/debug", which run a new test-set
"android-x86_64-qr-tests", which includes reftests and crashtests.
Differential Revision: https://phabricator.services.mozilla.com/D51295
--HG--
extra : moz-landing-system : lando
This also moves the 'mach' docs from /python/mach to /mach. The reason being
that 'mach' doesn't really have anything to do with Python other than its
implemented in it.
Differential Revision: https://phabricator.services.mozilla.com/D52253
--HG--
extra : moz-landing-system : lando
This worker-type isn't working with worker-manager, so backout the change
switching to it.
MANUAL PUSH: Prepration for testing firefox-ci cluster in advance of TCW
Differential Revision: https://phabricator.services.mozilla.com/D52119
--HG--
extra : histedit_source : 4f2689d47f25864b87abae6eeb55cc09936f4a61
We originally had a different plan related to migrating worker-types to a new cluster.
Remove the code that supported that.
Differential Revision: https://phabricator.services.mozilla.com/D52076
--HG--
extra : rebase_source : 1c0945e96add41659f56013a01d4d246e2d69dd3
extra : histedit_source : 03acebc1cc6796bd60cd472bc3c5c92a9c17f02b
MANUAL PUSH: (a) This patch will cause a ton of toolchain rebuilds, and might as well do that on central right now rather than autoland, and (b) We want to test the new Taskcluster instance today, and will be testing THAT on m-c, so we'll need this patch on m-c before we can test the new cluster as well.
tooltool at present needs to support production (legacy cluster) but its auth system is tied to that cluster.
Which means that using tooltool in the new cluster ahead of TCW is harder. We have swapped the credentials for the tooltool staging deployment to use the new tc cluster, so when we're using the taskcluster proxy we need to have it swap between legacy and new tooltool url's depending on which cluster (ROOT_URL) we're using.
This patch is intended to be ok to land on production code today, and could be backed out after the TCW when production tooltool will be configured to work with the firefox-ci cluster itself.
Differential Revision: https://phabricator.services.mozilla.com/D52089
MANUAL PUSH: (a) This patch will cause a ton of toolchain rebuilds, and might as well do that on central right now rather than autoland, and (b) We want to test the new Taskcluster instance today, and will be testing THAT on m-c, so we'll need this patch on m-c before we can test the new cluster as well.
tooltool at present needs to support production (legacy cluster) but its auth system is tied to that cluster.
Which means that using tooltool in the new cluster ahead of TCW is harder. We have swapped the credentials for the tooltool staging deployment to use the new tc cluster, so when we're using the taskcluster proxy we need to have it swap between legacy and new tooltool url's depending on which cluster (ROOT_URL) we're using.
This patch is intended to be ok to land on production code today, and could be backed out after the TCW when production tooltool will be configured to work with the firefox-ci cluster itself.
Differential Revision: https://phabricator.services.mozilla.com/D52089
--HG--
extra : amend_source : 479de00fdb9a93fc4d4211613bdc3ebf965f6492
This patch prevents the visual-metrics tasks from scheduling browsertime tests on mozilla-central by removing the run-on-projects setting (setting it to []). The run-on-projects setting is now set during the visual-metrics transformation so that it is the same as the dependent task so it will only run on projects that the dependent task runs on. Also, this patch enables browsertime TP6-1 on mozilla-central for chrome, firefox and geckoview.
Differential Revision: https://phabricator.services.mozilla.com/D52061
--HG--
extra : moz-landing-system : lando
This is the third, and final, part of a patch that adds chrome support to raptor-browsertime.
In this part, all the changes from the previous 2 parts are integrated in raptor and browsertime. The main change is that the browsertime-chromedriver paths created in taskcluster's `tests.py` are changed to include a `{}` for inserting the chrome version that is used in production (formatting is done within raptor). The Perftest class structure is slightly modified as well here to accommodate these changes.
There are also some changes to how the taskcluster definitions are made to make it easier to specify how chrome must be handled. The 'limit-platforms' and 'run-visual-metrics' fields are added for this purpose to limit chrome's platforms and disable visual-metric tasks.
Finally, chrome is missing some results in browsertime (relative to firefox) and at least one of the other results is scattered into a different location. The results.py and output.py changes handle this issue.
Differential Revision: https://phabricator.services.mozilla.com/D48898
--HG--
extra : moz-landing-system : lando
This is the second part of a patch that adds chrome support to raptor-browsertime.
This part of the patch adds fetch tasks to handle multiple chrome versions running in production. These fetch tasks provide a tar that the chrome browsertime can use to get a chromedriver compatible with the chrome version available on the testing machine. The artifacts are converted to `.tar.zst` so that they can be prefixed with the chome version that they are compatible with.
Differential Revision: https://phabricator.services.mozilla.com/D48897
--HG--
extra : moz-landing-system : lando
With Bug 1579189 we are going to raise the minimum clang version to 5. But in clang 5
and clang 6 an issue has been introduced where the `Decl` nodes from the `AST` don't
contain all of the annotation attributes. The missing attributes can cause static
analysis failures. We are therefore going to disable the static analysis for the
base-toolchain clang builds as a workaround.
Differential Revision: https://phabricator.services.mozilla.com/D52025
--HG--
extra : moz-landing-system : lando
With this patch applied but Bug 1592402 not fixed, I got:
```
Traceback (most recent call last):
File "/home/callek/mozilla/hg/mozilla-central/taskcluster/mach_commands.py", line 379, in show_taskgraph
tg = getattr(tgg, graph_attr)
File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/generator.py", line 151, in full_task_graph
return self._run_until('full_task_graph')
File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/generator.py", line 351, in _run_until
k, v = self._run.next()
File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/generator.py", line 287, in _run
yield verifications('full_task_graph', full_task_graph, graph_config)
File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/util/verify.py", line 36, in __call__
graph.for_each_task(verification, scratch_pad=scratch_pad, graph_config=graph_config)
File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/taskgraph.py", line 31, in for_each_task
f(task, self, *args, **kwargs)
File "/home/callek/mozilla/hg/mozilla-central/taskcluster/taskgraph/util/verify.py", line 240, in verify_task_graph_symbol
key,
Exception: Duplicate toolchain-alias in tasks `toolchain-linux64-clang-9`and `toolchain-linux64-clang-9-cross`: linux64-clang
```
Differential Revision: https://phabricator.services.mozilla.com/D51101
--HG--
extra : moz-landing-system : lando
Having a distinction between -chunked and not adds unnecessary complexity. It's
possible to simply remove them because:
1. The mozharness definitions for 'jittest' and 'jittest-chunked' are
identical, so it is literally not serving any purpose.
2. The definitions for 'mochitest' only add either '--chunk-by-dir' or
'--chunk-by-runtime'. Both of these are no-ops in the mochitest harness
unless '--total-chunks' is also supplied. Therefore, if we ever use these
suites without chunking (which I don't think we do anyway), then it'll
still work fine as those options won't have any affect.
Differential Revision: https://phabricator.services.mozilla.com/D51173
--HG--
extra : moz-landing-system : lando
MANUAL PUSH: Needed on central to populate the index for a non-gecko release expected today.
Differential Revision: https://phabricator.services.mozilla.com/D51309
--HG--
extra : rebase_source : 02ca5e6033c7708c2cc462f2ef76c3ec661ed20f
extra : amend_source : 4169f1357dbf29de60fcb80c2a46aee5c867a29a
We need this change so that the newly-built clang will have
C++17-compatible libstdc++ headers installed. I believe this change also
means that the newly-built clang (and associated tools) links against
GCC 7's libstdc++, but we set RPATH or similar appropriately, so there
shouldn't be issues stemming from that.
MANUAL PUSH: toolchain patches are requested to land on inbound
Differential Revision: https://phabricator.services.mozilla.com/D41251
This patch changes the browsertime archive built as a toolchain from a .zip archive to a .tar.bz2 archive to prevent the large amount of verbose unpacking output we currently see.
Differential Revision: https://phabricator.services.mozilla.com/D50995
--HG--
extra : moz-landing-system : lando
