This commit increases the threshold of payload size tracking tests from
500 bytes to 5,000 bytes, and from 1% to 5%. This is done to minimize merge
conflicts while still catching real regressions.
PR Close#49520
After discussion initiated in the framework team (by kkostadinov),
the team has decided to not keeping the `components-repo-unit-tests`
job. This commit removes it.
PR Close#48521
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
PR Close#46976
If the snapshot publish job is manually being restarted, the tag in the
snapshot repo might already exist and the job will fail. We can just
forcibly re-create the tag (even if it will be at the same revision).
We use force mode in a couple of other command as well, such as `git
push` of the actual tag and snapshot revision/SHA.
PR Close#46366
We recently had a couple of issues with the shallowing of snapshot
git repositories. In an attempt to fix this, parts of the publish
script of the COMP repo have been used, but variables have not been
updated properly.
This commit fixes an unbound variable, avoiding errors when snapshots
are published for a new branch (e.g. when we branch-off).
PR Close#46076
Use the absolute path for the artifacts directory, as well as encapsulate the clone
vs init logic to prevent it from changing directories.
Manually remove the shallow marker so that git does not recognize this as a shallow repo.
PR Close#45979
Rather than using git init to create an empty repo and then shallow fetch the
repo for a specific branch, we shallow clone the repository itself for the branch.
This prevents us from running into the issue of Github denying the push because it
comes from a shallow branch which does not map back to the repository.
PR Close#45975
It looks like because the primary branch for our ephemeral repos doesn't match the build repos
we are pushing to it causes errors around shallow clones. This attempts to prevent this.
PR Close#45974
Uploading payload size is unreliable from within Bazel. This is
because tests might not run for every commit, tests might have
been cached from a pull request RBE-build (causing payload uploading
to be skipped most of the time as every change comes from a PR)
We should disable the uploading as this is a fundamental problem
(good thing to note now) that we can solve with better payload
size tracking that we want to establish as part of dev-infra.
PR Close#45446
For quite some time now, since we started to use Bazel for integration tests, we
relied on some size tracking logic that did not actually fully work under Bazel.
It was thought that all the necessary CI push/PR information is available to the
Bazel test, but that was not the case. This was now fixed with the recent Rules NodeJS
v5 update where I made sure the `env.sh` variables are actually available before we
write them to the temporary file for the Bazel-access.
This now will unveil an issue because payload size goldens would start being based
on their branch name. e.g. the golden key in `13.3.x` should not be `master` but
`13.3.x`. This makes more sense than `master` as key, but makes things more
cumbersome and ideally we would not store the branch name at all (this is a larger
change though -- not worth now since we might refactor this anyway). For now we will
update the size tracking logic to always use `master` as golden key (like it worked
in the past year(s))
With the environment fix we now (again) start uploading payload size results to Firebase.
This did not work by accident either. The uploading logic is reliant on the CircleCI
commit range which is not working/reliable in upstream branches. This commit
removes this reliance on `COMMIT_RANGE` since it's not strictly necessary and
currently breaking renovate PRs. We can re-enable this when we have a solution with
CircleCI, or a workaround/resolution logic provided in e.g. `ng-dev ci determine-commit-range`.
PR Close#45444
CI components test install the angular package from the local
version, but still use the zone.js from npm, so this commit let
components also install zone.js from local too.
PR Close#45277
To speed up the components CI job (avoiding it being a bottleneck in FW),
we will stop building everything in `src/...`, but rather only build targets
which are needed to run all tests within `src/...`.
This notably should avoid unnecessary NPM package building. Arguably that
part would also be valuable to have, but we already test the `ng_package`
rule in FW itself, plus we run snapshot tests in the components repo as well.
PR Close#44832
Re-enables the building of the `src/dev-app` package in the components
repo when the components-repo-unit-test job runs. We previously disabled
the dev-app because it was not compatible with template typechecking of
ngtsc. This should be fixed now and can re-enable it.
This could be valuable for having some actual real test scenarios of
type checking.
PR Close#43798
Previously, if a commit message contained a carriage return in its
header, the `payload-size.sh` script would fail to upload the payload
size data to Firebase, because the JSON payload would be messed up when
trying to concatenate the commit message headers. See an example
[here][1].
This commit avoids this problem by replacing carriage returns before
concatenating the commit message headers with the JSON payload string.
[1]: https://app.circleci.com/pipelines/github/angular/angular/37437/workflows/d0fa4adf-43bb-464e-a2fd-d87da15226dd
PR Close#43569
The shared dev-infra package from `HEAD` should not be installed
when running the `components-repo-unit-tests` job. This is done
because otherwise changes to the dev-infra package can result in
build setup issues for the CI job (while the goal of the CI job
is to test the framework)
PR Close#42268
We now include `misc/angular-in-memory-web-api` in the packages that
are build in the `dist/packages-dist` directory. But this package should
not be published as an artifact.
This commit prevents attempting to publishing the `misc` directory by
first checking whether the directory contains a `package.json` file.
PR Close#41393
Previously, when a payload size check failed, the error message prompted
the user to update the size limits using a CI-specific file path, which
was confusing (esp. for external contributors). See, for example,
https://circleci.com/gh/angular/angular/932733.
This commit improves the error message by printing the file path
relative to the repository root instead.
PR Close#41116
Historically files to be formatted were added to a listing (via matchers)
to be included in formatting. Instead, this change begins efforts to
instead include all files in format enforcement, relying instead on an
opt out methodology.
PR Close#36940
* integration tests target definitions in integration/BUILD.bazel updated to use a single dict
* payload tracking for integration tests updated to work under Bazel
* legacy integration_test CI job removed
* integration/run_tests.sh script no longer used in CI so it has been updated for running integration tests locally in the legacy way
PR Close#35985
Switches our tslint setup to the standard `tslint.json` linter excludes.
The set of files that need to be linted is specified through a Yarn script.
For IDEs, open files are linted with the closest tslint configuration, if the
tslint IDE extension is set up, and the source file is not excluded.
We cannot use the language service plugin for tslint as we have multiple nested
tsconfig files, and we don't want to add the plugin to each tsconfig. We
could reduce that bloat by just extending from a top-level tsconfig that
defines the language service plugin, but unfortunately the tslint plugin does
not allow the use of tslint configs which are not part of the tsconfig project.
This is problematic since the tslint configuration is at the project root, and we
don't want to copy tslint configurations next to each tsconfig file.
Additionally, linting of `d.ts` files has been re-enabled. This has been
disabled in the past and a TODO has been left. This commit fixes the
lint issues and re-enables linting.
PR Close#35800
Previously we needed the `components-repo-ci` blocklist to disable
tests that were failing during the development of Ivy. Since we fixed
all those failing tests, and we don't want to regress, we can remove the
blocklist logic.
Resolves FW-1807
PR Close#35115
We rename the `material-unit-tests` job to `components-repo-unit-tests`
because the job runs all unit tests found in the Angular Components repository.
This includes the Angular CDK, Angular Material and more. Also the repository has
been renamed from `angular/material2` to `angular/components` in the past.
PR Close#34898
The components repository has a Yarn resolution to ensure that
dgeni-packages uses a specific TypeScript version. This resolution
causes the specified TS version to be considered as candidate for the
`@angular/bazel` peer dependency. Ultimately, Yarn decides to use
the TypeScript version from the resolution for `@angular/bazel`,
and builds will fail due to a version mismatch.
This is because `tsickle` will use the hoisted top-level TS
version (set to `3.7.4` ), while `@angular/bazel` uses the
version from the resolution (at the time of writing: v3.6.4)
PR Close#33717
Before updating to remove the compile build variable, we must update
the components unit test integrations to a sha in the components
repo which no longer relies on the compile build variable.
PR Close#34280
The change type was only recorded for `aio/` and was not correct anyway.
For example:
- It considered `package.json` changes as `application` (even if only
`package.json` and `yarn.lock` had changed).
- It failed to account for changes in `@angular/*` dependencies, when
using the locally built Angular packages (instead reporting them as
`other`).
- It only looked at the last commit, so it failed to provide accurate
information for multi-commit builds (which are rare, but possible).
For the above reasons (and because there is no straight-forward way of
fixing it), this commit removes the change type from the uploaded data.
If necessary, it is still possible to find the type of changes from the
uploaded info (e.g. extract the associated commits and look at their
changes using git).
PR Close#33987
As part of the `payload-size` npm script in `aio/package.json` (which is
run on CI), the sizes of the angular.io app bundles are checked to
ensure they do not exceed certain limits and are also uploaded to
Firebase to be available for later analysis. The uploaded data include
the type of the changes (dependencies only, application only, or both).
The type of changes is inferred by looking at the files that have
changed inside the `aio/` directory.
When the `payload-size.sh` script was first introduced, the only files
that could affect bundle sizes were inside the `aio/` directory.
Therefore, the script would skip uploading the data and checking the
sizes if no changes were detected inside the `aio/` directory.
However, this assumption stopped being valid over time. For example:
- We started tracking/checking bundle sizes when building the angular.io
app with the locally built Angular packages (which live outside the
`aio/` directory.
- Due to CircleCI limitations, the `CI_COMMIT_RANGE` environment
variable (which is used for determining what files have been affected)
stopped reflecting the whole commit range of the build and only
included the last commit instead.
Based on the above, there were many cases were size data would not be
uploaded to Firebase, even when they may have been affected (because the
affecting changes were outside `aio/` - e.g. in framework packages).
This makes it harder to analyze size regressions, because important
data-points are missing.
Even worse, in these cases, the sizes were not even checked against the
specified limits, thus making it possible for size regressions to go
unnoticed (unless caught by other similar tests).
This commit fixes the `scripts/ci/payload-size.sh` script to always
track and check payload sizes for angular.io bundles.
NOTE: This change will result in more data being recorded (i.e.
recording data when it is not possible for the bundle sizes to
have been affected by the changes). This is still preferable to
failing to record and/or check when sizes could have been
affected.
PR Close#33987
The size diff threshold of 1% has proven to be too lenient for us
to catch size regressions in AIO. Since the AIO main bundle is
between 400-500 KB, a size regression must be between 4-5 KB before
it will cause the tests to fail. As a result, we may merge many
changes with smaller regressions of a few KB before the size test
eventually lets us know that the number has increased. The hope is
that lowering the threshold will help us catch the smaller
regressions during code review and prevent the size tests failing at
a random later time when someone catches the size "hot potato".
PR Close#33969
In efbbae5a4, the `publish_packages_as_artifacts` CircleCI job was
created to publish the build artifacts of PR builds on CI. In a8f4f14bd,
its scope was expanded to also publish build artifacts on non-PR builds.
The published artifacts names are constructed based on the PR number
(e.g. include `-pr12345-`), so on non-PR builds the names do not reflect
the source branch (instead, they include `-prfalse-`).
This commit fixes this by using the current branch name. For example,
artifact names for the `master` or `9.0.x` branch will include
`-master-` and `-9.0.x-` respectively (instead of `-prfalse-`).
(NOTE: For PRs, where branch name is `pull/12345`, the branch name is
transformed to `pr12345`.)
PR Close#33957
Since #33321, Angular packages have been persisted on each build as
CircleCI build artifacts (`.tgz` files), which can be used to install
dependencies on a project (for the purpose of testing or trying out a
change before a PR being merged and without having to build the packages
from source locally).
Previously, only packages published to npm under the `@angular` scope
were persisted as build artifacts.
This commit adds the `zone.js` package to the list of persisted
packages.
Fixes#33686
PR Close#33733
The Material units tests job has been disabled with the
typescript upgrade PR since the components repository was
still on an old TypeScript version (due to cyclic dependencies
between the framework and components repository).
Since the components repository has been updated to `9.0.0-next.15`
and now uses the compatible TypeScript version, we can re-enable
ds
Related to this change, we need to ignore the `package.json`
engines when installing the dependencies of the components repo. This
is because the components repo already updated to NodeJS v12 and Yarn
v1.19.1. This is not the case for the CI setup of framework. For now,
since we don't want to change the dev setup (as it slows down
development), we temporarily disable the engines.
Additionally, the material unit tests job now depends on the actual
release packages (not on the ngtsc compiled ones). This is because
the components repo setup relies on NGCC being run. This is also
helpful for validating ngcc against the framework packages.
PR Close#33530
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
