Previously, when one wanted to try out the changes from a PR before it
was merged, they had to check out the PR locally and build the Angular
packages themselves (which is time-consuming and wasteful given that the
packages have already been built on CI).
This commit persists all Angular packages on each build as `.tgz` files,
which can be used to install dependencies on an project (supported by
both [npm][1] and [yarn][2]). In addition to individual `.tgz` files for
each package, a `.tgz` file including all packages is also stored, which
can be used to test the packages locally by overwriting the ones in the
`node_modules/` directory of a project.
CircleCI [build artifacts][3] an be used for longer-term storage of the
outputs of a build and are designed to be useful around the time of the
build, which suits our needs.
[1]: https://docs.npmjs.com/cli/install.html
[2]: https://yarnpkg.com/lang/en/docs/cli/add
[3]: https://circleci.com/docs/2.0/artifacts
PR Close#33321
The `payload-size.sh` script is mainly used on CI to calculate, check
and potentially save (on non-PR builds) the sizes of the bundles for
various apps (including angular.io). If everything goes well (i.e. the
checks pass, meaning that the sizes did not increase above the specified
threshold) nothing is shown in the CI logs.
In some cases, it is useful to be able to see what the sizes were in a
specific build; e.g. for debugging purposes or when investigating a
gradual increase that happened over time. (Some of this info is
available on https://size.angular.io/, but not all.)
Previously, the only way to find out what the sizes were for a specific
build was to checkout the corresponding commit locally and build the
target app, which in turn requires building all Angular packages and can
take some time. Given that the sizes are already calculated on CI, this
was a waste.
This commit makes it easy to find out the bundle sizes for a specific
build/commit by always printing out the calculated sizes (thus making
them show up in the CI logs).
PR Close#33099
Updates the `material-unit-test` job to run tests against
the latest commit of the Angular Components repository.
The components repository updated to rules_nodejs#0.38.2 before Angular Bazel did.
To do this, the `@angular/bazel` v0.38.2 compatibility changes were patched on postinstall.
This now conflicts because we install a `@angular/bazel` version in the `material-unit-tests` job
that already includes these compatibility changes. This would result in the patch being a noop
for which the `patch` command throws an error.
We can remove this once components can install a released version of `@angular/bazel` that is
compatible with `rules_nodejs#0.38.2`.
PR Close#33073
The components repository updated to rules_nodejs#0.38.0 before Angular Bazel did.
To do this, the `@angular/bazel` v0.38.0 compatibility changes were patched on postinstall.
This now conflicts because we install a `@angular/bazel` version in the `material-unit-tests` job
that already includes these compatibility changes. This would result in the patch being a noop
for which the `patch` command throws an error.
We can remove this once components can install a released version of `@angular/bazel` that is
compatible with `rules_nodejs#0.38.0`.
PR Close#32889
Ensures that the `material-unit-tests` job does not accidentally build
subpackages of the `src/dev-app` in the components repo. This is now
an issue because the components repository updated their dev-app
to use Bazel with more individual subpackages. These subpackages
are not excluded by the `--deleted_packages` flag.
For best practice, we should use the exclusion target pattern
instead of the undocumented `--deleted_packages` flag anyway.
PR Close#32485
The commit range that is associated with a CI build is used for a couple
of things (mostly related to payload-size tracking):
- Determine whether a size change was caused by application code or
dependencies (or both).
- Add the messages of the commits associated with the build (and thus
the payload-size change).
NOTE: The commit range is only used on push builds.
Previously, the commit range was computed based on the
`CIRCLE_COMPARE_URL` environment variable. With [CircleCI Pipelines][1]
enabled, `CIRCLE_COMPARE_URL` is no longer available and the commit
range cannot be reliably detected.
This commit switches `CI_COMMIT_RANGE` to only include the last commit.
This can be less accurate in some rare cases, but is true in the
majority of cases (on push builds). Additionally, it stores the CircleCI
build URL in the database along with the payload data, so the relevant
info can be retrieved when needed.
[1]: https://circleci.com/docs/2.0/build-processing
PR Close#32537
This commit changes the Angular compiler (ivy-only) to generate `$localize`
tagged strings for component templates that use `i18n` attributes.
BREAKING CHANGE
Since `$localize` is a global function, it must be included in any applications
that use i18n. This is achieved by importing the `@angular/localize` package
into an appropriate bundle, where it will be executed before the renderer
needs to call `$localize`. For CLI based projects, this is best done in
the `polyfills.ts` file.
```ts
import '@angular/localize';
```
For non-CLI applications this could be added as a script to the index.html
file or another suitable script file.
PR Close#31609
Ivy snapshots no longer contain metadata.json which breaks the detection logic for
Angular Package Format (APF) in npm/yarn install.
This PR adds ANGULAR_PACAKGE as a magic file to denote APF.
See https://github.com/bazelbuild/rules_nodejs/issues/927
PR Close#31900
Initially the blocklist has been removed because there were
no remaining disabled tests that failed. Also the blocklist
logic didn't work anymore because the `material-unit-tests` CI
job now runs against `angular/components#master` with Bazel.
388578fec9 tried to revert the removal
of the blocklist in favor of a new upcoming breaking change with
HammerJS, but the revert doesn't help since the blocklist still
doesn't work with Bazel.
In order to make the blocklist work with the unit tests running
with Bazel, a PR has been submitted on the components repository.
See: https://github.com/angular/components/pull/16833.
This commit updates the blocklist logic on the framework side to
work with the new logic on the components repo side.
PR Close#32239
Initially when the `material-unit-tests` job got wired up,
Ivy was not really backwards-compatible and a few bugs caused
test failures when running the Angular Material test suites w/ Ivy.
These bugs got fixed progressively and eventually the test
blocklist became empty. At this point we don't want to regress
in the future and the blocklist should never have new items.
Additionally since we switched the unit-tests job to run against
Angular Material `master` with Bazel, the blocklist is no
longer respected. Therefore we can safely remove the blocklist.
PR Close#32138
No longer locks the Material unit tests job to a specific branch, but rather allows
locking to a specific commit from a given branch. This allows us to use the
"master" branch from the `components` repository.
PR Close#31569
Previously, the ivy-2019 branch of the Material (aka components) repo was
used, which contains some changes that were necessary to work with Ivy.
These changes are not longer necessary, as Material's master branch is
fully working with Ivy today. To be up-to-date with recent Material
development and its support for more recent dependencies, e.g. TypeScript,
it is desirable for us to be on a newer version of Material.
This commit moves the Material tests away from the ivy-2019 branch, to a
recent commit on master. We are not targeting the master branch itself,
as that would introduce a moving target into Angular's CI checks, which
is undesirable.
Lastly, the usage of gulp to run Material's tests is changed into using
Bazel, as Material itself is now also built with Bazel.
PR Close#31569
Payload size tracking was temporarily disabled in #31057, due to
`CIRCLE_COMPARE_URL` stopping being available. It turned out this was
related to turning on the new [Pipelines][1] feature, which was required
for testing Windows on CircleCI.
Since then, we have turned `Pipelines` off and got `CIRCLE_COMPARE_URL`
back (e.g. see [build 362971][2]). According to CircleCI, failing to
populate `CIRCLE_COMPARE_URL` with `Pipelines` on is a bug and they are
working on fixing it.
[1]: https://circleci.com/docs/2.0/build-processing/
[2]: https://circleci.com/gh/angular/angular/362971Fixes#31121
PR Close#31138
The `CIRCLE_COMPARE_URL` is not available in builds any more since we
enabled `Pipelines` on CircleCI. We have contected CircleCI, but until
this is solved we cannot get the commit range and thus disabling
uploading of payload size data to avoid broken builds.
PR Close#31057
Currently we cache the Material `node_modules` after
the `run_angular_material_unit_tests.sh` completed. This
means that the cache will incorrectly contain the Ivy NPM
package output which might be incompatible with the
other Material dependencies. e.g. the Material postinstall
command now uses a different NGC version that does not
work with the `typescript` version that has been specified in
the Material project.
PR Close#29416
Moving the tests over to CircleCI in pretty much "as-is" state just so that we can drop the dependency on Travis.
In the followup changes we plan to migrate these tests to run on sauce under bazel. @gregmagolan is working on that.
I've previously verified that all the tests executed in legacy-unit-tests-local already under bazel.
Therefore the legacy-unit-tests-local job is strictly not necessary any more, but given how flaky legacy-unit-tests-saucelabs is,
it is good to have the -local job just so that we can quickly determine if any failure is a flake or legit issue
(the bazel version of these tests could theoretically run in a slightly different way and fail or not fail in a different way, so having -lcoal job is just an extra safety check).
This change was coauthored with @devversion
PR Close#27937
the polymer benchmarks are super old and not relevant any more
and these benchmarks were the only reason why we needed bower at all
so long, bower. thanks for all the fish.
PR Close#27931
Some engineers were already on Yarn 0.10.x which was permitted by the range in our package.json#engines
However this introduced 'integrity sha512' lines into the yarn.lock files.
Then when engineers use yarn 0.9 (in particular, Bazel did this) then the lock files get tons of meaningless edits.
We could force everyone back to yarn 0.9 but this commit chooses to instead advance everyone past 0.10
PR Close#27193
These files are not needed once the size has been calculated and there
is no point in keeping them around.
Deleting them prevents, for example, uploading unnecessary files from
`aio/dist/` to Firebase (because `deploy-to-firebase.sh` runs the
payload size checks right before deploying).
PR Close#26746
This commit includes the following changes:
* CLI version information is read from the CLI package from which
we read the help files.
* CLI API pages now contain GH links
* line numbers are not shown in GH links, if the doc does not
have a truthy `startingLine` value. This allows us to remove
hard coded checks for `guide` pages
* content pages and CLI api docs no longer have a `startingLine`
* the hard-coded `packages` path segment has been removed from
the templates; instead we now only use the `realProjectRelativePath`.
* the `realProjectRelativePath` has been updated accordingly for API
and CLI API docs.
PR Close#26515
The deployment of PR previews is triggered by the notification webhook
of the `aio_preview` CircleCI job (which creates and stores the build
artifacts).
This commit adds a new job (`test_aio_preview`), which waits for the
preview to be deployed (for PRs that do have a preview) and then runs
some tests against it (currently only PWA tests).
Fixes#23818
PR Close#25671
George Kalpakas
Greg Magolan
Paul Gschwendtner
Pete Bacon Darwin
Keen Yee Liau
Kara Erickson
JoostK
Matias Niemelä
Jeremy Elbourn
Igor Minar
Alex Eagle