Now instead of pushing the AIO build artifacts to the preview server
from inside a Travis job, the artifacts are built and hosted on the
CircleCI infrastructure. The preview server will then pull these
down after being triggered by a CircleCI build webhook.
The reporter was added in 87d56acda, with the purpose of fixing
source-map paths (which was apparently needed back then). Things have
moved around a lot since then and the custom reporter doesn't seem to be
necessary any more. By removing the reporter, we have one less thing to
worry about while upgrading karma; plus we get improvements in built-in
reporters for free.
Output with the custom reporter:
```
at someMethod (packages/core/.../some-file.ts:13:37)
```
Output with the built-in reporter:
```
at someMethod (packages/core/.../some-file.ts:13.37 <- dist/all/@angular/core/.../some-file.js:1:337)
```
PR Close#24803
With these changes, the types are a little stricter now and also not
compatible with Protractor's jasmine-like syntax. So, we have to also
use `@types/jasminewd2` for e2e tests (but not for non-e2e tests).
I also had to "augment" `@types/jasminewd2`, because the latest
typings from [DefinitelyTyped][1] do not reflect the fact that the
`jasminewd2` version (v2.1.0) currently used by Protractor supports
passing a `done` callback to a spec.
[1]: 566e039485/types/jasminewd2/index.d.ts (L9-L15)Fixes#23952Closes#24733
PR Close#19904
Two new CircleCI environments are created: test_ivy_jit and test_ivy_aot.
Both run a subset of the tests that have been marked with Bazel tags as
being appropriate for that environment.
Once all the tests pass, builds are published to the *-builds repo both
for the legacy View Engine compiled code as well as for ivy-jit and ivy-aot.
PR Close#24309
This uses a new script and CircleCI job called "build-packages-dist"
which shims the new Bazel build to produce outputs matching the legacy
build. We'll use this to get AIO testing onto CircleCI as well.
We move the integration tests to a new circleCI job that depends on this
one, as well as the build publishing job.
Note that every PR will have a trivial green publishing status, because
we always create this job even for PRs. We'd rather not - see
https://discuss.circleci.com/t/workflows-pull-request-filter/14396/4
PR Close#23512
We now create npm packages to cover all the public api assertions in tools/public_api_guard.
We no longer depend on ts-api-guardian from npm - it is now stale since the repository was archived.
There is no longer a gulp task to enforce or accept the public API, this is in CircleCI as part of running all bazel test targets.
PR Close#22639
This saves us an executor on Travis.
Note that we still do a bazel build on travis when we run the integration tests under e2e_2.
We expect that CircleCI is the only place we'll ever consume bazel-built artifacts.
PR Close#22170
There seems to be some issue that causes Chrome/ChromeDriver to
unexpectedly reload during the aio e2e tests, causing flakes. It is not
clear what exactly is causing the reloading, but to the best of my
knowledge it is something inside Chrome or ChromeDriver.
Pinning Chrome to r494239 (between 62.0.3185.0 and 62.0.3186.0) fixes
the flakes.
Fixes#20159
Since our version of Chromium is also pinned, a new ChromeDriver (that
drops support for our Chromium version) can cause random (and unrelated
to the corresponding changes) errors on CI.
This commit pins the version of ChromeDriver and it should now be
manually upgraded to a vrsion that is compatible with th currently used
Chromium version.
PR Close#20940
Add enough BUILD files to make it possible to
`bazel build packages/core/test`
Also re-format BUILD.bazel files with Buildifier.
Add a CI lint check that they stay formatted.
PR Close#20768
The scripts were accidentally broken in #20524. More specifically, when a limit
was exceeded the script would break while trying to log an error message due to
a missing `commit` variable.
This commit fixes it and also does some minor clean-up (improve docs, use more
descriptive variable names, remove dead code, etc).
PR Close#20683
When this command is run on CI, `yarn build` has already been run, so
this was unnecessarily building angular.io again (adding ~4mins to the
`aio` job).
When this command is run locally, it is most often about testing a new
`lighthouse` version/config, so you don't need to build angular.io over
and over (and if necessary, one can always run `yarn build` manually).
Closes#19633
Usages of `NgTools_InternalApi_NG_2` from `@angular/compiler-cli` will now
throw an error.
Adds `listLazyRoutes` to `@angular/compiler-cli/ngtools2.ts` for getting
the lazy routes of a `ng.Program`.
PR Close#19836
Also adds auto upgrade from lower version based
on the .d.ts file (e.g. from version 3 to 4).
This is needed as we are now also capturing type aliases
in metadata files (and we rely on this),
see 6e3498ca8e.
This commit allows building angular.io against the locally built Angular
packages. It adds two new npm scripts:
- `setup-local`: Same as `setup`, but overwrites the Angular packages for both
angular.io and the examples boilerplate with the locally built ones.
- `build-local`: Same as `build`, but uses `setup-local` instead of `setup`
under the hood, thus overwriting installed Angular packages with locally built
ones.
Fixes#18611
With this commit `ngc` is used instead of `tsc-wrapped` for
collecting metadata and tsickle rewriting and `tsc-wrapped`
is removed from the repository.
`@angular/tsc-wrapped@5` is now deprecated and is no longer
used, updated, or maintained as part as of Angular 5.x.x.
`@angular/tsc-wrapped@4` is still maintained and required by
Angular 4.x.x and will be maintained as long as 4.x.x is in
LTS.
PR Close#19298
* Remove now unnecessary portions of build.
* Add a compilePackageES5 method to build ES5 from sources
* Rework all package.json and rollup config files to new format
* Remove "extends" from tsconfig-build.json files and fixup compilation roots
PR Close#18541
The source map does not currently work with the transformer pipeline.
It will be re-enabled after TypeScript 2.4 is made the min version.
To revert to the former compiler, use the `disableTransformerPipeline` in
tsconfig.json:
```
{
"angularCompilerOptions": {
"disableTransformerPipeline": true
}
}
```
This commit also updates the version of `@angular/cli` used for docs examples.
The previous (transient) dependency `@ngtools/webpack` was not compatible with
`@angular/compiler-cli@>=5` and was breaking when running against the local
builds (currently at 5.0.0-beta.2). The version of `@ngtools/webpack` used by
the latest `@angular/cli` version is compatible with `@angular/compiler-cli@5`.
There are now 3 modes for deployment: next, stable, archive.
We compute which mode (and other deployment properties)
from the `TRAVIS_BRANCH` and the `STABLE_BRANCH`.
If the TRAVIS_BRANCH is master we deploy as "next".
If the `TRAVIS_BRANCH` matches the `STABLE_BRANCH` we deploy as "stable".
Otherwise if the branch has a major version lower than the stable version
and its minor version is highest of similar branches we deploy as "archive".
For "archive" deployments we compute the firebase project and deployment
url based on the major version of the `TRAVIS_BRANCH`.
As well as choosing where to deploy the build, we also use this
to select the environment file for the AIO Angular app.
This will enable the app to change its rendering and behaviour
based on its mode.
See #18287Closes#18297
There are now 3 modes for deployment: next, stable, archive.
We compute which mode (and other deployment properties)
from the `TRAVIS_BRANCH` and the `STABLE_BRANCH`.
If the TRAVIS_BRANCH is master we deploy as "next".
Otherwise if the branch is the highest of its minor versions
we deploy as "stable" if the `TRAVIS_BRANCH` matches the `STABLE_BRANCH` or
else "archive".
For "archive" deployments we compute the firebase project and deployment
url based on the major version of the `TRAVIS_BRANCH`.
As well as choosing where to deploy the build, we also use this
to select the environment file for the AIO Angular app.
This will enable the app to change its rendering and behaviour
based on its mode.
See #18287
In previous version of tsickle abstract class methods were materialized.
The change resulted in 6Kb savings in angular.io bundle.
This change also required the removal of `@private` and `@return` type
annotation as it is explicitly dissalowed by tsickle.
NOTE: removed casts in front of `makeDecorator` due to:
https://github.com/angular/devkit/issues/45
```
14938 Jul 19 13:16 0.b19e913fbdd6507d346b.chunk.js
1535 Jul 19 13:16 inline.d8e019ea3cfdd86c2bd0.bundle.js
589178 Jul 19 13:16 main.54c97bcb6f254776b678.bundle.js
34333 Jul 19 13:16 polyfills.4a3c9ca9481d53803157.bundle.js
14938 Jul 18 16:55 0.b19e913fbdd6507d346b.chunk.js
1535 Jul 18 16:55 inline.0c83abb44fad9a2768a7.bundle.js
582786 Jul 18 16:55 main.ea290db71b051813e156.bundle.js
34333 Jul 18 16:55 polyfills.4a3c9ca9481d53803157.bundle.js
main savings: 589178 - 582786 = 6,392
```
PR Close#18236
Since 808bd4af4, we are no longer pre-verifying PRs before uploading the build
artifacts to the preview server, thus we no longer need the
`travis-preverify-pr.sh` script or the `GITHUB_TEAM_MEMBERSHIP_CHECK_KEY`
variable.
There have been some issues lately with Travis jobs failing due to
`print-log.sh`. This is likely due to trying to print the Lighthouse PWA report,
which is too large.
This commit stops printing that report (since it was rarely used and is pretty
easy to acquire when needed) and restores the `print-logs.sh` script (that was
temporarily removed with dfcca66fd).
The current stable branch is determined based on the current version mapped to
the npm `latest` tag (by replacing the patch version number with 'x' - e.g.
`1.2.3` --> `1.2.x`).
PRs against the stable branch will be deployed to the preview server (as long as
the rest of the requirements are met). Commits on the stable branch itself will
be deployed to production.
Fixes#16908
(Coincidentally), this wasn't an issue before fdfeaaf1f, because
pre-verification was run after `test.sh`, during which `aio-builds-setup` was
built.
Now that `deploy-staging.sh` is being run before `test.sh`, we need to build
the `aio-builds-setup` scripts first.
Previously, PR previews were deployed after successfully running all tests.
While this makes sense for staging/production deployments, previews should be
available as soon as possible (and regardless of the outcome of tests).
Fixes#16705
Previously, no previews would be deployed for PRs that didn't touch files inside
`aio/`. Now, previews will be deployed for PRs that touch non-spec files inside
either `aio/` or `packages/` (as long as other preconditions are met).
Partially addresses #16526.