ChromeDriver now supports Apple Silicon ARM processors.
`webdriver-manager` versions 12.1.7 and earlier will, however,
incorrectly download the arm64 ChromeDriver regardless of the
system's architecture. This results in failure to run Protractor tests
on macOS with the error: `spawn Unknown system error -86`
This commit fixes the problem by upgrading `webdriver-manager` to
version 12.1.8, which includes a fix.
See also https://stackoverflow.com/questions/65618558.
PR Close#40756
Previously, the paths to some local dependencies in the `ivy-i18n`
integration project were pointing to non-generic bazel files that would
normally not exist on a user's machine.
This commit changes these paths to relative paths pointing to build
artifacts that are guaranteed to exist (once the necessary build
commands have been executed).
PR Close#40756
Upgrade the karma dependency to version 4.4.0 in the root package.json
and in integration tests. Compared to version 4.3.0, which most of the
packages were previously depending on, it has the following changes:
Bug Fixes
- runner: remove explicit error on all tests failed
Features
- client: Add trusted types support
- Preprocessor can return Promise
- config: add failOnSkippedTests option.
- config: clientDisplayNone sets client elements display none.
- deps: Remove core-js dependency.
The motivation for upgrading the package is the Trusted Types support
that it adds, which is necessary to enable Trusted Types in Angular's
unit tests.
PR Close#39180
The integration test for i18n now makes use of the new extraction tooling
from the `@angular/localize` package rather than the old ViewEngine extractor.
PR Close#32912
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 commit moves the build-related scripts
(`build-ivy-npm-packages.js`, `build-packages-dist.js` and
`package-builder.js`) to a dedicated directory to keep the `scripts/`
directory cleaner.
It also moves the logic for building the `zone.js` package to a separate
script, `zone-js-builder.js`, to make it re-usable. A subsequent commit
will use it to build the `zone.js` package when building the Ivy Angular
packages as well.
PR Close#35780
* it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as `BUILD_WORKSPACE_DIRECTORY` will be set in that context
* test //integration:bazel_test and //integration:bazel-schematics_test exclusively
* run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute
```
//integration:bazel-schematics_test PASSED in 317.2s
//integration:bazel_test PASSED in 167.8s
```
* Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are:
- cli-hello-world*
- hello_world__closure
* add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test
@babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive.
NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0
NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass
NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct.
PR Close#33927
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
This allows us to update the version of the package in a single place for all tests.
Notable exemption of this is aio which currently doesn't depend on anything installed in the root.
PR Close#34002
Since we cannot run `yarn install` with the `--frozen-lockfile` option
(because we want to be able to install the locally built Angular
packages), integration project lockfiles are susceptible to getting
out-of-sync with the corresponding `package.json`. When this happens,
yarn will install the latest available version that satisfies the
version range specified in `package.json`.
This commit adds another line of defense, by specifying exact versions
for the dependencies in `package.json` files (i.e. `1.33.7` instead of
`^1.33.0`). While transitive dependencies will be unpinned, this still
ensures that the same version of direct dependencies will be installed
in case of an out-of-sync lockfile, thus reducing the probability of
random failures.
PR Close#33968
In the `integration_test` CircleCI job, we run `yarn install` on all
projects in the `integration/` directory. If a project has no lockfile
or if the lockfile is out-of-sync with the corresponding `package.json`
file, then the installed dependency versions are no longer pinned, which
can result in different versions being installed between different runs
of the same job (if, for example, a new version is released for a
package) and breaks hermeticity.
This could be prevented by using the `--frozen-lockfile` option with
`yarn install`, but this is not possible with the current setup, because
yarn needs to be able to install the locally built Angular packages,
whose checksums will be different from the ones in the lockfile.
Therefore, we have to manually ensure that the lockfiles remain in-sync
with the corresponding `package.json` files for the rest of the
dependencies.
For example, previously, [cli-hello-world-lazy/yarn.lock][1] had an
entry for `@angular-devkit/build-angular@0.900.0-next.9` (pinned to
`0.900.0-next.9`), but [cli-hello-world-lazy/package.json][2] specified
the `@angular-devkit/build-angular` version as `^0.900.0-rc.0` (note the
leading caret). As a result, since the version in the lock file does not
much the one in `package.json`, the lockfile is ignored and the latest
available version that matches `^0.900.0-rc.0` is installed.
This, for example, started causing unrelated CI failures ([example][3]),
when `@angular-devkit/build-angular@9.0.0-rc.3` was released with a size
improvement.
This commit ensures that all integration projects have a lockfile and
that lockfiles are up-to-date (with the current `package.json` files).
[1]: https://github.com/angular/angular/blob/fc2f6b845/integration/cli-hello-world-lazy/yarn.lock#L13
[2]: https://github.com/angular/angular/blob/fc2f6b845/integration/cli-hello-world-lazy/package.json#L26
[3]: https://circleci.com/gh/angular/angular/535959#tests/containers/2
PR Close#33968
The `:` char is used as a metadata marker in `$localize` messages.
If this char appears in the metadata it must be escaped, as `\:`.
Previously, although the `:` char was being escaped, the TS AST
being generated was not correct and so it was being output double
escaped, which meant that it appeared in the rendered message.
As of TS 3.6.2 the "raw" string can be specified when creating tagged
template AST nodes, so it is possible to correct this.
PR Close#33820
In #33823, `scripts/package-builds.sh` (which is used by both
`build-packages-dist.sh` and `build-ivy-npm-packages.sh`) was updated to
use `realpath`. It turns out that `realpath` does not exist on macOS, so
the build scripts do not work there.
In order to fix this (and also reduce the likelihood of introducing
similar issues in the future), this commit changes these bash scripts to
Node.js scripts (using [ShellJS](https://github.com/shelljs/shelljs) for
a cross-platform implementation of Unix shell commands where necessary).
PR Close#33854
In #33046, internal uses of `zone.js` were switched to reference it
directly from source (built with Bazel) instead of npm. As a result, the
necessary scripts were updated to build `zone.js` as necessary. However,
some `integration/**/debug-test.sh` scripts were missed (apparently
because they are not used on CI, but only locally as helpers for
debugging the integration projects).
This commit updates the `scripts/build-packages-dist.sh` script to also
build `zone.js`, so that other scripts (such as the various
`debug-test.sh` scripts) can use it.
PR Close#33733
Alan Agius
George Kalpakas
Marcono1234
Bjarki
Andrew Kushnir
Pete Bacon Darwin
JiaLiPassion
Greg Magolan
Igor Minar
Filipe Silva