PR Close #40434

The changes in angular/components#20136 are required to allow the
framework tests to succeed.

PR Close #38273

Updates to the latest commit of the `angular/components` repository. We
need to do this because we removed the `esm5.bzl` output flavour aspect,
but an old version of the components repo relied on this file to exist.

This is no longer the case, and we can simply update the version of the
components repo we can test against.

PR Close #37623

Updates the commit the `components-repo-unit-tests` job runs
against. The goal is that we run against a revision that at
least contains: https://github.com/angular/components/pull/19336.

The new commit contains fixes for a flaky test in the datepicker that we
saw failing in the components-repo-unit-tests job too:
https://app.circleci.com/pipelines/github/angular/angular/15359/workflows/27ffae7c-a7b8-46a3-9c9e-6dd22ca4734d/jobs/712643.

Additionally, with this commit, the components repo unit tests job will
use TypeScript 3.9.2, so we can re-enable the job in another commit.

PR Close #37176

Updates the `components-repo-unit-tests` job to
https://github.com/angular/components/commit/d3a9ac67d2ef89ca9570c73af41111c796c135ca.

We need to update since we added a new diagnostic in ngtsc, and
the given commit in the components repo fixes failures caused by
the new diagnostic.

Note: This commit currently points to a PR as it's unlikely that
this fix lands soon, but we want to move forward. There is no
downside to doing that as the PR is based on top of the latest
components repo `master`.

PR Close #36921

Remove TypeScript 3.6 and 3.7 support from Angular along with tests that
ensure those TS versions work.

BREAKING CHANGE: typescript 3.6 and 3.7 are no longer supported, please
update to typescript 3.8

PR Close #36329

A caching mechanism was put in place to prevent repeated calls to
the Github API.  As the CI setup no longer relies on calls to the
Github API, this caching is no longer necessary.

It was discovered that this caching was causing a contention issue
for saucelabs testing as the same tunnel was being reused for
multiple jobs simultaneously.  With this caching mechanism removed
the jobs will once again run via separate tunnels.

PR Close #36936

Previously our CI during the setup process has made requests
to the Github API to determine the target branch and shas.
With this change, this information is now determined via git
commands using pipeline parameters from CircleCI.

PR Close #36500

Update to clang@1.4.0 to gain support for optional changing and nullish
coalescing.  Because this would trigger a change on >1800 files in the
repository, also changes our format enforcement to only be run against
changed files.  This will allow us to incramentally roll out the value
add of the upgraded clang format.

PR Close #36203

This is done by requesting the refs and shas for the PR when the
env.sh script is run.  Additionally, the env.sh script is now setup
to write all of the environment variables created to a cache file
and subsequent loads of the environment load the values from there.

The get-refs-and-shas-for-target.js script now also first attempts
to load the refs and shas from an environment variable before
falling back to requesting from github via the API.

PR Close #36207

* 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

Updates the commit that the `components-repo-unit-tests` job runs
against to the latest available commit at time of writing.

The motivation for updating is that a lot of changes have been made, and
that a upcoming framework PR that fixes check no changes for OnPush
components exposed a test failure in `angular/components`.

See: https://github.com/angular/components/commit/eae5cf886d6e93e0d189a7974d2615cc448d54e8

PR Close #35961

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

PR Close #35348

Updates the commit the `components-repo-unit-tests` job runs against.
We need at least https://github.com/angular/components/commit/2ec7254f88c4865e0de251f74c27e64c9d00d40a
which fixes a Ngcc postinstall patch conflict that required us to
temporarily disable the job in #35079.

PR Close #35123

In the past we had connecitivity issues on Saucelabs. Browsers on
mobile devices were not able to properly resolve the `localhost`
hostname through the tunnel. This is because the device resolves
`localhost` or `127.0.0.1` to the actual Saucelabs device, while it
should resolve to the tunnel host machine (in our case the CircleCI VM).

In the past, we simply disabled the failing devices and re-enabled the
devices later. At this point, the Saucelabs team claimed that the
connecitivy/proxy issues were fixed.

Saucelabs seems to have a process for VMs which ensures that requests to
`localhost` / `127.0.0.1` are properly resolved through the tunnel. This
process is not very reliable and can cause tests to fail. Related issues have been
observed/mentioned in the Saucelabs support docs. e.g.

https://support.saucelabs.com/hc/en-us/articles/115002212447-Unable-to-Reach-Application-on-localhost-for-Tests-Run-on-Safari-8-and-9-and-Edge
https://support.saucelabs.com/hc/en-us/articles/225106887-Safari-and-Internet-Explorer-Won-t-Load-Website-When-Using-Sauce-Connect-on-Localhost

In order to ensure that requests are always resolved through the tunnel,
we add our own domain alias in the CircleCI's hosts file, and enforce that
it is always resolved through the tunnel (using the `--tunnel-domains` SC flag).
Saucelabs devices by default will never resolve this domain/hostname to the
actual local Saucelabs device.

PR Close #35171

PR Close #34955

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

Since we always set up bazel on both our windows and linux CI
runs, we should consider this configuration part of the environment
setup.

PR Close #34834

Updates the `material-unit-tests` job commit to the latest
available commit. We need to update since the `angular/components`
repository updated to TypeScript 3.7, which means that we can remove
the TS 3.7 workarounds we applied to get the job green when framework
updated to TS 3.7.

