depot_tools ships a "vpython" binary that is added to the $PATH
for all Chromium engineers. This binary is versioned by depot_tools
which we roll in ourselves as part of `gclient sync`.
By using `vpython` instead of `python`, we are no longer depended
on the Python version installed locally and instead use the version
we pull in from DEPS.
R=liviurau@chromium.org
Change-Id: If49a54c24b6cf129ff843cd9ca1140a723a78afb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2571462
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This CL introduces the infrastructure and first test for what we're calling
"Interaction tests". These are tests that can be used to test component
behaviour that cannot be tested via Karma unit tests but don't require an e2e
test either.
The best example here is complex user interactions: clicking and dragging a
mouse, or doing multiple tabs to navigate through the UI.
Note that the one interaction test added here for theme_colors isn't the best
example of a complex test, but it's a test that's good enough for now whilst we
get everything set up on infrastructure and make sure it runs without flaking.
Bug: 1153281
Change-Id: Ifb37639a557c459974f703b8954ae68a93d5d368
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2566808
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
As part of the work to enable Puppeteer component tests, we need to
configure the test suite to run either the hosted mode server or the
component docs server. This CL updates it to take a flag, and makes some
updates to the component docs server, which now has to run either
directly or in the out/Default/gen directory depending on how it is run.
I suspect I'll make a follow up CL to always run the component server in
out/Default/gen, but for now enabling it to detect its context is the
quickest way to unblock running it in tests. The next CL will add a
component test suite that can run a basic test against the component doc
server, but I have manually verified locally that I can run tests
against that server.
Bug: 1153281
Change-Id: I55bda4edd0a983d03bfecff0446b0f3e3a008b52
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562707
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Only set the unhandled rejection handler once per process.
We run the setup and teardown multiple times per-process now.
Add clearPuppeteerState() to unset the state between runs on
a parallel test runner. This is because the port changes
between successive runs in the same process.
Remove the hasShutdown logic from mocha_hooks. Also remove the
beforeExit hook which was causing this to get called at least
twice for every process. It already gets called in the ordinary
shutdown case via the afterAll() hook. We only need to call it
in the extraordinary case which is the SIGINT case. Now that we
do the shutdown multiple times per process, we don't care if we
already shutdown on this process or not. The only issue could be
if ctrl+c is sent during the shutdown, but then we are crashing
anyway.
Right now the default # of jobs is 1, so out bots will still run
in serial mode. We want to add parallel mode as an options for
local development while we iron out any last problems with this
approach.
You can test this locally with npm run e2etests -- --jobs=8.
We make use of global setup fixtures to only run one hosted
mode server and share it between all parallel runners. Each
runner still starts its own chrome and restarts it between
files, which is a bit inefficient but still a big improvement
compared to serial mode.
Split the hosted mode server out into its own file inside
conductor as it can be dealt with entirely separately, and
its state is not per-process like the chrome state, but only
per-main-process which launches the test runner sub-processes.
Bug: 1101784
Change-Id: Ic0c9be3559708fd5403a88882b9fb93257633de9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2288694
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
There previously were two special files that were handled
by `build_release_applications`: root.js and RuntimeInstantiator.js.
Both files are explicitly part of the startup process of DevTools
and its various entrypoints.
To remove the copying from `build_release_applications`, we have
to move these to the relevant `devtools_entrypoint`. Since a
`devtools_entrypoints` bundles all subdirectories, we can't keep
these files in `front_end/` directly. Instead, we move these files
to `startup/` to denote their special-casing in the startup process.
Next to that, we have to fix all usages of these files in the entrypoints.
For all JavaScript entrypoint files, all side-effect legacy files
that are loaded by `startup.js` (previously known as `root.js` and renamed
to prevent confusion with the `root/` module) are removed. All
"additional" legacy files that a particular entrypoint requires are
still loaded as-is.
The RuntimeInstantiator is moved to become an implementation detail
of `startup/`. Therefore, all of the usages that were previously
importing from `RuntimeInstantiator` now import via `startup.js`.
In the end, the special-casing of these files are removed and renamed
for clarity. In the future, we want to remove the complicated
entrypoints startup process, but we are not ready for that yet.
That will require additional cleanups with `resources` in `module.json`
before that change can happen.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: I198d5a62d2aab70f842c68d9b4c0871fde1587a4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2485072
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit 8f012723b7.
The cause of the i18n not working on debug configuration was that
some files were missing from the grd lists.
- Added i18nImpl, i18n-bundle.js with a similar process to the rest
of the modules.
To make it easy to review:
the first patchset contains the reland with no modifications the >2 patchset
contains the fixes, so if you diff Patchset 1 vs > 1 you should see the fixes
described above.
Change-Id: Iee3767b6afeb1a039be952f787886f94c0752f56
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2376945
Commit-Queue: Vidal Diazleal <vidorteg@microsoft.com>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Port formatter_worker to use devtools_entrypoint, which is the abstraction
around `rollup`. It handles the creation of the rollup bundle, but leaves
it alone if you are building with `is_debug=true`. This way, we can keep
development use the existing workflow where individual files are fetched,
while in release mode we bundle the entrypoint into 1 big file.
In the future, anything we consider an entrypoint must use this method.
This would include third_party packages like lit-html and CodeMirror.
A follow-up CL will move the lit-html entrypoint back into
third_party/lit-html, as we no longer require it to be a direct subfolder
of `front_end/` (that was fixed in
https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2270168)
DISABLE_THIRD_PARTY_CHECK=TypeScript fixes
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1098730
Change-Id: I5d2e67cc9c71291e8b67bbc29354e75239aae9a9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2267001
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
The e2e-tests now use the build output in resources/inspector in
the out directory. This allows us to introduce TypeScript-authored
files in the source directory `front_end`, which will get compiled
into resourc/inspector.
After to making a change to a e2e-test or the front_end, you need
to rebuild Devtools, after which you can run `npm run e2etest` as
normal.
Since we now use the build output, this also means that you can
run the e2e-tests on the release build. In other words, if you
build DevTools with build optimizations (such as Rollup), the
e2e-tests will now use the output (and thus provide test coverage).
DISABLE_THIRD_PARTY_CHECK=Node fixes
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Fixed: 1088463
Change-Id: I02ec3c2476bc3647158fede9e1d347963b3a720a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2224809
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jose Leal <joselea@microsoft.com>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Use `npm run build` to generate the mjs files.
Create a acorn-numeric-separator_types.mjs for closure to typecheck.
Create acorn-numeric-separator.mjs.d.ts for TS compiler.
Update acorn_types.mjs to allow Parser to take varargs.
Bug: chromium:1086817
Change-Id: I9f040ddaf5748f3d7437a075c3322335d8e076ec
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2261447
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
stylelint requires POSIX-formatted paths/globs, even on Windows. This
patch ensures we pass such paths in the case where only specific files
are being linted (i.e. `PRESUBMIT.py` calls `run_lint_check_css.py`
with a list of potentially Windows-formatted file paths as arguments.
Bug: chromium:1083142
Change-Id: I1eea6bf146decd52bb978388d4e3e98f48ec91b3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2252007
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
On Windows, if your checkout is at:
C:\devtools\devtools-frontend
Then the stylelint CLI lives here:
C:\devtools\devtools-frontend\node_modules\stylelint\bin\stylelint.js
Prior to this patch, the lint CSS script was instead trying to use:
C:\node_modules\stylelint\bin\stylelint.js
That is, it went two levels too far up the directory tree. This only
happened on Windows.
This patch avoids the problem altogether by forcing the root directory
to be the current working directory and passing a root-relative glob
instead.
As a drive-by, this patch cleans up the `_getFilesToLint` helper in
`PRESUBMIT.py`.
Bug: chromium:1083142
Change-Id: Ida7d19e4c1cb8954346a3103ce95748f0bc38f00
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2252005
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
This CL adds an optional --chrome-binary argument to the unittest.py
script to use a specific Chrome binary to run unit tests against.
When no argument is specified, the script defaults to the downloaded
Chrome binary from `gclient sync` (same behavior as before).
We'd like to have the option of running unit tests on a Microsoft Edge
executable instead of the default downloaded Chrome executable.
Change-Id: Ice72f129086bcc1da56efa118280532cdbb25fd3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2202628
Reviewed-by: Brandon Goddard <brgoddar@microsoft.com>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Robert Paveza <Rob.Paveza@microsoft.com>
Commit-Queue: Brian Cui <brcui@microsoft.com>
This resurrects the perf test suite, as the older test-runner setup
was removed, but the perf test suite was not ported.
Example output:
Spawning hosted mode server
Boot performance
✓ run 1/37 (1185ms)
✓ run 2/37 (1234ms)
✓ run 3/37 (1213ms)
✓ run 4/37 (1376ms)
✓ run 5/37 (1327ms)
✓ run 6/37 (1235ms)
✓ run 7/37 (1352ms)
✓ run 8/37 (1439ms)
✓ run 9/37 (1332ms)
✓ run 10/37 (1290ms)
✓ run 11/37 (1229ms)
✓ run 12/37 (1241ms)
✓ run 13/37 (1233ms)
✓ run 14/37 (1203ms)
✓ run 15/37 (1177ms)
✓ run 16/37 (1336ms)
✓ run 17/37 (1526ms)
✓ run 18/37 (1465ms)
✓ run 19/37 (1537ms)
✓ run 20/37 (1709ms)
✓ run 21/37 (1760ms)
✓ run 22/37 (1704ms)
✓ run 23/37 (2549ms)
✓ run 24/37 (1387ms)
✓ run 25/37 (1934ms)
✓ run 26/37 (1860ms)
✓ run 27/37 (1309ms)
✓ run 28/37 (1295ms)
✓ run 29/37 (1391ms)
✓ run 30/37 (1569ms)
✓ run 31/37 (1562ms)
✓ run 32/37 (1442ms)
✓ run 33/37 (1431ms)
✓ run 34/37 (1646ms)
✓ run 35/37 (1927ms)
✓ run 36/37 (1600ms)
✓ run 37/37 (1587ms)
Mean boot time: 1475.28ms
50th percentile boot time: 1390.83ms
90th percentile boot time: 1860.02ms
99th percentile boot time: 2549.29ms
R=aerotwist@chromium.org
Change-Id: I1b6a79fdfc1b7c98f6156d3309b5b98ff8530476
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2209108
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This significantly speeds up Karma execution times to about 12 seconds on an unchanged build folder.
It uses the Ninja build output to find the unittest files.
You can run the new script with:
npm run unittest
npm run unittest -- --target=Release
To make sure you perform a minimal build and run tests right after it, run:
npm run auto-unittest
npm run auto-unittest -- --target=Release
If no ninja-build-name is set, it assumes that `out/Default` exists.
The `auto-unittest` command will run autoninja for you on the output folder.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
No-Presubmit: true
Bug: 1061125
Change-Id: I45edd11e422c5cdc8a4fc0bbb6bc43e386519aa9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2102717
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Brandon Goddard <brgoddar@microsoft.com>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This has two benefits:
1. We can now "pre-process" the arguments. It therefore allows us
to specifically set the tests we want to run. Before this change,
we would incorrectly include JavaScript files that were outputs
from (since-removed) TypeScript tests. Since adding these as
arguments to the Mocha invocation causes issues on Windows bots
with "arguments too long" errors, we should be using the config
file.
2. We can add additional arguments here without the need
of passing all the arguments from `run_test_suite.py` in.
R=petermarshall@chromium.orgTBR=aerotwist@chromium.org
Bug: 1071369
Change-Id: Icab02b1117f4095081987b65c8151ddf04239e11
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2157044
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
The shared test runner logic was reimplementing parts of Mocha,
in particular the test logging and filtering. Moreover, it was
booting the hosted mode server and puppeteer outside of Mocha.
Mocha supports root level hooks [1]. These hooks allow us to
perform work before a test starts. Moreover, by using the
before and after hook, we can run logic before and after
all tests.
By using these hooks, we can extract the "boot the hosted mode
server and hookup puppeteer" part to these root hooks.
Additionally, we can reset the pages in the `beforeEach`, which
means that tests themselves don't have to reset the pages.
We also put the implementation code into third_party/conductor,
as we would like to reuse this logic for the Puppeteer tests.
The Puppeteer test suite now also uses Mocha and has very
similar requirements as to our DevTools tests. By extracting
from DevTools, we can look into expanding the test runner to
other usecases, but that is out of scope for now.
[1]: https://mochajs.org/#root-level-hooks
Bug: 1071369
Change-Id: Ie9f954359d9de84da564b74b6f5517dd535db008
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2150458
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
I ran into this while trying to reproduce Closure failures locally for
a different CL. Python's built-in remove method on lists returns None
instead of the modified list, which was causing the resulting value in
exec_command to be incorrect when a Java install without a server JVM
was used.
Change-Id: Ib2629b513c2f6401c51654e68792509796366e61
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2150731
Reviewed-by: Leo Lee <leolee@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Tony Ross <tross@microsoft.com>
We ignore some files for ESLint, as they are either generated or
third_party. However, when someone tries to change these files,
ESLint would emit a warning stating that the file in question is
ignored.
This issue was reported to ESLint in https://github.com/eslint/eslint/issues/9977
The suggested workaround is to use the CLIEngine to filter out
the problematic paths. However, since our script was written in
Python, that API is not accessible to us.
Therefore rewrite the script to Node and filter out the problematic
files. The calls to CLIEngine were mostly taken from eslint/lib/cli.js,
which was the previous file used by `node_modules/bin/eslint`.
R=jacktfranklin@chromium.orgCC=sigurds@chromium.org
Change-Id: Iee600f0e0d99fcb6eeeb203a952a50fe35f9aaf3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2149316
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Tim van der Lippe