Previously, the docker images used on CI where specified by a tag
(`10.16` and `10.16-browsers`). Since tags are not immutable, this only
pins specific characteristics of the environment (e.g. the OS type and
the Node.js version), but not others. Especially when using a tag that
does not specify the patch version (e.g. `10.16` instead of `10.16.0`),
it is inevitable that the image will change at some point, potentially
leading to unrelated failures due to changes in the environment.
One source of such failures can be the Chrome version used in tests.
Since we install a specific ChromeDriver version (that is only
compatible with specific Chrome version ranges), unexpectedly updating
to a newer Chrome version may break the tests if the new version falls
outside the range of supported version for our pinned ChromeDriver.
Using a tag that specifies the patch version (e.g. `10.16.0`) or even
the OS version (e.g. `10.16.0-buster`) is safer (i.e. has a lower
probability of introducing the kind of breakages described above), but
is still not fully hermetic.
This commit prevents such breakages by pinning the docker images by ID.
Image IDs are based on the image's digest (SHA256) and are thus
immutable, ensuring that all CI jobs will be running on the exact same
image.
See [here][1] for more info on pre-built CircleCI docker images and more
specifically [pinning images by ID][2].
[1]: https://circleci.com/docs/2.0/circleci-images
[2]: https://circleci.com/docs/2.0/circleci-images#using-a-docker-image-id-to-pin-an-image-to-a-fixed-version
PR Close#32602
This commit expands the `lint` CircleCI job to also run the
`tools/verify-codeownership.js` script. This script verifies that some
important files/directories in the codebase have code-owners assigned in
`.github/CODEOWNERS`.
The main purpose of this change is to prevent adding new directories
(e.g. packages or docs guides/examples) without assigning appropriate
code-owners. When no code-owner is explicitly assigned, corresponding
PRs will automatically request reviews from @igorminar, who is the
"fall-back" code-owner.
PR Close#32577
Updates the SHA that will be tested against in the `material-unit-tests` job
to the latest commit in the components repository. SHA 2817c9e2faa4140342336987a692d5dd30bf24c2
is needed in order to make the `material-unit-tests` job pass after the remove
of the `protractor_web_test_suite` bazel rule from @angular/bazel. `protractor_web_test_suite` is
now provided by the @bazel/protractor npm package.
PR Close#32485
The docs examples e2e tests have been quite flaky recently. This causes
the `test_docs_examples` and `test_docs_examples_ivy` CircleCI jobs to
often fail (and block PRs) without a real reason.
This commit adds support for re-running failed docs examples e2e tests
and configures the `test_docs_examples` and `test_docs_examples_ivy`
jobs to try running each test that fails a second time, before giving up
and marking it as failed.
Closes#31841Closes#31842
PR Close#32497
These were initally added to allow for CircleCI to provide a better failure UI using junit data.
This information is not currently being created for bazel tests and once it is created it will
be available on the cloud status pages created by the BEP for each bazel execution.
PR Close#32292
Updates the SHA that will be tested against in the `material-unit-tests` job
to the latest commit in the components repository. SHA 18b9ef3f5529f0fa8f034944681486447af7b879
is needed in order to make the newly introduced material-ci test blocklist effective.
PR Close#32243
We don't need to build this branch as it's informative for the purposes of figuring out
the diff between the master and what's synced into google3.
PR Close#32202
Updates the `material-unit-tests` job to the latest commit
on the components repository. 097f4335a4e0b6e6b579829ae3a9cffce6292d2b.
This commit ensures that the postinstall script does not run NGC
on schematic code from `@angular/core`. Running NGC on the
generated schematic code can cause unexpected issues as some
migrations import types directly from `@angular/compiler-cli`
while the entry-point is not usable in all cases.
See: https://github.com/angular/angular/issues/29220.
PR Close#31650
The `setup-local` npm script uses `NgPackagesInstaller` to replace the
Angular packages with the locally built ones. Previously, it would (a)
assume that the packages were built and (b) it would do anything if the
currently installed versions already correspond to locally built
packages (even if not the latest version).
This could lead to all sorts of errors, such as:
- Confusing error messages, `dist/packages-dist/` was missing.
- Using outdated build artifacts from `dist/packages-dist/` without a
warning.
- Not installing the latest locally built packages, because the ones
installed already corresponded to locally built (but older) ones.
This commit fixes these issues by ensuring that:
- The local packages are always built before being used by
`NgPackagesInstaller`.
- The local packages are installed, even if the ones install already
correspond to local packages.
NOTE: Special `*-ci` scripts are introduced (for use on CI) that skip
building the local packages, since that step would have been taken
care of (in a more efficient way) in a previous CI step.
PR Close#31985
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
Previously, the `test_saucelabs_bazel` job was run as part of the
`saucelabs_test` workflow every hour (for every "publish branch";
currently 8.0.x, 8.1.x and master).
Since this job runs a subset of the tests in
`legacy-unit-tests-saucelabs` (see [BUILD.bazel][1]) and is just a
proof-of-concept for running tests on SauceLabs via bazel, there is
little point in running is on all branches. It is also wasteful to run
it every hour, even if there were no changes pushed into the branch
since the last run.
This commit makes the job part of `default_workflow`, but limits it to
only be run on master builds (not on other branches or PRs). Based on
its recent history, the job is relatively stable and (since it will only
be run on master builds) it is not expected to affect our dev workflow.
[1]: https://github.com/angular/angular/blob/ef44f51d5/BUILD.bazel#L66-L92
PR Close#31636
Enables remote caching for CI jobs.
This configuration:
always reads from build cache on CI
only write to build cache for local builds for non-PR CI run
PR Close#31204
No longer uses docker in order to pull down the toolchain configs
for remote build execution. We don't need to make docker a prerequisite
for working on the Angular repository since we can leverage the checked-in
toolchain configurations from the `@bazel-toolchains` repository.
PR Close#31251
The publish_snapshots job is currently not able to decode the Github
token because the openssl version changed. This is because the default
digest for more recent openssl version has been updated and the github
token file has been encrypted with an old digest. We need to ensure
that the md5 digest is used for decryption as that matches the
digest used for encryption.
PR Close#31099
Updates the NodeJS version to the latest stable version at the time of
writing (v10.16.0). We need to update our image to use a minimum NodeJS
version of v10.15.0 because new CLI apps automatically install a non-locked
version of selenium-webdriver that now requires NodeJS >= 10.15.0 since the
latest release of 17th June 2019 (4.0.0-alpha.3).
See CI failures: https://circleci.com/gh/angular/angular/359077
PR Close#31088
Previously, we run the PWA score tests before unit/e2e tests, because
the latter would destroy the `dist/` directory required by the former.
Since cli@6, unit/e2e tests no longer detroy the `dist/` directory, so
it is now safe to run the unit/e2e tests first. This is preferrable,
since they are conceptually lower-level and any error messages (in case
of breakage) are more specific/actionable.
Related discussion about cli behavior:
- angular/angular-cli#4366
- angular/angular-cli#14701
PR Close#31047
After this PR is merged, maintainers no longer need to update .bazelrc
file, toolchain and platform related flags for RBE builds and tests
(unless there is a breaking change in Bazel related to those flags).
Maintainers just need to update the pin of @bazel-toolchains repo
regularly in the packages/bazel/package.bzl file according to
https://releases.bazel.build/bazel-toolchains.html to include the
latest checked-in toolchain configs. If rbe_autoconfig() cannot find
appropriate toolchain configs for the version of Bazel in the version of
@bazel_toolchains repo that is currently used by this project, it will pull
down the container and generate the configs on the fly as the beginning
of the build/test.
PR Close#29336
The `aio_monitoring_next` CircleCI job was disabled due to a failure in
[302254](https://circleci.com/gh/angular/angular/302254). It turned out
the failure was caused because the job happened to run after a change
had been merged into master and right before it was deployed to
https://next.angular.io/ causing the tests not to match the deployed
version.
This commit re-enables the job and moves it to a different time, when it
is less likely that PRs will be being merged (and thus reducing the risk
of a similar timming issue).
Fixes#30101
PR Close#30168
Previously, the `aio_monitoring_stable` job (which runs tests against
https://angular.io/) was using the tests from the master branch. As a
result, if the master branch included changes in those tests that were
not yet backported to the stable branch (and thus deployed to
https://angular.io/), the tests would fail.
This commit fixes this by using the tests from the stable branch to test
against https://angular.io/.
Fixes#30101
PR Close#30110
Previously, the `aio_monitoring` job was testing both the stable
(https://angular.io/) and the @next (https://next.angular.io/) versions.
This commit splits the tests into two separate jobs (still run as part
of the same workflow). This speeds up the tests (since the two jobs can
now run in parallel) and makes it easier to isolate failures (e.g.
identify which branch is failing, disable one of the two, etc.).
(Credits to @petebacondarwin 😉)
PR Close#30110
The job started failing for https://angular.io/, due to changes in tests
that only affected https://next.angular.io/, and was disabled in #30102.
This commit re-enables the job (since it does not block anything and it
will be fixed in a subsequent commit).
PR Close#30110
Redirects that were updated in 24c61cb63e break the aio_monitoring CircleCI job, since we run the tests against the production angular.io site (that doesn't have the latest redirects config yet).
This change temporary disables the aio_monitoring job to avoid failures for other PRs. The problem will be resolved and the job will be enabled in followup PRs.
PR Close#30102
We recently added the "uname -a" command to the CircleCI
integration test in order to identify Linux kernels that
broke Chrome sandboxing.
Since this issue seems to be claimed as fixed by the CircleCI
support and we didn't see any sandboxing issues the last month,
we are removing the debugging command we added.
PR Close#30006
To better test ngcc (in addition to Ivy) on angular.io, change the
`test_aio_local_ivy` CircleCI job to use the pre-ivy Angular packages
(and have ngcc transform them to Ivy ones).
PR Close#29989
The server used for testing on localhost has less optimizations (e.g.
serves uncompressed files), so we need to wait longer the ServiceWorker
to be loaded and registered to allow Lighthouse to reliably detect it,
especially on slower environments (e.g. CI).
Related: https://github.com/GoogleChrome/lighthouse/issues/5527#issuecomment-483710849Fixes#29910
PR Close#29953
Filipe Silva
Joey Perrott
George Kalpakas
Greg Magolan
Paul Gschwendtner
Igor Minar
JoostK
JiaLiPassion
Xin Gao
Andrew Kushnir