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
The PWA score tests have been occasionally failing on CI recently
(possibly due to CI VM/network issues).
This commit temporarily disables them, until we investigate the
root-cause and/or put a work-around in place.
The PWA score tests are still run against the deployed versions (which
don't suffer as much) or PRs with public previews (as part of the
`test_aio_preview` job) and on upstream builds (as part of the
`deploy_aio` job).
Related to #29910.
[1]: https://github.com/angular/angular/blob/3a836c362/.circleci/config.yml#L390
PR Close#29911
Run all targets with RBE config. Previously we filtered out one target, //tools/ts-api-guardian:tests, and ran that with a different bazelrc
PR Close#29731
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
The CircleCI team needs to know what causes the Kernel
inconsistency that most likely causes our no usable sandbox
errors. Therefore we add "uname -r"
PR Close#29309
Recently we moved the Saucelabs job into a cronjob in order to avoid
heavy flakiness that we experienced due to a Saucelabs connect bug
that has been supposedly fixed by the Saucelabs team (no new version
is released yet though).
Our initial assumption was that we very rarely hit specific browser failures
and can therefore move the Saucelabs tests into a cronjob, but after some
days of having the cronjob, we realized that we actually hit browser-specific
failures quite often and that we should run the tests for every PR (like before)
PR Close#29255
Currently the "test_docs_examples_ivy" job attaches
the legacy package output, while we can also attach
the Ivy NPM package output. We don't need Ngcc to downlevel
the Angular packages in order to build AIO with Ivy.
PR Close#29117
Currently the `test_saucelabs` job does not use our general
CircleCI bazel configuration. We should set this configuration
up, as it enables better logging, better use of the `xlarge`
resource class, and also sets up Bazel's integrated flakiness
retry functionality.
PR Close#29106
Currently when `sauce-connect` times out after 2min, we just
print a message saying that the SauceLabs tunnel didn't establish
within 2min. In order to make debugging easier, we now print the
full log file output on failure.
PR Close#29084
Currently the docs example tests (`test_docs_examples_ivy`
and `test_docs_examples`) are the culprits for a slow-down
in our overall CI turnaround. We need to increase parallelism
in order to make our CI turnaround more _acceptable_. This is
temporary and the long-term goal is to move these tests to Bazel
with remote build execution.
References #28940
PR Close#28984
Currently the "test_docs_examples_ivy" job attaches
the legacy package output, while we can also attach
the Ivy NPM package output. We don't need Ngcc to downlevel
the Angular packages in order to run the docs examples with Ivy.
PR Close#28984
Initially when we introduced the cronjob for Saucelabs,
we specified that the tests should run every 4h. Since the
caretaker needs more recent results when merging PRs
or before creating a release, we should run the saucelabs
tests every hour. This still ensures that PRs are not
affected by Saucelabs flakiness or incidents, and
the caretaker can also react better to real browser
failures (and isn't blocked on a 4h time frame)
PR Close#28903
Previously, our yarn (which overwrote the pre-installed yarn on the
docker image) was only available through `$BASH_ENV` (as an exported
function). This caused it to be undefined for commands executed in other
shells (e.g. via Node.js' `child_process.spawn()` unless explicitly
configuring it to run with `bash`).
This commit fixes this by making our yarn version available globally via
a symlink (`/usr/local/bin/yarn`).
(This was accidentally broken in #28839.)
PR Close#28889
We no longer want to run Saucelabs for every PR/commit because
Saucelabs has been very flaky recently and it blocks most of the
PRs with a flaky failing state that we cannot fix most of the time due
to upstream Saucelabs failures/incidents. Since real browsers tests
rarely catch browser-specific failures (same as in Material), we should
only run Saucelabs in a cronjob on the upstream branches. This still
ensures/guarantees our browser compatibility, but makes our CI
more stable and the PR workflow more productive.
PR Close#28787
George Kalpakas
JiaLiPassion
Joey Perrott
Paul Gschwendtner
Xin Gao
Andrew Kushnir
Alex Eagle
Filipe Silva
Greg Magolan