Commit Graph

51 Commits

Author SHA1 Message Date
Greg Magolan a1d0396c55 build: fix integration tests flakes using local yarn cache for bazel-schematics & ng_elements_schematics demos (#35877)
ng_update_migrations will still access the global yarn cache on its `ng update` call and there is no way to avoid this that I can see but if no other integration tests access the global yarn cache then that one test can have free reign over it.

PR Close #35877
2020-03-05 15:30:20 -05:00
Greg Magolan 93fc392549 build: fix flakiness in integration/bazel-schematics by disabling symlinked_node_modules (#35808)
Because the WORKSPACE file is generated JIT by schematics in this integration test, we need to patch the schematics to add the work-around.

PR Close #35808
2020-03-03 09:19:31 -08:00
Greg Magolan 983e487a8f build: use puppeteer in integration/bazel-schematics (#33927)
PR Close #33927
2020-02-24 08:59:18 -08: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
George Kalpakas 19396769e2 ci: get rid of the `CI_CHROMEDRIVER_VERSION_ARG` env var (#35381)
Previously, we needed to manually specify a ChromeDriver version to
download on CI that would be compatible with the browser version
provided by the docker image used to run the tests. This was kept in the
`CI_CHROMEDRIVER_VERSION_ARG` environment variable.

With recent commits, we use the browser provided by `puppeteer` and can
determine the correct ChromeDriver version programmatically. Therefore,
we no longer need the `CI_CHROMEDRIVER_VERSION_ARG` environment
variable.

NOTE:
There is still one place (the `bazel-schematics` integration project)
where a hard-coded ChromeDriver version is necessary. Since I am not
sure what is the best way to refactor the tests to not rely on a
hard-coded version, I left it as a TODO for a follow-up PR.

PR Close #35381
2020-02-18 12:42:48 -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 7f0d7f4d12 build: update lockfiles for integration projects (#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
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
Filipe Silva 02308c4f71 test: update CLI to rc version (#33510)
PR Close #33510
2019-11-01 17:50:56 +00:00
Greg Magolan bf913cc39b feat(bazel): update bazel-schematics to use Ivy and new rollup_bundle (#33435)
Note: the @angular/bazel schematic now appends the package.json "script" field with 'ngcc --properties es2015 browser module main'. If there is an existing script field with ngcc then the schematic modifies it in place removing `--first-only` and `--create-ivy-entry-points`.

ViewEngine sources under node_modules need to be updated in-place for Bazel as it does not know how to use the `__ivy__` entry points that are created by the non-bazel `ngcc` command that is added to "scripts" :`ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points`.

PR Close #33435
2019-10-29 14:04:21 -07:00
Keen Yee Liau f0366843ea fix(bazel): Remove angular devkit and restore ngc postinstall (#32946)
This commit removes `@angular-devkit/build-angular` from package.json
for a project that opts into Bazel. This is because the package adds a
dependency on node-sass, which is rejected by Bazel due to its absense.

This commit also appends to `scripts.postinstall` if it already exists.
This is needed because `ng new` in CLI v9 now automatically adds a
postinstall step for `ngcc`.

PR Close #32946
2019-10-18 13:15:16 -04:00
Igor Minar 86e1e6c082 feat: typescript 3.6 support (#32946)
BREAKING CHANGE: typescript 3.4 and 3.5 are no longer supported, please update to typescript 3.6

Fixes #32380

PR Close #32946
2019-10-18 13:15:16 -04:00
Greg Magolan c1346462db build: update to nodejs rules 0.37.1 (#32151)
This release includes a ts_config runfiles fix so also cleaning up the one line work-around from #31943.

This also updates to upstream rules_webtesting browser repositories load("@io_bazel_rules_webtesting//web/versioned:browsers-0.3.2.bzl", "browser_repositories") to fix a breaking change in the chromedriver distro. This bumps up the version of chromium to the version here: https://github.com/bazelbuild/rules_webtesting/blob/master/web/versioned/browsers-0.3.2.bzl

PR Close #32151
2019-09-25 11:29:12 -07:00
Alex Rickabaugh ec4381dd40 feat: make the Ivy compiler the default for ngc (#32219)
This commit switches the default value of the enableIvy flag to true.
Applications that run ngc will now by default receive an Ivy build!

This does not affect the way Bazel builds in the Angular repo work, since
those are still switched based on the value of the --define=compile flag.
Additionally, projects using @angular/bazel still use View Engine builds
by default.

Since most of the Angular repo tests are still written against View Engine
(particularly because we still publish VE packages to NPM), this switch
also requires lots of `enableIvy: false` flags in tsconfigs throughout the
repo.

Congrats to the team for reaching this milestone!

PR Close #32219
2019-08-20 16:41:08 -07:00
Keen Yee Liau b0866769b0 fix(bazel): do not modify tsconfig.json (#30877)
Before this change, user's tsconfig.json is cloned and some options
controlled by Bazel are removed otherwise Bazel would complain about:

```
WARNING: your tsconfig.json file specifies options which are overridden by Bazel:
 - compilerOptions.target and compilerOptions.module are controlled by downstream dependencies, such as ts_devserver
 - compilerOptions.typeRoots is always set to the @types subdirectory of the node_modules attribute
 - compilerOptions.rootDir and compilerOptions.baseUrl are always the workspace root directory
```

Since the warning has been removed in rules_typescript/8d8d398, there's no
need to clone and backup tsconfig.json

PR Close #30877
2019-06-11 14:23:00 -07:00
Alex Eagle 532c1cb485 build: update to Bazel 0.26.1 (#30627)
PR Close #30627
2019-06-11 00:03:11 +00:00
Greg Magolan ba83d33dd0 build(bazel): update to nodejs rules 0.30.1 & bazel 0.26.0 (#30627)
nodejs rules 0.30.1 has new feature to symlink node_modules with yarn_install and bazel 0.26.0 includes new managed_directories feature which enables this

PR Close #30627
2019-06-11 00:03:11 +00:00
Keen Yee Liau 1f4c380f58 fix(bazel): Exclude common/upgrade* in metadata.tsconfig.json (#30133)
It has a dependency on @angular/upgrade which is not part of the
dependencies in package.json, so postinstall would fail.

PR Close #30133
2019-04-26 11:07:34 -07:00
Keen Yee Liau 0629ebd9e9 build(bazel): Bump CLI and @angular-devkit/* to v8 beta 15 (#29966)
PR Close #29966
2019-04-18 13:53:33 -07:00
Filipe Silva ea70d41ac2 test: ensure correct TS version before running postinstall (#29885)
The bazel-schematics test could suffer from a version skew where new CLI projects were not yet using a new TS version, but Angular packages already were.

This caused the the `ngc` call in the added `postinstall` to run and fail: https://circleci.com/gh/angular/angular/283109

PR Close #29885
2019-04-13 09:31:21 -07:00
Filipe Silva ef85336719 build: update to TypeScript 3.4 (#29372)
PR Close #29372
2019-04-10 12:12:16 -07:00
Keen Yee Liau 401b8eedd5 fix(bazel): Update schematics to support routing (#29548)
PR closes https://github.com/angular/angular/issues/29035

PR Close #29548
2019-03-27 12:35:52 -07:00
Pete Bacon Darwin bc88816c10 test: ignore the generated `demo` folder in the `bazel` integration test (#29092)
PR Close #29092
2019-03-20 14:45:54 -04:00
Keen Yee Liau d6d081e120 feat(bazel): Upgrade rules_nodejs and rules_sass (#29388)
PR Close #29388
2019-03-20 13:42:03 -04:00
Igor Minar 75748d6044 feat: add support for TypeScript 3.3 (and drop older versions) (#29004)
https://blogs.msdn.microsoft.com/typescript/2019/01/31/announcing-typescript-3-3/

BREAKING CHANGE: TypeScript 3.1 and 3.2 are no longer supported.

Please update your TypeScript version to 3.3

PR Close #29004
2019-03-13 10:38:37 -07:00
Keen Yee Liau f4f20daee3 refactor(bazel): Remove bazel-workspace schematics (#29148)
`bazel-workspace` schematics is no longer needed now that the Bazel
files are injected into the project by the Bazel builder.

PR Close #29148
2019-03-07 13:04:09 -08:00
Keen Yee Liau 7060d9038b feat(bazel): Hide Bazel files in Bazel builder (#29110)
This commit modifies the Bazel builder to copy the Bazel WORKSPACE and
BUILD.bazel files to the project root directory before invoking Bazel.

This hides the Bazel files from users.

PR Close #29110
2019-03-06 17:35:06 -08:00
Alex Eagle ba602dbaec build: update Bazel to 0.23 (#29058)
PR Close #29058
2019-03-01 15:24:05 -08:00
Greg Magolan 9fe522f3e2 build: yarn.lock updates (#28871)
PR Close #28871
2019-02-28 12:06:36 -08:00
Greg Magolan 3cc9ba24c6 build: fix integration/bazel on OSX and update integration yarn.lock files (#28900)
PR Close #28900
2019-02-21 17:49:17 -08:00
Keen Yee Liau b9eb662c4a test(bazel): Upgrade CLI dependencies for schematics test (#28872)
This commit makes the integration test for bazel-schematics more robust
by removing package.json.replace. Instead of replacing the file, the
test script now just overrides Angular packages with the local ones.

This commit also fixes running the test locally by providing default
argument for CI_CHROMEDRIVER_VERSION_ARG.

PR Close #28872
2019-02-20 10:55:29 -08:00
Keen Yee Liau e5e4e63e71 refactor(bazel): Schematics should fetch angular from distro (#28851)
PR Close #28851
2019-02-20 09:01:44 -08:00
Greg Magolan 25aae64274 build(bazel): do not build rxjs from source under Bazel (#28720)
PR Close #28720
2019-02-19 16:28:14 -08:00
Keen Yee Liau 49fb8c3cb0 fix(bazel): Install angular repo before yarn_install (#28670)
PR closes https://github.com/angular/angular/issues/28636

PR Close #28670
2019-02-13 09:52:30 -08:00
Greg Magolan 7a6237bc50 build: update lock files (#28532)
PR Close #28532
2019-02-05 16:55:43 -05:00
Greg Magolan ebaceb37e0 build: fix for integration test bazel-schematics (#28532)
PR Close #28532
2019-02-05 16:55:43 -05:00
Greg Magolan 0d1e065a1c build: update to rules_typescript 0.23.2 and rules_nodejs 0.16.8 (#28532)
PR Close #28532
2019-02-05 16:55:43 -05:00
Keen Yee Liau 4a92fa9471 refactor(bazel): Create `ng-add` schematic for Bazel (#28436)
The logic to create additional files needed for Bazel are currently
hosted in `ng new`. Such files include the main.*.ts files needed
for AOT and a different angular.json to use Bazel builder, among others.

This commit refactors the logic into `ng add` so that it can be used to
perform the same modifications in an existing project. Users could do so
by running `ng add @angular/bazel`.

With this change, `ng new` effectively becomes an orchestrator that runs
the original `ng new` followed by `ng add @angular/bazel`.

PR Close #28436
2019-02-05 14:40:46 -05:00
George Kalpakas 72c36956de ci: pin ChromeDriver to a version compatible with docker image's Chrome (#28494)
By default, `webdriver-manager update` will download the latest
ChromeDriver version, which might not be compatible with the Chrome
version included in the [docker image used on CI], causing CI failures.
Previously, we used to pin the ChromeDriver version on CI in
[ngcontainer's Dockerfile][2]. This was accidentally broken in #26691,
while moving from ngcontainer to default CircleCI docker images.

This commit fixes the issue by pinning ChromeDriver to a known
compatible version.

[1]: bfd48d156d/.circleci/config.yml (L16)
[2]: bfd48d156d/tools/ngcontainer/Dockerfile (L63)

PR Close #28494
2019-02-01 20:22:03 -05:00
Keen Yee Liau 36902e2f0e fix(bazel): Bazel builder resolves with require.resolve() (#28478)
This commit fixes a bug in the Bazel builder in which the path to Bazel
executable is constructed using the project path. For non-default
project, the node_modules directory is actually one level above the
project path.

This PR fixes the bug by resolving node_modules with require.resolve().
It requires @bazel/bazel v0.22.1 because previous versions do not have
index.js or main field in package.json and would cause node module
resolution to fail.

This has been tested with both bazel and ibazel.

PR Close #28478
2019-02-01 13:56:53 -05:00
Keen Yee Liau b1e099b657 fix(bazel): fix integration test for bazel-schematics (#28460)
With the release of @angular/bazel v7.2.3, the npm install step right
after `ng new` installs this version. However there is a bug in the
builder which results in bazel executable not found.

This bug was not discovered before because the dependencies of the
project created by `ng new` are not pinned.

The fix is to pin the version of @angular/bazel to 7.2.2 which relies on
global installation of bazel.

PR Close #28460
2019-01-30 19:05:11 -05:00
Keen Yee Liau c84739dc55 test(bazel): Integration test for Sass support (#28297)
Add .sass files to the integration test for bazel-schematics.

Also addressed Alex's comment in
https://github.com/angular/angular/pull/28167/files#r248149866
about the unit tests being too brittle.

PR Close #28297
2019-01-28 20:01:18 -08:00
Keen Yee Liau 3b48d13af8 fix(bazel): ng-new should run yarn install (#28381)
yarn install was disabled in ng-new for Bazel schematics because
Bazel manages its own node_modules dependencies and therefore
there is no need to install dependencies twice.

However, the first yarn install is needed for `ng` commands to work,
most notably `ng build`.

This commit restores the original behavior.

PR Close #28381
2019-01-28 11:54:37 -08:00
Keen Yee Liau 2a02f4beb2 test(bazel): Cleanup bazel-schematics integration test (#28351)
PR Close #28351
2019-01-25 12:47:25 -08:00
Keen Yee Liau a570fdf0f0 fix(bazel): Fix integration test after v8 bump (#28194)
The integration test for bazel-schematics installs Angular in
two different locations:

1. Bazel workspace
2. package.json -> fetched from npm

Pull request #28142 changes the test to always install (1) from
source. This breaks when there's a major version bump since the
versions locally and the version in package.json no longer match.

This change updates package.json to fetch @angular/* packages
locally as well.

PR Close #28194
2019-01-16 16:09:58 -08:00
Keen Yee Liau 2afbcafab7 test(bazel): Use local_repository to load Angular (#28061)
The current integration test for Bazel schematics downloads a
published version of Angular as required by the http_archive
rule in the CLI created WORKSPACE.
However, this makes the test less useful because it does not
actually test any changes to the Angular repo at source.
This PR replaces the http_archive method in the WORSPACE
with local_repository so that any local changes to the Angular
repo are tested accordingly.

With Typescript 3.2, the file e2e/src/app.po.ts generated by CLI
no longer compiles under Bazel due to missing type annotations.
A temporary file is placed in the integration/bazel-schematics
directory while the change is pending in CLI repo.
https://github.com/angular/angular-cli/pull/13406

PR Close #28061
2019-01-11 16:19:59 -08:00
George Kalpakas 176b3f12f4 ci: make `integration_test` job logs less verbose (#27934)
The build and test progress logs make the CI log output so long that it
can't be displayed in the UI and one has to download and view the file
locally instead. This makes it harder to get to the interesting lines,
such as error messages.

Similar to #26869, but for the `bazel-schematics` integration project.

PR Close #27934
2019-01-04 12:18:39 -08:00
Keen Yee Liau b08f3acf09 test(bazel): Make sure CLI project created with Bazel works with original workflow (#27741)
Bazel bits added to a CLI project should not be destructive.
The project should still work under the original CLI workflow.

PR Close #27741
2018-12-19 18:24:25 -05:00
Keen Yee Liau 85866defa4 fix(bazel): Set module_name and enable ng test (#27715)
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360

With that fixed, `ng test` now works.

`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.

PR Close #27715
2018-12-17 16:43:09 -08:00