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-Edgehttps://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
Now that bazel respects the yarn-path value found in .yarnrc, we can
remove the last remaining reliances on our vendoring in
//third_party/github.com/yarnpkg/yarn/
PR Close#35083
In #35004, we started ignoring yarn's engines check for `yarn install`
in AIO's `test-production.sh` script to fix a failure in the
`aio_monitoring_stable` CI job. (See #35004 for details.)
It turns out that the version of yarn used on the stable branch (1.17.3)
`--ignore-engines` is needed on all yarn commands (including `yarn
run`). Thus, #35004 is not enough to fix the failures.
New example failure: https://circleci.com/gh/angular/angular/604341
This commit turns of the engines check for the whole
`aio_monitoring_stable` CI job to fix the failure and make the job more
robust.
PR Close#35033
* Added a /tools/saucelabs/sauce-service.sh script that manages the sauce-connect as a service which is used by the karma-saucelabs.js wrapper to start the service.
* Added /tools/saucelabs/README.md that covers the details of SauceLabs karma testing with Bazel.
PR Close#34769
We are migrating to PullApprove for our PR review management in an attempt
to allow for more granular and equitable code review assignments across the
team. Currently this migration is equivalent in the review assignments
it will create. Once stable, our expectation is that we will be able to
take advantage of PullApproves additional features for things like staged
reviews.
PR Close#34814
The `aio_monitoring_stable` CI job needs to check out (and execute
commands on) some files from the stable branch. Therefore, it needs to
use a version of `yarn` that is compatible with the `engines` version
specified in `aio/package.json`.
In #34902 (and subsequently #34952 for the 8.2.x branch), the way to
access our vendored version of yarn changed. This commit ensures that we
checkout the necessary files from the stable branch to use an
appropriate yarn version.
PR Close#34954
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
Creates a Bazel macro that can be used to test packages for
circular dependencies. We face one limitation with Bazel:
* Built packages use module imports, and not relative source file
paths. This means we need custom resolution.
Fortunately, tools like `madge` support custom resolution.
Also removes the outdated `check-cycles` gulp task that
didn't catch circular dependencies. It seems like the test
became broken when we switched the packages-dist output to Bazel. It
breaks because the Bazel output doesn't use relative paths, but uses
the module imports. This will be handled in the new Bazel macro/rule.
PR Close#34774
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
Since we always execute our bazel commands using RBE on CI
we should not have separete tasks of configuring bazel
and setting up RBE for bazel. Enabling RBE for bazel should
be part of our bazel configuration process on CI.
PR Close#34834
Previously, we added patches to the `angular/components` repository in
the `material-unit-tests` job in order to be able to run their tests
with TypeScript 3.7. This is no longer needed since the components
repository updated to Ts 3.7 already. Hence we can remove the patches.
PR Close#34863
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
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
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).
31a50f7ad2
PR Close#33717
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
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 6ae74a0eb2
that improved stability of a few menu tests that were flaky.
e.g. https://circleci.com/gh/angular/angular/564650
PR Close#34430
Currently the `saucelabs_view_engine` job fails because
the Saucelabs Bazel run script thinks that `--config=saucelabs`
is a flag targeting the actual script. This is not the case and
the flag should be actually part of the bazel command.
PR Close#34429
Currently we only run Saucelabs on PRs using the legacy View Engine
build. Switching that build to Ivy is not trivial and there are various
options:
1. Updating the R3 switches to use POST_R3 by default. At first glance,
this doesn't look easy because the current ngtsc switch logic seems to
be unidirectional (only PRE_R3 to POST_R3).
2. Updating the legacy setup to run with Ivy. This sounds like the easiest
solution at first.. but it turns out to be way more complicated. Packages
would need to be built with ngtsc using legacy tools (i.e. first building
the compiler-cli; and then building packages) and View Engine only tests
would need to be determined and filtered out. Basically it will result in
re-auditing all test targets. This is contradictory to the fact that we have
this information in Bazel already.
3. Creating a new job that runs tests on Saucelabs with Bazel. We specify
fine-grained test targets that should run. This would be a good start
(e.g. acceptance tests) and also would mean that we do not continue maintaining
the legacy setup..
This commit implements the third option as it allows us to move forward
with the general Bazel migration. We don't want to spend too much time
on our legacy setup since it will be removed anyway in the future.
PR Close#34277
We keep a version of yarn in the repo, at
`third_party/github.com/yarnpkg/`. All CI jobs should use that version
for consistency (and easier updates).
Previously, the Windows jobs did not use the local version. They used
the version that came pre-installed on the docker image that we used.
This made it more difficult to update the yarn version (something that
we might want to do independently of updating other dependencies, such
as Node.js).
This commit fixes this by setting up the Windows CI jobs to also use the
local, vendored version of yarn.
PR Close#34384
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
This reverts commit f029af50820765019413fa319330830306b80d6a while we investigate
some failures on master on Circle CI. Currently the Windows tests and the
"test-ivy-aot" jobs are red because of incompatible yarn versions.
PR Close#34402
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
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
In #33823, `scripts/package-builds.sh` (which is used by both
`build-packages-dist.sh` and `build-ivy-npm-packages.sh`) was updated to
use `realpath`. It turns out that `realpath` does not exist on macOS, so
the build scripts do not work there.
In order to fix this (and also reduce the likelihood of introducing
similar issues in the future), this commit changes these bash scripts to
Node.js scripts (using [ShellJS](https://github.com/shelljs/shelljs) for
a cross-platform implementation of Unix shell commands where necessary).
PR Close#33854
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
In #33046, internal uses of `zone.js` were switched to reference it
directly from source (built with Bazel) instead of npm. As a result, the
necessary scripts were updated to build `zone.js` as necessary. However,
some `integration/**/debug-test.sh` scripts were missed (apparently
because they are not used on CI, but only locally as helpers for
debugging the integration projects).
This commit updates the `scripts/build-packages-dist.sh` script to also
build `zone.js`, so that other scripts (such as the various
`debug-test.sh` scripts) can use it.
PR Close#33733
Updates the commit we run the `material-unit-tests` job
against. The latest commit includes 1255139a38
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
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
Paul Gschwendtner
Joey Perrott
Pete Bacon Darwin
George Kalpakas
Greg Magolan
Andrius
Filipe Silva
atscott
Kara Erickson
Igor Minar
JiaLiPassion
Matias Niemelä