Because DevEdition builds are intended to be shipped, we must force clobbers on all of them. We also need to fix the update channel, which is currently still set to "beta". In order to make it possible to override this we need to change stage_platform to a unique value.
--HG--
extra : amend_source : 84422951ad22665c1cf027882171db01953ff840
To make OS X and Windows DevEdition builds upload to the "devedition" area on archive, instead of "firefox".
--HG--
extra : amend_source : b5472a9c2f27aa59b7f8715800dcb2161fe4252f
We shouldn't be running pymake any more. So code to work around its
behavior is no longer necessary and can be removed. Good riddance.
MozReview-Commit-ID: AlV6ZLiA6WB
--HG--
extra : rebase_source : 56252a8d96f108fd24878e7a26f0d4ffe4a0db45
Now that mozharness is calling `mach build` to invoke the "check" target,
there are no more consumers of the "enable_pymake" config option. So we
remove it from the configs.
We also remove definitions of the "make" executable referring to pymake.
The only call sites I could find for "query_exe('make')" are in
testing/mozharness/scripts/mobile_l10n.py. So most of these definitions of
the "make" executable appear to be a cargo cult or left over from a
previous rewrite (the code we just changed to stop calling "make" wasn't
using query_exe). Since mobile_l10n.py is still using query_exe() to find
the make executable, there's a chance switching away from pymake (if this
patch even does that - I don't think we touched a config file related to
that script) could break something. I'm fine with teasing out that bug.
MozReview-Commit-ID: 7HR6ShAKcoV
--HG--
extra : rebase_source : 07c6a6f7aaab6d7fceeab46b6ca2744c964148dd
We switch mozharness to use `mach build` to invoke the "check" make
target instead of using `make` itself. Because `mach` is the interface
that everyone should use and `make` is an implementation detail.
My editor also snuck in a change to normalize a CRLF line ending.
MozReview-Commit-ID: 4gdE6oeK0Lz
--HG--
extra : rebase_source : 0bfd6503a25f6b4304b596bd59ef99294c011474
There appear to be no in-tree users of this function and it references
"b2g." I'm pretty sure it is dead code.
MozReview-Commit-ID: EHHRQ2iqQoP
--HG--
extra : rebase_source : ec136063dc5e4243232fce5289a8f47bd925b481
We shouldn't be running any Firefox OS automation.
MozReview-Commit-ID: 4ea9SL7jill
--HG--
extra : rebase_source : 6d5c457d14d9d2b2b4abda47a2b3bfa1fa745d36
We shouldn't be running any automation related to Firefox OS. We should
be able to delete these files.
MozReview-Commit-ID: SY5f0GD9NQ
--HG--
extra : rebase_source : 3b7b5b28bc5da554ad9082c1c3115b3ab8de2e0a
These were the last occurrences of "gaia" in the mozharness directory.
MozReview-Commit-ID: 8ACEw1rMoUS
--HG--
extra : rebase_source : b5d98c9166d75a83f5303ee0faa34484b6f998d3
In cases where CPU usage couldn't be recorded, we may incur a division
by 0 exception.
While we should figure out why we're not collecting CPU data, this patch
papers over the uncaught exception which was causing mozharness to bail.
MozReview-Commit-ID: 3PrIl6cEzuf
--HG--
extra : rebase_source : ece317b73af6a5b47ccad30981963457e6c6b9a8
These builds do not have a distinct variant and they do not have an artifact
build equivalent, so specify this in their respective mozharness configs.
MozReview-Commit-ID: CHMglUoP8LR
--HG--
extra : rebase_source : a82323616c8266a6e7d4d82fde0da441da3cc3f3
The previous commit changed our default behavior to make these entries no longer
necessary.
MozReview-Commit-ID: 5bKEH7zbbWi
--HG--
extra : rebase_source : 431d7f6df1136a20ed5796c23832879c5be99790
No builds other than vanilla opt and debug builds are supported by the artifact
code currently, so prevent variant builds from being replaced by artifact builds
by modifying mozharness' replacement logic to replace a build with an artifact
build only when it is a regular opt or debug build or when specified by a
config.
MozReview-Commit-ID: KUUgrbga53l
--HG--
extra : rebase_source : d3c6e3929bf02893ec18f54b0a8739181067e22b
The primary change here is to increase the number of times a failed
download is retried, when downloading test_packages.json and test zip
files, in hopes of recovering from more temporary service interruptions.
This commit makes sccache dump JSON stats at the end of the build, and then
reads them in `BuildScript.generate_build_stats` and adds them to the
build_metrics we submit to Perfherder. The stats dumping is done in
Makefile.in where we currently dump verbose sccache stats because sccache
doesn't persist stats to disk right now and it will also shut down its server
process after 5 minutes, so when the post-build automation steps take more
than 5 minutes the server shuts down and the stats are lost.
Currently it's collecting:
* Cache hit rate
* Cache write errors
* Non-cacheable requests (compiler invocations that sccache can't cache)
We can always grow this list later.
MozReview-Commit-ID: J9CwU7XB05I
--HG--
extra : rebase_source : 084b09c3b0621330ac331a99b1bca9a15cf833b7
The current setup is confusing, and, I guess, an inheritage from when
the same mozharness configs were used for buildbot and taskcluster jobs.
When mozharness calls tooltool_wrapper.sh, it doesn't set the
TOOLTOOL_CACHE environment variable from its configuration, like it does
for other commands. Instead, it passes the -c flag with the path from
its configuration. Then tooltool_wrapper.sh proceeds with ignoring the
-c flag and using TOOLTOOL_CACHE from the original environment,
inherited from the taskcluster setup script.
The upcoming new wrapper for tooltool in bug 1355731 doesn't keep this
confusing behavior, and respects the cache directory it's given on the
command line.
Now that most jobs run on taskcluster, and few use the same mozharness
config between buildbot and taskcluster, we can now go ahead and change
the TOOLTOOL_CACHE path in the mozharness config to match reality.
The list of files modified was generated from looking at
MOZHARNESS_CONFIG values in the full-task-graph.json file coming from
the Gecko decision task.
--HG--
extra : rebase_source : fe2baee48baffae52f738b4168f862c81370fcef
Those jobs, running on taskcluster, don't have a persistent cache
anyways, so we might as well not pretend setting a tooltool cache does
anything, especially considering the configured directory is not
writeable anyways.
--HG--
extra : rebase_source : a435bce42b4c181a6690a42e068bb2e0e875d5e8
We'd like to ensure that both parallel and serial traversal in Stylo are
tested on automation. Since e10s is the future, we've chosen to force
parallel traversal on during e10s tests, and force serial traversal on
during non-e10s tests.
This is from changeset 249a47720ddcf896a9f07600c429a1b4492b805e from
the version-control-tools repo. It contains a fix to restore
compatibility with Mercurial 3.7, which caused mozharness tests
to fail because that test pins Mercurial 3.7.3 in a requirements
file. This is a bug. But getting a modern robustcheckout deployed
is more important than upgrading that test.
File copied verbatim from changeset e0d30b04dac6bcd36b57c711d9c5b1c280f63390
from the version-control-tools repository.
The updated extension now detects and retries after network failures
where it didn't before. This should cut down on the number of
intermittent failures.
MozReview-Commit-ID: 2bFLcGEARTJ
--HG--
extra : rebase_source : ac43b1925713ce33e1d0d835323efc02c30aed74
Wes Kocher
Ben Hearsum
Gregory Szorc
Xidorn Quan
Carsten "Tomcat" Book
Shing Lyu
Joel Maher
Sebastian Hengst
Chris Manchester
Johan Lorenzo
Peter Moore
Justin Wood
Geoff Brown
Mike Hommey
Ted Mielczarek
Nathan Froyd
William Lachance
Iris Hsiao