PR Close #34863

Updates the SHA that will be tested against in the `material-unit-tests` job to the latest commit in the components repository. SHA 71955d2e194bfc5561f25daea16e68af266d6ff9 is needed in order to compile repository with typescript 3.7

PR Close #33717

Updates the commit SHA the `material-unit-tests` CircleCI
job runs against. We need to include a commit that makes
the node module installation more determinisitc (i.e. ensuring
that `tsickle` is always hoisted at the node module root).

https://github.com/angular/components/commit/31a50f7ad2947d9ceba99a64717ffa263a2a1d56

PR Close #33717

Revert "test: update to latest angular/components commit to pick up rules_nodejs 1.0 update (#34589)" (#34730)

This reverts commit d0400a11.

PR Close #34730

This reverts commit 0e52d929.

PR Close #34730

Also add comment that cache_key version should be bumped when switching forks or branches and added a comment from @devversion explaining how the fallback cache key works.

PR Close #34589

This commit includes https://github.com/angular/components/pull/18064 which is a pre-req for updating the angular repo to rules_nodejs 1.0.

PR Close #34589

The `aio_monitoring_stable` CI job is triggered as a cronjob on the
master branch and its purpose is to run some e2e tests against the
deployed stable version of the docs web-app at https://angular.io/. In
order for the tests to be compatible with the deployed version of the
web-app (which gets deployed from the stable branch), the stable branch
is checked out in git as part of the CI job.

Previously, we only checked out the `aio/` directory from the stable
branch, leaving the rest of the code at master. This doesn't matter as
long as the commands used to run the tests do not rely on code outside
of `aio/`. However, it turns out that there _is_ code outside of `aio/`
that affects the executed commands: It is our vendored version of yarn
(in `third_party/github.com/yarnpkg/`), which overwrites the global yarn
installed on the docker image on CI and must match the version range
specified in `aio/package.json > engines`.

Using the yarn version checked out from the master branch with the
`aio/` code checked out from the stable branch can lead to failures
such as [this one][1].

This commit fixes the problem by checking out both the `aio/` and
`third_party/github.com/yarnpkg/` directories from the stable branch and
re-running the steps to overwrite the global yarn executable with our
own version from `third_party/github.com/yarnpkg/`. This ensures that
the version of yarn used will be compatible with the version range
specified in `aio/package.json > engines`.

NOTE:
We cannot checkout everything from the stable branch, since the CI
config (`.circleci/config.yml` from the master branch) may try to run
certain scripts (such as `.circleci/get-vendored-yarn-path.js`) that are
not available on the stable branch. Therefore, we should only check out
the necessary bits from the stable branch.

[1]: https://circleci.com/gh/angular/angular/567315

PR Close #34451

Updates the material-unit-tests job commit SHA to the most recent
commit at the time of writing. The goal is to run the unit tests
with https://github.com/angular/components/commit/6ae74a0eb21268d4b107a052a8cf8ae63078bf99
that improved stability of a few menu tests that were flaky.

e.g. https://circleci.com/gh/angular/angular/564650

PR Close #34430

We keep a version of yarn in the repo, at
`third_party/github.com/yarnpkg/`. All CI jobs (including Windows ones)
should use that version for consistency (and easier updates). The path
to the actual `yarn.js` script, however, changes depending on the
version (e.g. `third_party/github.com/yarnpkg/v1.21.1/...`).
(NOTE: The Windows jobs are currently not using this local version, but
that should be fixed in a subsequent commit.)

Previously, when updating the local version of yarn, we would
potentially have to update the path in several places.

This commit addresses the problem by adding a Node.js script that infers
the correct path. The script can be used in all places where we need to
use the local version of yarn (including both Linux and Windows CI
jobs), thus eliminating the need to update the path in several places.

PR Close #34384

Since #32537, the `.circleci/get-commit-range.js` script is no longer
used in `.circleci/env.sh`. This commit removes the now unused local
variable to the script's path.

PR Close #34384

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

Currently all saucelabs usage in our repos is done using the same
account angular-ci.  By migrating to use individual accounts
for each repo, we can better track the usage for each repo as well
as providing concurrency limiting on a per repo basis.

Additionally, we no longer use two separate accounts based on being
on master or a PR branch, so this logic can be removed.

PR Close #34233

Updates the commit we run the `material-unit-tests` job
against. The latest commit includes https://github.com/angular/components/commit/1255139a38e5d8425bb6236c63c3d231301b21da

This commit reduces the flakiness of a `MatMenu` test and therefore
improves the stability of the material-unit-tests job.

Example failing build: https://circleci.com/gh/angular/angular/521625

PR Close #33716

build: update to latest material commit to pick up https://github.com/angular/components/pull/17620 (#33607)

PR Close #33607

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

Updates the commit of the Angular components repository for
which the `material-unit-tests` job runs tests against. We need to
update to the latest commit at the time of writing, in order to be able
to remove the gesture tests from the material-ci/blocklist.

This is now possible because the Angular components repository
removes the dependency on `hammerjs` completely.

PR Close #33221

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

Updates the `material-unit-test` job to run tests against
the latest commit of the Angular Components repository.

We need to update to a version where components already
updated to `rules_nodejs#0.38.0`.

PR Close #32889

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 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