Commit Graph

11 Commits

Author SHA1 Message Date
JiaLiPassion d37939623f test(zone.js): test zone.js package with tgz (#38649)
Zone.js 0.11.0 release an empty bundle, and now the npm_package tests all target
bazel rule `npm_package`, but not `npm_package.pack`, and these two rules may
generate different results, for example, Zone.js 0.11.0's issue is `package.json`
define files array which make the bundle only include the files in the files array.
So this PR install the zone.js package from the archive generated from `npm_package.pack` rule.

PR Close #38649
2020-10-19 08:06:11 -07:00
Greg Magolan dde68ff954 build: add npm_integration_test && angular_integration_test (#33927)
* 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
2020-02-24 08:59:18 -08:00
Greg Magolan acfd0edd38 test: use puppeteer in integration tests and to download correct chromedriver (#35049)
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
2020-02-11 13:16:52 -08:00
Igor Minar ea37e82e69 build: consolidate @angular-devkit/build-angular to the root package.json (#34002)
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
2019-12-02 10:49:12 -08:00
George Kalpakas 4ece0eb27c build: use exact versions for integration project dependencies (#33968)
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
2019-11-26 16:08:32 -08:00
Filipe Silva 891708cfc9 build: update to Angular CLI 9.0.0-rc.3 (#33955)
Followup to https://github.com/angular/angular/pull/33337

PR Close #33955
2019-11-21 09:17:18 -08:00
George Kalpakas 74b7d1ace1 test(ngcc): build `zone.js` from source in `scripts/build-packages-dist.sh` (#33733)
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
2019-11-12 09:55:16 -08:00
JiaLiPassion 8c6fb17d29 build: reference zone.js from source directly instead of npm. (#33046)
Close #32482

PR Close #33046
2019-11-06 00:48:34 +00:00
Filipe Silva 02308c4f71 test: update CLI to rc version (#33510)
PR Close #33510
2019-11-01 17:50:56 +00:00
Pete Bacon Darwin d883007cc6 build: update CLI and related dependencies (#33382)
This commit also ensures that the integration tests
are all using the top level dependencies.

Resolves https://github.com/angular/angular/pull/33314#discussion_r338381134

PR Close #33382
2019-10-24 14:12:30 -07:00
Filipe Silva 609d2557bc test: add integration test for lazy chunks and ngDevMode in cli apps (#32957)
PR Close #32957
2019-10-21 11:27:43 -04:00