Switches the integration tests form Puppeteer/webdriver-manager to the
Bazel-managed Chromium/Chromedriver. This is now possible with the new
integration test rule for which we can consult the
`dev-infra/bazel/browsers` toolchain and setup environment variables.
This has been configured already in a previous commit.
This commit also includes some additional small cleanups necessary for
the new integration test rule:
* The `test.sh` scripts have been renamed as they would conflict with
the `test.sh` scripts generated by the integration test rule.
Previously this was not an issue because tests were declared at a
higher-level. As mentioned though this has other downsides and it is
trivial to rename the file.
* Related to the point above, since tests are now declared witin the
actual test folder (for perf e.g.), `package.json` files setting
`"type": "module"` will accidentally cause the `nodejs_test`-generated
files to be considered ESM. This is not correct and likely needs to be
fixed upstream in `rules_nodejs` where explicit `.cjs` extensions
should be used. This is only happening **once** in the `injectable-def`
test so it is acceptable doing that for now.
PR Close#44238
Previously only one translation file per locale could be loaded.
Now the user can specify multiple files per locale, and the translations
from each of these files will be merged together by message id.
The merging is on a first-wins approach. So if to you have three files
to be merged:
```
['a.xlf', 'b.xmb', 'c.json']
```
Then any message from `a.xlf` will be used rather than a message from `b.xmb`
or `c.json` and so on. In practice this means that you should put the files
in order of most important first, with "fallback" translations later.
PR Close#36792
This means integration tests no longer need to depend on a $CI_CHROMEDRIVER_VERSION_ARG environment variable to specify which chromedriver version to download to match the locally installed chrome. This was bad DX and not having it specified was not reliable as webdriver-manager would not always download the chromedriver version to work with the locally installed chrome.
webdriver-manager update --gecko=false --standalone=false $CI_CHROMEDRIVER_VERSION_ARG is now replaced with node webdriver-manager-update.js in the root package.json, which checks which version of chrome puppeteer has come bundled with & downloads informs webdriver-manager to download the corresponding chrome driver version.
Integration tests now use "webdriver-manager": "file:../../node_modules/webdriver-manager" so they don't have to waste time calling webdriver-manager update in postinstall
"// resolutions": "Ensure a single version of webdriver-manager which comes from root node_modules that has already run webdriver-manager update",
"resolutions": {
"**/webdriver-manager": "file:../../node_modules/webdriver-manager"
}
This should speed up each integration postinstall by a few seconds.
Further, integration test package.json files link puppeteer via file:../../node_modules/puppeteer which is the ideal situation as the puppeteer post-install won't download chrome if it is already downloaded. In CI, since node_modules is cached it should not need to download Chrome either unless the node_modules cache is busted.
NB: each version of puppeteer comes bundles with a specific version of chrome. Root package.json & yarn.lock currently pull down puppeteer 2.1.0 which comes with chrome 80. See https://github.com/puppeteer/puppeteer#q-which-chromium-version-does-puppeteer-use for more info.
Only two references to CI_CHROMEDRIVER_VERSION_ARG left in integration tests at integration/bazel-schematics/test.sh which I'm not entirely sure how to get rid of it
Use a lightweight puppeteer=>chrome version mapping instead of launching chrome and calling browser.version()
Launching puppeteer headless chrome and calling browser.version() was a heavy-handed approach to determine the Chrome version. A small and easy to update mappings file is a better solution and it means that the `yarn install` step does not require chrome shared libs available on the system for its postinstall step
PR Close#35049
Paul Gschwendtner