If the run task generates bad profile data, the merge step in the
profile-use task will fail. However, retrying the profile-use task
doesn't fix the problem, and there isn't a straightforward way to retry
the run task in this situation. Instead we can add a clang toolchain to
all the run tasks, and perform the merge there.
This means the output from the run task will always be a successfully
merged file called 'merged.profdata', and we no longer need to perform
the merge as part of the profile-use build as a GENERATED_FILES step.
Depends on D45262
Differential Revision: https://phabricator.services.mozilla.com/D45263
--HG--
extra : moz-landing-system : lando
We'll require preprocessing that configure subst files don't allow in
the next change, so prepare for that.
Differential Revision: https://phabricator.services.mozilla.com/D43011
--HG--
extra : moz-landing-system : lando
These two mozconfigs are used for the 1st and 3rd stages of PGO.
'profile-generate' is used for the 1st stage to generate a firefox
binary with instrumentation enabled. Since it is only used for getting
profile data, we don't run tests against it or need crashreporter
symbol.s
The 'profile-use' mozconfig is for the 3rd and final stage were we
produce the fully optimized build. The profiling information and jarlog
are input artifacts produced by the 2nd stage (running the
profileserver).
Differential Revision: https://phabricator.services.mozilla.com/D15749
--HG--
extra : moz-landing-system : lando
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
..and remove support for when.files-changed in the test kind. It is still used
for other kinds, and that will be addressed in other bugs.
This is re-landing of this bug, now without running test-verify excessively.
MozReview-Commit-ID: GBilXAktICZ
--HG--
extra : rebase_source : 6cc9a3b5a365d74689946bfa0296f51bc08c2113
When building with a --enable-project that is neither js nor a
toolkit-based one (like browser or mobile/android), we don't want to be
building things that are specific to gecko and/or spidermonkey.
At the same time, this lifts the exception that js standalone doesn't
have an app.mozbuild included, and makes the moz.build parsers that
don't set a MOZ_BUILD_APP get the same information as they were through
toolkit.mozbuild.
We still keep mfbt, build and a few other DIRS set from the top-level,
because at the moment, there aren't really any --enable-project that
would benefit from those not being recursed.
When first introduced, test-verify was only run when .js/.html/.xul/.xhtml files
were changed. Recently, it seems to run on every push. This is a speculative fix:
There may be confusion between "test-verify" and "test-verification" so I am
using "test-verify" consistently.
The files generated from the contents of probes/ are never used even
with dtrace enabled, and mozilla-trace.d actually never contained probes
definitions. The js engine has probes of its own, and separate scripts
to generate the corresponding source headers.
(see e.g. js/src/devtools/javascript-trace.d)
--HG--
extra : rebase_source : ad60902f087e81cdaced3bf858454e4cecfc8f11
This just adds two basic tests, one for a passing test and another for a
failing one. In mochitest, we use privileged APIs to also tests crashes,
assertions, asan and leaks. But these APIs aren't available to reftests
so I'm not sure how we can test these things.
I figure it's not worth holding the framework up on this though, I'll file
a follow-up to figure out something to do for that.
MozReview-Commit-ID: 59TSbsugT5T
--HG--
extra : rebase_source : 72ecd817017c8b7d55eab879db4f6ad5fecc54c0
The current way to configure compare-locales has a lot of
assumptions that make our l10n system really stubborn.
The generic configuration is independent of python, and uses
toml files for configuration. They're still modular, but
there's only one file format.
See http://moz-l10n-config.readthedocs.io/en/latest/fileformat.html
for the specification.
Also fixes a few nits in filter.py, where we compared the
entity key as bool, which is false if we pass in ''.
Explicitly compare as "entity is None" to be precise about
when we're checking files.
MozReview-Commit-ID: 5TmfobaImF4
--HG--
extra : rebase_source : 84e56eb2076e74f79677df9e0368811579c1f173
This will create a mochitest selftest harness based on |mach python-test|. There
is also a basic test that checks whether TEST-PASS and TEST-UNEXPECTED-FAIL work.
MozReview-Commit-ID: Jqyhbj7nC6z
--HG--
extra : rebase_source : d73b37305590a415e350ee45785a85635e7d4209
The current way to configure compare-locales has a lot of
assumptions that make our l10n system really stubborn.
The generic configuration is independent of python, and uses
toml files for configuration. They're still modular, but
there's only one file format.
See http://moz-l10n-config.readthedocs.io/en/latest/fileformat.html
for the specification.
Also fixes a few nits in filter.py, where we compared the
entity key as bool, which is false if we pass in ''.
Explicitly compare as "entity is None" to be precise about
when we're checking files.
MozReview-Commit-ID: 5TmfobaImF4
--HG--
extra : rebase_source : 7c6feee0aa178315cc69fd6e8c7938365193224c