The max-run-time for tasks appears to have been mostly cargo
culted. In particular, a value of 36000 (10 hours) is quite absurd:
no single task takes that long to execute.
This commit reduces the max-run-time of several tasks to
more reasonable values. The goal here is to prevent
excessively long-running tasks. There is definitely room to
further tweak values to further mitigate long-running tasks. But
let's bite off the biggest chunk first, since that doesn't
require much mental effort.
There is a possibility I overshot on some of these tasks. If we
get timeouts, we can always increase the timeout again.
Differential Revision: https://phabricator.services.mozilla.com/D1716
The by-project and by-build-platform are collapsed by resolve_keyed_by(), and in turn by keymatch() in
utils/attributes.py. That needs a regexp to look for matches (if a simple match isn't possible). Rev
39eed777c0c4 missed that when it landed. The trailing hypens are to distringuish between the two linux
platforms.
MozReview-Commit-ID: LiAJpfV71Ws
--HG--
extra : rebase_source : 6952e4b6be4b05cc7917efba8a346211d1e5c7e0
Instead of clang 4, which they were the last to use, so remove the
clang 4 toolchain.
--HG--
extra : rebase_source : d03a083e9217aeb6c1d2c91decb978426f0e8d1a
For those toolchains built with clang, use clang 6.
The only jobs remaining to use the clang 3.9 toolchain are the
base-toolchains build jobs.
--HG--
extra : rebase_source : 1fe92e9e2730c11ce5ce87dddd6496228c3d270c
Many builds have been using clang 6 explicitly because they needed
features or fixes from it that weren't available in earlier versions.
Now that other builds have kept up, it's probably desirable to keep
everything in sync.
--HG--
extra : rebase_source : deb9daaf792d05518e17b1c48589a3b33035a7ab
The linux64-clang toolchain alias is currently clang 5. Switch it to
clang 6, but keep the spidermonkey tsan builds on clang 5 because of
bug 1467673.
The LLVM headers that come with clang 6 contain a DEBUG define that
conflicts with our DEBUG define and breaks the clang-plugin build,
so force unset ours.
--HG--
extra : rebase_source : aae88f1166108f003b06c022f14d5f4c61fc1ed9
Chains a release-eme-free-repack-beetmover-checksums kind after release-eme-free-repack-beetmover, to move
the target.checksums generated by the latter into the beetmover-checksums/ in candidates directory. Those
are then consumed by release-generate-checksum kind.
A lot of details like scopes, worker & provisioner, attributes, as well as data like repack_id and
partner_path, are inherited directly from the parent beetmover task. Mainly to avoid recalculating them.
In contrast to nightly builds, GPG signing of target.checksums has not been implemented. I don't believe
that adds any value in our current system because the sigs are not verified.
MozReview-Commit-ID: 38iz3J2PAXh
--HG--
extra : rebase_source : 8f2bebe747d97437780f1bc0d9e2f42159aee8a6
Any run-task task could exit with EXIT_PURGE_CACHES and expect the
task to be retried. Before this commit, we only registered this exit
code for tasks "using: run-task." That excluded mozharness and
a handful of other "using" flavors.
With this commit, we register the exit codes for all run-task tasks
by sniffing for the presence of run-task in the low-level code that
emits the task definition. This should prevent run-tasks tasks
from falling through the cracks and not having their exit codes
result in meaningful behavior.
Differential Revision: https://phabricator.services.mozilla.com/D1715
Mike Hommey
Gregory Szorc
Joel Maher
Kartikaya Gupta
Andreea Pavel
Dorel Luca
Justin Wood
Simon Fraser
Sebastian Hengst
Nick Thomas
shindli
David Major
Rob Wood
Geoff Brown
Ciure Andrei
Eric Rahm
Bhavesh
Csoregi Natalia
Brindusan Cristian
Narcis Beleuzu
Chris Manchester
Chris AtLee
Ben Hearsum