Add some SCHEDULES rules so that, when a push only modifies files known to be associated
with a particular test suite, only that test suite is run.
Differential Revision: https://phabricator.services.mozilla.com/D58448
--HG--
extra : moz-landing-system : lando
Some of these were obvious typos. Others probably reflect once-correct components
that have been combined, split, or otherwise obsoleted; for these I've tried to
use the component associated with the bugs for recent changes to the affected files.
Differential Revision: https://phabricator.services.mozilla.com/D55756
--HG--
extra : moz-landing-system : lando
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
Geoff Brown
Ethan Glasser-Camp
Anthony Ramine
Mike Shal
Mike Hommey
Matthew Gaudet
Bob Clary
Bogdan Tara
Chris Manchester
Sebastian Hengst
Dave Hunt
Joel Maher
Matt Brubeck
Dustin J. Mitchell
Noemi Erli
Margareta Eliza Balazs
Nathan Froyd
Ionut Goldan
Attila Craciun
Phil Ringnalda
Andrew Halberstadt
Ryan VanderMeulen
Eric Rahm