We've recently marked the ngtsc test as flaky for the Windows
job. We should not attempt running tests 3 times locally. This
negatively impacts the debugging/developer workflow.
Instead, flaky test attempts can still be made on CI. Using the
default attempt count of 3.
PR Close#50852
Enables colors for Bazel in CircleCI. Bazel does not seem to
detect color support properly, but CircleCI does support such.
Colors make debugging a little easier with larger Bazel logs.
PR Close#50720
This commit updates the minimum supported Node version across packages from 16.13.0 -> 16.14.0 to ensure compatibility with dependencies.
PR Close#49771
Ocasionally Node is randomly not installed in the Windows job. We've
been trying to debug this for a while. With the additonal debug
information it looks like in some situations the NodeJS folder from
NVM is not even present.
One idea is to use `nvm on` to ensure NVM is actually enabled. It's
unclear why it would be `off` at VM start, but it's worth giving a try.
Trying `nvm off` via SSH yields similar issues as we saw in the flaky
workflows:
https://app.circleci.com/pipelines/github/angular/angular/56160/workflows/2f1b80b3-29c7-4274-804e-cb994c20aff0/jobs/1287228
PR Close#49142
It looks like the wrapping in `&> /dev/null` breaks for some reason.
We don't need it as CircleCI will remove secrets from logs if they
would leak for some reason.
A simple echo is very unlikely ever printing its content to
stdout/stderr though.
PR Close#48648
Instead of encoding the GitHub snapshot robot access token
in a file that needs to be decoded by an ambiguously named
secret called `KEY`, the token can be directly stored in the
secrets of CircleCI given easier maintenance and the same risk.
The leakage of the secret still means the GitHub token file could
be decoded.
We are switching to a similar model as in the components repo, which
also simplifies key rotations etc.
PR Close#48644
This will help making it easier to update patches when `node_modules`
are cached. Note that most of the time this shouldn't be necessary
as we only cache the Yarn `.cache` for the non-windows jobs. Windows
job caches `node_modules` directly- so could be affected and needs
a cache reset/wipe occasionally when patches change (even though it's
rarely). Long-term we can remove this when the esm patches are no longer
needed.
PR Close#48521
ZoneJS is no longer loaded as an UMD, but instead is included as part
of the browser init entry-point. This means that ZoneJS is bundled and
the ESBuild logic needs to be adjusted for that.
PR Close#48521
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
* Adjusts tests to no longer rely on CommonJS features. Switches them to
ESM
* Updates test initialization files to not double-initialize Jasmine now
that bootstrap files are loaded after Jasmine. The `jasmine.boot`
setup was hacky from `rules_nodejs` and will break in the future
regardless if we e.g. use `rules_js` with actual unmodified `jasmine`.
PR Close#48521
The docker-based AIO preview deploy setup is replaced with
significantly simpler setup using GitHub actions provided by
dev-infra (also something dev-infra can maintain better then).
The actions under the hood leverage Firebase preview channels.
PR Close#48345
Ocassionally the NodeJS version is not correct after NVM on Windows.
This adds some debug information that should help improve stability
here. A recent attempt to update the `$PATH` did not seem to help.
PR Close#48351
These steps builds AIO which is memory intensive. Running out of memory
may be the cause of some ci flakiness. Change the executor size to test
this theory.
For context: The CLI process is randomly getting `Killed`, likely by the
linux OOM killer. The Angular CLI builds happen on the host machine- no RBE.
Without the Bazel migration they were previously already at ~63% peak RAM.
With Bazel's overhead and e.g. remote caching, it seems to hit 100%
(can be seen in CircleCI machine insights). OOM killer may then choose the
highest consuming task. i.e. the Angular CLI and kill it.
Angular CLI build ram consumption is proportional to the size of the app. AIO is not small
https://app.circleci.com/pipelines/github/angular/angular/53992/workflows/ec47e3d8-2e7d-45b8-a802-7ec8ec4026c4/jobs/1265666/parallel-runs/0/steps/0-106https://angular-team.slack.com/archives/C02PARQNMC1/p1670067910332809i
PR Close#48342
The `test_win` job is occasionally failing where a super old NodeJS
version is used even though we installed a proper one with `nvm`.
It's unclear how the CircleCI windows VMs differ here, it's coming
up rarely and is hard to reproduce when SSH-ing into VMs. Our best
guess is that the existing NodeJS version from the container/image is
super old and somehow takes precedence over the NVM-managed NodeJS
version. This could happen due to bad ordering in the `$PATH`
environment variable, or NVM not properly being wired up there.
We attempt to fix this by always setting `$PATH` to the NVM symlink
directory manually- with highest priority.
PR Close#48326
Bazel otherwise may almost look as being stuck when it performs
many slow e2e tests. We should show what is running, even it results
in a little more output in the logs.
PR Close#48316
This change aligns with the supported Node.js versions of the Angular CLI.
See: https://github.com/angular/angular-cli/pull/24026
BREAKING CHANGE: Angular no longer supports Node.js versions `14.[15-19].x` and `16.[10-12].x`. Current supported versions of Node.js are `14.20.x`, `16.13.x` and `18.10.x`.
PR Close#47730
Previously, `setDisabledState` was never called when attached if the control is enabled. This PR fixes the bug, and creates a configuration option to opt-out of the fix.
Fixes#35309.
BREAKING CHANGE: setDisabledState will always be called when a `ControlValueAccessor` is attached. You can opt-out with `FormsModule.withConfig` or `ReactiveFormsModule.withConfig`.
PR Close#47576
Updates the version range in the compiler to require at least TypeScript 4.8. Note that I'm keeping the backwards-compatibility layer for 4.7 around for now until internal projects have been migrated to 4.8.
BREAKING CHANGE:
TypeScript versions older than 4.8 are no longer supported.
PR Close#47690
Yarn 1.x has a bug where it keeps nested unused node modules and doesn't
delete them automatically. This throws off Bazel in some scenarios when
the lock file is updated. This commit invalidates the cache to get a
fresh clean node modules cache without any unused nested directories.
PR Close#47240
This commit enables publishing of snapshots for the `image-directive`
feature branch. The artifacts can be accessed with the following steps:
1. Land your change in `image-directive`
2. Go to the corresponding snapshot repo (e.g. `angular/common-builds`)
3. Go to the `image-directive` branch
4. Copy the SHA of the latest commit in that branch
5. Use that SHA to install via NPM. e.g.
`https://github.com/angular/common-builds.git#SHA`.
PR Close#47082
Yarn 1.x. is known to not prune nested unused node modules. This throws
off Bazel when the dependency tree changes but there are leftover unused
nested node module folders. This causes CI failures currently after the
dependency tree updates.
Invalidating the cache fixes this issue. Long-term a switch to Yarn
2.x+, pnpm will fix this.
PR Close#46707
For the branch rename migration we temporarily had to work
from a forked-off branch. Now that all the migration and cleanup
Is complete, we can switch to the actual new main branch.
This is the last remaining cleanup in the organization as it seems.
PR Close#46743
This commit disables the `aio_preview` CircleCI job temporarily, since it's failing after switching to CircleCI API v2. It will be enabled back once the code is updated. More info can be found here: https://github.com/angular/angular/issues/45931
PR Close#45932
An additional issue with the current approach of how Yarn and Bazel
interact, Yarn 1.x. does not prune unused nested `node_modules`. This
can throw-off the Bazel NodeJS rules because they (correctly) would not
expect such a nested folder.
This seems to happen in some caches currently, so we invalidate the
cache. Its worth seeing if we should rather cache the Yarn cache
folder on Windows as well, but for now this will remain as is.
Yarn 2.x+ will solve this for us, by addressing the root-cause.
Dev-Infra already has Yarn 2.x+ running, so it's not far from happening.
PR Close#45872
Paul Gschwendtner