Bug 1303806 moved `GeckoJavaSampler` to be Fennec-only as part of a general push
to slim GeckoView down. But there is no reason to restrict to Fennec and it is useful
for other non-Fennec GeckoView vehicles.
This patch moves the `GeckoJavaSampler` inside `geckoview` and changes profiler
code to make Java sampling work in both GeckoView and Fennec.
Depends on D33522
Differential Revision: https://phabricator.services.mozilla.com/D33502
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoJavaSampler.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java
extra : moz-landing-system : lando
If MOZ_BASE_PROFILER_STARTUP and MOZ_PROFILER_STARTUP are set, this will integrate
a pre-XPCOM startup profile into the main profile.
It is stored as separate threads (in a single JSON string that is moved around),
which will appear as a new track under the main process.
Only adding threads from BaseProfiler means a better integration with Gecko
Profiler profiles, and is more efficient: Less code, and a smaller memory
footprint.
Differential Revision: https://phabricator.services.mozilla.com/D31932
--HG--
extra : moz-landing-system : lando
Running identical (but separate) InitializeWin64ProfilerHooks in both profilers
confuses the DLL interceptor and the 2nd one crashes because of unexpected
opcodes introduced by the 1st one.
If MOZ_BASE_PROFILER is defined, Gecko Profiler will use that implementation of
InitializeWin64ProfilerHooks instead of its own; and that code also has a guard
so that it effectively only run once even if called from both profilers.
Differential Revision: https://phabricator.services.mozilla.com/D31931
--HG--
extra : moz-landing-system : lando
Notice the extra 'BASE' in the env-var names.
This is to control BaseProfiler separately from the Gecko Profiler.
Differential Revision: https://phabricator.services.mozilla.com/D31928
--HG--
extra : moz-landing-system : lando
If MOZ_BASE_PROFILER_STARTUP and MOZ_PROFILER_STARTUP are set, this will integrate
a pre-XPCOM startup profile into the main profile.
It is stored as separate threads (in a single JSON string that is moved around),
which will appear as a new track under the main process.
Only adding threads from BaseProfiler means a better integration with Gecko
Profiler profiles, and is more efficient: Less code, and a smaller memory
footprint.
Differential Revision: https://phabricator.services.mozilla.com/D31932
--HG--
extra : moz-landing-system : lando
Running identical (but separate) InitializeWin64ProfilerHooks in both profilers
confuses the DLL interceptor and the 2nd one crashes because of unexpected
opcodes introduced by the 1st one.
If MOZ_BASE_PROFILER is defined, Gecko Profiler will use that implementation of
InitializeWin64ProfilerHooks instead of its own; and that code also has a guard
so that it effectively only run once even if called from both profilers.
Differential Revision: https://phabricator.services.mozilla.com/D31931
--HG--
extra : moz-landing-system : lando
Notice the extra 'BASE' in the env-var names.
This is to control BaseProfiler separately from the Gecko Profiler.
Differential Revision: https://phabricator.services.mozilla.com/D31928
--HG--
extra : moz-landing-system : lando
Changes:
- require `--full` keyword for `./mach try fuzzy` in order to schedule android-hw jobs to hopefully reduce the backlog
Differential Revision: https://phabricator.services.mozilla.com/D33834
--HG--
extra : moz-landing-system : lando
If MOZ_BASE_PROFILER_STARTUP and MOZ_PROFILER_STARTUP are set, this will integrate
a pre-XPCOM startup profile into the main profile.
It is stored as separate threads (in a single JSON string that is moved around),
which will appear as a new track under the main process.
Only adding threads from BaseProfiler means a better integration with Gecko
Profiler profiles, and is more efficient: Less code, and a smaller memory
footprint.
Differential Revision: https://phabricator.services.mozilla.com/D31932
--HG--
extra : moz-landing-system : lando
Running identical (but separate) InitializeWin64ProfilerHooks in both profilers
confuses the DLL interceptor and the 2nd one crashes because of unexpected
opcodes introduced by the 1st one.
If MOZ_BASE_PROFILER is defined, Gecko Profiler will use that implementation of
InitializeWin64ProfilerHooks instead of its own; and that code also has a guard
so that it effectively only run once even if called from both profilers.
Differential Revision: https://phabricator.services.mozilla.com/D31931
--HG--
extra : moz-landing-system : lando
Notice the extra 'BASE' in the env-var names.
This is to control BaseProfiler separately from the Gecko Profiler.
Differential Revision: https://phabricator.services.mozilla.com/D31928
--HG--
extra : moz-landing-system : lando
Key features in this commit:
- support for `contentfulSpeedIndex` visual metric
- support for the Gecko Window Recorder (Desktop only)
- support for the Gecko Profiler (Desktop only)
- partial support for GeckoView on Android
Differential Revision: https://phabricator.services.mozilla.com/D32907
--HG--
extra : moz-landing-system : lando
Since it's not a xul document anymore we can't rely on the xul.js lint preprocessor.
This means we need to remove preprocessor attributes from inline scripts, and tell
lint about the browser window environment.
Differential Revision: https://phabricator.services.mozilla.com/D33207
when update-verify migrated from using build-tools to in-tree, the path
to `diff-summary.log` was not updated.
Differential Revision: https://phabricator.services.mozilla.com/D32403
--HG--
extra : moz-landing-system : lando
Two use cases:
1) Show the errors
$ ./mach lint -l rustfmt js/rust/src/rust.rs
Also works on a directory:
$ ./mach lint -l rustfmt js/rust/src/
2) Update the code
$ ./mach lint -l rustfmt js/rust/src/rust.rs --fix
To install it:
$ rustup component add rustfmt
$ export PATH=$PATH:~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/
Differential Revision: https://phabricator.services.mozilla.com/D30813
--HG--
extra : moz-landing-system : lando
Add Jitspewing control for tracelogger data. This can be enabled from the profiler or from the JS shell. Usage is as follows:
From browser (ION_SPEW_FILENAME is recommended here so stdout doesn't get clobbered by each process):
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger ION_SPEW_FILENAME=tracelogger ./mach run
2. Enable JSTracer feature in profiler addon
3. Start profiling and ctrl+shift+2 to view profile, and the data will be automatically spewed during profile collection.
From shell:
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger dist/bin/js test.js
2. Data is automatically spewed to stdout when the shell exits, or use ION_SPEW_FILENAME.
There is an optional environment variable JS_TRACELOGGER_SPEW that can be used to emit specific events, for example JS_TRACELOGGER_SPEW="Interpreter,Baseline,GC" will emit only those specific events along with the script and self time of each script.
The structured spewer is also supported with SPEW=tracelogger, and this will emit the tracelogger data for every recorded event.
Differential Revision: https://phabricator.services.mozilla.com/D30033
--HG--
extra : moz-landing-system : lando
This is part 1 of the required changes. This just addresses the
storage mechanism and any place that uses experiments in their raw
form. This updates most callers to support studies with multiple
preferences.
We update about-studies to assume only one preference. This seems
counterproductive, but studies with multiple preferences will include
a description field that obviates the need for this.
Differential Revision: https://phabricator.services.mozilla.com/D29293
--HG--
extra : moz-landing-system : lando
Now starting with a maximum of `1u << 22`, i.e. 4,194,304 entries, or 36MB per
process. (Using powers of two, because that's what we round up to anyway.)
Also giving more information in MOZ_PROFILER_HELP:
- Reminding this is a number of entries *per process*.
- Bytes per entry, and resulting total buffer sizes per process.
Differential Revision: https://phabricator.services.mozilla.com/D31389
--HG--
extra : moz-landing-system : lando
Treeherder will display a summary of errors from the log, if they are match
certain patterns. Make update-verify more useful by outputing errors that
match.
Differential Revision: https://phabricator.services.mozilla.com/D31165
--HG--
extra : moz-landing-system : lando
- sm-shell: Selects shell only test cases that shouldn't require a full browser build.
- sm-all: Selects test cases that may require a full browser build.
Differential Revision: https://phabricator.services.mozilla.com/D28994
--HG--
extra : moz-landing-system : lando
Also for checker `modernize-avoid-bind` export the respective reliability index from config.yaml
Differential Revision: https://phabricator.services.mozilla.com/D30904
--HG--
extra : moz-landing-system : lando
If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
There were many inconsistent ways to retrieve process/thread ids in the
profiler. Now we have only one platform-dependent implementation each:
profiler_current_process_id() and profiler_current_thread_id().
Note that this removes the need for the small `class Thread` in platform.h.
However memory_hooks.cpp still needs to be built non-unified, because of the
required order of #includes (replace_malloc.h before replace_malloc_bridge.h),
which could be disturbed by other cpp's.
Differential Revision: https://phabricator.services.mozilla.com/D29977
--HG--
extra : moz-landing-system : lando
Bug 1484243 removed the --git argument and made the VCS auto-detected,
so we should no longer suggest passing in that argument in error
messages.
Differential Revision: https://phabricator.services.mozilla.com/D30257
--HG--
extra : moz-landing-system : lando
Under the hood, browsertime invokes a certain `visualmetrics.py`
script. That script depends on `ffmpeg` and ImageMagick's `convert`,
`compare`, and `mogrify` commands. It also depends on certain Python
packages.
So this installs those dependencies, and then wires up the evaluation
environment such that `./mach browsertime` can find the dependencies.
It also adds a `./mach visualmetrics` command for processing a
captured MP4 file in the same way that browsertime processes such a
file.
In order to avoid downloading dependencies multiple time, the existing
artifact cache is extracted. This is a small first step towards [Bug
1526021](https://bugzilla.mozilla.org/show_bug.cgi?id=1526021), which
might want to use this artifact cache as well.
At this time, hashes and filesizes are not verified. During
development, the upstream files changed multiple times, and it's not
worth being completely locked down while experimenting with this
functionality. If we start running this code in automation or in more
sensitive environments, we can build fetch tasks and TC indexes to
streamline the artifact gathering process.
It is expected that a future mach command will want to invoke
browsertime without suffering the overhead of invoking Python (and
mach, which is itself bulky) so a nod is given to exposing the
relevant environment pieces.
During testing, it was discovered that [MozillaBuild doesn't ship
git](https://bugzilla.mozilla.org/show_bug.cgi?id=1503028), so that
git repositories can't be used out-of-the-box on Windows. So instead
we use a [tarball link from github.com/$USER/$REPO/tarball/$COMMIT-LIKE](https://github.blog/2008-03-03-tarball-downloads/).
Differential Revision: https://phabricator.services.mozilla.com/D29442
--HG--
rename : python/mozbuild/mozbuild/test/test_artifacts.py => python/mozbuild/mozbuild/test/test_artifact_cache.py
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
Under the hood, browsertime invokes a certain `visualmetrics.py`
script. That script depends on `ffmpeg` and ImageMagick's `convert`,
`compare`, and `mogrify` commands. It also depends on certain Python
packages.
So this installs those dependencies, and then wires up the evaluation
environment such that `./mach browsertime` can find the dependencies.
It also adds a `./mach visualmetrics` command for processing a
captured MP4 file in the same way that browsertime processes such a
file.
In order to avoid downloading dependencies multiple time, the existing
artifact cache is extracted. This is a small first step towards [Bug
1526021](https://bugzilla.mozilla.org/show_bug.cgi?id=1526021), which
might want to use this artifact cache as well.
At this time, hashes and filesizes are not verified. During
development, the upstream files changed multiple times, and it's not
worth being completely locked down while experimenting with this
functionality. If we start running this code in automation or in more
sensitive environments, we can build fetch tasks and TC indexes to
streamline the artifact gathering process.
It is expected that a future mach command will want to invoke
browsertime without suffering the overhead of invoking Python (and
mach, which is itself bulky) so a nod is given to exposing the
relevant environment pieces.
During testing, it was discovered that [MozillaBuild doesn't ship
git](https://bugzilla.mozilla.org/show_bug.cgi?id=1503028), so that
git repositories can't be used out-of-the-box on Windows. So instead
we use a [tarball link from github.com/$USER/$REPO/tarball/$COMMIT-LIKE](https://github.blog/2008-03-03-tarball-downloads/).
Differential Revision: https://phabricator.services.mozilla.com/D29442
--HG--
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
Promise::Compartment is unused.
The callers that want to call AutoJSAPI::Init can pass it an nsIGlobalObject,
which is actually _more_ efficient, since passing a JSObject just gets an
nsIGlobalObject from it and passes that.
Differential Revision: https://phabricator.services.mozilla.com/D29703
--HG--
extra : moz-landing-system : lando
Since we need to generate the full_task_set as a prereq to the target_task_set,
and since getting from full_task_set -> target_task_set is trivial.. we might
as well save both computed sets to the cache while we have them. This means users
that run:
$ ./mach try fuzzy
and then run:
$ ./mach try fuzzy --full
(or vice versa)
Will only incur task generation once. It also means that the 'watchman' trigger
will cache both taskgraphs.
Differential Revision: https://phabricator.services.mozilla.com/D29557
--HG--
extra : moz-landing-system : lando
This adds a 'watchman.json' file to /tools/tryselect and some documentation on
how to use it. Tl;dr, install watchman and then:
$ cd path/to/gecko
$ watchman -j < tools/tryselect/watchman.json
Differential Revision: https://phabricator.services.mozilla.com/D28771
--HG--
extra : moz-landing-system : lando
When testing updates from ESR52, the SHA-1 release certs in the updater need to
be replaced with the dep certs update-verify to succeed.
Differential Revision: https://phabricator.services.mozilla.com/D31173
--HG--
extra : source : f7c2d2cfddd0860c94bfb0f0d5a0f98bfd123586
extra : amend_source : e10b0036e298890084875e00cc2ca0095bddd9b8
extra : intermediate-source : c06d38cbaaa94ed5723cdbb6d210e1d20902c839
Memory tracks are fed from a memory counter, which is unconditionally installed
from profiler_start(). This means:
- It is installed even if memory measurements are not requested.
- Startup profiling doesn't use profiler_start() and therefore never starts
recording memory.
Because installing the memory counter may need to take the (non-recursive)
profiler lock, it cannot simply be installed from the common
`locked_profiler_start()` function.
Instead, it will have to be installed after each `locked_profiler_start()` call.
Also, it should only be installed if the "memory" feature is requested.
That "memory" feature is now considered available only if Firefox was built with
MOZ_REPLACE_MALLOC and MOZ_PROFILER_MEMORY. (This may effectively prevent the
old RSS&USS memory reporting which doesn't depend on these #defines, but This Is
Fine as it is not used anymore and slated for removal in bug 1521929.)
Differential Revision: https://phabricator.services.mozilla.com/D25533
--HG--
extra : moz-landing-system : lando
Startup-profiling usually needs to capture more data, especially on slower
systems, so the default is changed to 10 million entries when
MOZ_PROFILER_STARTUP is set.
Also:
- Changed #define into `static constexpr` with the same type as expected by
`profiler_start()`.
- Better validity check of MOZ_PROFILER_STARTUP_ENTRIES.
- Defaults are shown in MOZ_PROFILER_HELP.
Differential Revision: https://phabricator.services.mozilla.com/D25689
--HG--
extra : moz-landing-system : lando
MOZ_PROFILER_FEATURES is mostly used to add features in addition to the
defaults. This will now be easier, e.g.:
`MOZ_PROFILER_STARTUP_FEATURES=default,screenshots`
Differential Revision: https://phabricator.services.mozilla.com/D25532
--HG--
extra : moz-landing-system : lando
It is too easy to mistype a feature name, and be confused or misled by the
results. This patch will catch such errors.
The previous code was going through each possible feature, seeing if it was in
MOZ_PROFILER_STARTUP_FEATURES -- Meaning unknown names would just be ignored.
The new code is doing the reverse: Going through all names in
MOZ_PROFILER_STARTUP_FEATURES, trying to match each one with possible features;
if not found, we indicate the first name that is unknown, show the help and
exit.
Differential Revision: https://phabricator.services.mozilla.com/D25531
--HG--
extra : moz-landing-system : lando
Show the list of MOZ_PROFILER_STARTUP_FEATURES with their value, name,
description, and whether they are default and/or available on this platform.
Feature descriptions are now provided in PROFILER_FOR_EACH_FEATURE.
Available features and defaults are now defined in one place, for easier
maintenance.
Differential Revision: https://phabricator.services.mozilla.com/D25530
--HG--
extra : moz-landing-system : lando
Moving to non-XPCOM data structures, to help with upcoming transfer to mozglue.
Differential Revision: https://phabricator.services.mozilla.com/D24698
--HG--
extra : moz-landing-system : lando
Moving to non-XPCOM data structures, to help with upcoming transfer to mozglue.
Differential Revision: https://phabricator.services.mozilla.com/D24697
--HG--
extra : moz-landing-system : lando
Some macros would not work if they were used in a context where `namespace
mozilla` is not directly accessible. Fixed by added appropriate `mozilla::`
specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D28028
--HG--
extra : moz-landing-system : lando
As the third-party node modules are throwing errors while running ./mach lint, the path was added to the ignore list for third party folders / files.
Differential Revision: https://phabricator.services.mozilla.com/D28620
--HG--
extra : moz-landing-system : lando
It turns out there are several places where the change to suite 'jittest-chunked'
causes problem. I am abandoning that approach.
Desktop uses this trick, and this returns android '-chunked' handling to a state
similar to what it was before I started messing around!
Differential Revision: https://phabricator.services.mozilla.com/D28897
--HG--
extra : moz-landing-system : lando
This skips a number of talos jobs that are unlikely to be affected
by due a browser-chrome specific change
Run with: `./mach try fuzzy --preset perf-chrome`
Differential Revision: https://phabricator.services.mozilla.com/D27911
--HG--
extra : moz-landing-system : lando
This officially makes 'moztest.resolve' the source of truth when it comes to
suite names. It aligns that file with the names used in both the
desktop_unittest and android_emulator_unittest scripts.
Differential Revision: https://phabricator.services.mozilla.com/D27555
--HG--
extra : moz-landing-system : lando
Currently we have the concept of a "suite" and a "flavour" in our task
configuration. Typically, the "suite" refers to the high-level test harness
like "mochitest" or "reftest", whereas the flavour is more specific, e.g
"browser-chrome-instrumentation" or "crashtest". However the line between suite
and flavour is not applied with any semblance of consistency which results in
inconsistent naming throughout the tree.
This patch gets rid of the concept of "flavours" entirely (at least when it
comes to task configuration). A suite is a type of test run, for example:
- mochitest-plain
- mochitest-devtools-chrome
- mochitest-browser-chrome-instrumentation
- jsreftest
- reftest
- firefox-ui-functional-remote
etc
There is no confusion here between suites and flavours because flavours don't
exist. However, there are a couple of places where we *do* need to know what
"test harness" is used to run a suite. These cases are:
1. For SCHEDULES moz.build rules
2. For the desktop_unittest.py mozharness script which takes arguments like
--mochitest-suite=browser (this is not a compelling use of this information
and should be refactored to work more like the android_emulator_unittest.py
script)
So to get this information, this patch introduces a new concept of a "category"
which is the overall "test harness" that runs the suite. For many suites, the
"category" is identical to the suite name. Unlike flavours, "categories" have
no bearing on how we call or refer to the suite.
Differential Revision: https://phabricator.services.mozilla.com/D27554
--HG--
extra : moz-landing-system : lando
This was regressed by bug 1544816 but the test never ran on the push that regressed.
This patch also updates the 'files-changed' for the tryselect task.
Differential Revision: https://phabricator.services.mozilla.com/D28386
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
Changes:
- added windows10-aarch64 to the filter for fuzzy, to require `--full` in order to trigger jobs
- return False for any test tasks that contain windows10-aarch64 to prevent users using old try syntax from overwhelming the limited number of hardware
Differential Revision: https://phabricator.services.mozilla.com/D27590
--HG--
extra : moz-landing-system : lando
Since e10s is the default configuration, we shouldn't explicitly mark things
with the "-e10s" suffix. Instead we should mark things that *don't* run with
'e10s. This patch removes '-e10s' from all treeherder group symbols and task
labels, adds the "-1proc" suffix to tasks that are non-e10s.
Differential Revision: https://phabricator.services.mozilla.com/D25958
--HG--
extra : moz-landing-system : lando
This helps run the tests locally if fzf is normally installed in
$HOME/.mozbuild. Since the tests set MOZBUILD_STATE_PATH to a temporary
directory, fzf_bootstrap() can't find fzf in the HOME location unless it
is added to PATH.
Differential Revision: https://phabricator.services.mozilla.com/D27194
--HG--
extra : moz-landing-system : lando
Add Android 7.0 gtests, opt and debug, running against the geckoview
TestRunnerActivity.
Differential Revision: https://phabricator.services.mozilla.com/D27016
--HG--
extra : moz-landing-system : lando
This patch enables compilation of the tracelogger by default on nightly builds
as well as providing an environment variable (JS_TRACE_LOGGING) to enable or
disable tracelogger instrumentation when compiling Javascript. This helps to
reduce the performance impact of the Tracelogger code when not in use. In the
future, this could be improved to recompile the JS with/without Tracelogger
instrumentation when toggling Tracelogger support.
Differential Revision: https://phabricator.services.mozilla.com/D26255
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
We always pass in the platform formated as an update platform. Since the only
variation in formats is between major platforms, be liberal in parsing
platforms, when selecting which unpack logic to use. This makes win64-aarch64
support fall out automatically.
Differential Revision: https://phabricator.services.mozilla.com/D26201
--HG--
extra : moz-landing-system : lando
We always pass in the platform formated as an update platform. Since the only
variation in formats is between major platforms, be liberal in parsing
platforms, when selecting which unpack logic to use. This makes win64-aarch64
support fall out automatically.
Differential Revision: https://phabricator.services.mozilla.com/D26201
--HG--
extra : moz-landing-system : lando
These modules are MIT licensed and they're to be used in xpcshell-tests for TRR.
They allow us to make moz-http2.js act like a true DoH server - more specifically to answer DNS queries that have actually been asked, not just a dumb character buffer.
Differential Revision: https://phabricator.services.mozilla.com/D25672
--HG--
extra : moz-landing-system : lando
These modules are MIT licensed and they're to be used in xpcshell-tests for TRR.
They allow us to make moz-http2.js act like a true DoH server - more specifically to answer DNS queries that have actually been asked, not just a dumb character buffer.
Differential Revision: https://phabricator.services.mozilla.com/D25672
--HG--
extra : moz-landing-system : lando
There are a few windows/mac-only suites that were missed since we were only
reading the linux variant.
Depends on D25401
Differential Revision: https://phabricator.services.mozilla.com/D25432
--HG--
extra : moz-landing-system : lando
While running presets + intersection queries works with 'mach try fuzzy
--preset <foo>', it is still broken with 'mach try --preset <foo>'.
Differential Revision: https://phabricator.services.mozilla.com/D25298
--HG--
extra : moz-landing-system : lando
Some of these were working with the '<flavor>-<subsuite>' mechanism that was
previously being used, but better to be explicit wherever possible.
Depends on D25077
Differential Revision: https://phabricator.services.mozilla.com/D25078
--HG--
extra : moz-landing-system : lando
Mozharness appends -chunked/-coverage to some suites, but the build system/test
resolver don't have any concept of these things. We need to normalize these out
for the purposes of MOZHARNESS_TEST_PATHS.
Differential Revision: https://phabricator.services.mozilla.com/D25015
--HG--
extra : moz-landing-system : lando
It turns out bug 1489100 regressed the ability to specify test paths for most
suites by naively assuming that mozharness uses suite names that look like:
<flavor>-<subsuite>
In reality, there is no consistency to how suite names are generated. This test
does a few things:
1) Patches the moztest.TestResolver to return a list of all possible
suites/subsuites (assuming the lists in moztest.resolve are up to date).
2) Finds all the suites defined in the mozharness configs (e.g
linux_unittest.py), and uses these are parametrized inputs.
3) Checks that for each test suite,
DesktopUnittest._get_mozharness_test_paths() returns something.
I've marked all of the test suites that currently fail as expected. This way I
have a good sense of what needs to be fixed, and can validate my changes as I
move through the list.
Differential Revision: https://phabricator.services.mozilla.com/D25014
--HG--
extra : moz-landing-system : lando
Disable the following tests for windows10-aarch64:
- test_enterjit_osr.js
- test_feature_mainthreadio.js
They were likely intermittents at first, but as of recent try push noted below these tests are failing consistently.
Differential Revision: https://phabricator.services.mozilla.com/D24413
--HG--
extra : moz-landing-system : lando
The graph contains some extra things like toolchains, fetches and packaging
tasks that people will almost never want to run on their own. This change gets
them out of the default fuzzy selection interface, and makes it so --full is
needed to schedule them.
Differential Revision: https://phabricator.services.mozilla.com/D24187
--HG--
extra : moz-landing-system : lando
This makes RAPL abort with more informative error messages if certain
kernel-provided files aren't present.
Differential Revision: https://phabricator.services.mozilla.com/D23974
--HG--
extra : moz-landing-system : lando
Not only is it best practice to pin dependencies and check hashes, but this
will allow tests to install these dependencies as well.
Depends on D22784
Differential Revision: https://phabricator.services.mozilla.com/D22785
--HG--
extra : moz-landing-system : lando
