Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upbuild: migrate to node v12 #34955
build: migrate to node v12 #34955
Conversation
0aa4216
to
3409028
@@ -3,10 +3,10 @@ export declare const APP_BASE_HREF: InjectionToken<string>; | |||
export declare class AsyncPipe implements OnDestroy, PipeTransform { | |||
constructor(_ref: ChangeDetectorRef); | |||
ngOnDestroy(): void; | |||
transform<T>(obj: null): null; |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
devversion
Jan 24, 2020
Member
We had the same on angular/components
in the past. It's because NodeJS v12 now provides a stable sorting algorithm for .sort
. This will be used by ts-api-guardian
for sorting the members.
Lgtm Merge-assistance: global approval |
Marking this as |
var_3: &cache_key v3-angular-node-10.16-{{ checksum "yarn.lock" }}-{{ checksum "WORKSPACE" }}-{{ checksum "packages/bazel/package.bzl" }}-{{ checksum "aio/yarn.lock" }} | ||
var_4: &cache_key_fallback v3-angular-node-10.16- | ||
var_3: &cache_key v3-angular-node-12.14.1-{{ checksum "yarn.lock" }}-{{ checksum "WORKSPACE" }}-{{ checksum "packages/bazel/package.bzl" }}-{{ checksum "aio/yarn.lock" }} | ||
var_4: &cache_key_fallback v3-angular-node-12.14.1- |
This comment has been minimized.
This comment has been minimized.
gkalpak
Jan 25, 2020
Member
Why not -12-14-
(or maybe even 12
), so we don't have to update the key so frequently?
(I doubt the dependencies will be affected between patch or minor releases.)
This comment has been minimized.
This comment has been minimized.
@@ -109,7 +109,7 @@ executors: | |||
# - Node 12 | |||
# - yarn 1.17 | |||
# - Python 3 3.7.4 | |||
image: windows-server-2019-vs2019:201908-02 | |||
image: windows-server-2019-vs2019:stable |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
IgorMinar
Jan 26, 2020
Member
oh uh.. great catch! someone from circleci tried to move us to this "branch" image that autoupdates and it failed due to some issues. we should say pinned!
This comment has been minimized.
This comment has been minimized.
josephperrott
Jan 27, 2020
Author
Member
Moved it back, especially since we are going to set our version of node by installing it manually, we should be fine to stay pinned.
@@ -38,9 +38,12 @@ openssl aes-256-cbc -d -in .circleci\gcp_token -md md5 -out "$env:APPDATA\gcloud | |||
#################################################################################################### | |||
copy .circleci\bazel.windows.rc ${Env:USERPROFILE}\.bazelrc | |||
|
|||
#################################################################################################### | |||
# Install version of specific version of node. |
This comment has been minimized.
This comment has been minimized.
gkalpak
Jan 25, 2020
Member
# Install version of specific version of node. | |
# Install specific version of node. |
In angular#34955, we switched to Node.js v12 on master and 9.0.x. This causes the `aio_monitoring_job` CI job (which checks out files from the stable branch; currently 8.2.x) to start failing yarn's engines check (since the 8.2.x branch expects Node.js version <11). Since the job is expected to run with files from both the stable and the master branches (and since the version of Node.js is not important here), this commit uses the `--ignore-engines` option to prevent failures due to Node.js version mismatch. NOTE: Typically, the stable and master branch are on the same Node.js version, because related PRs land on both master and the patch branch. One exception is during RC periods, when the stable branch is different than the patch branch. These periods are usually short, but in the case of 9.0.0 the period has lasted several months causing the CI environments between master and the stable branch to get significantly out-of-sync.
In angular#34955, we switched to Node.js v12 on master and 9.0.x. This causes the `aio_monitoring_job` CI job (which checks out files from the stable branch; currently 8.2.x) to start failing yarn's engines check (since the 8.2.x branch expects Node.js version <11). Since the job is expected to run with files from both the stable and the master branches (and since the version of Node.js is not important here), this commit uses the `--ignore-engines` option to prevent failures due to Node.js version mismatch. NOTE: Typically, the stable and master branch are on the same Node.js version, because related PRs land on both master and the patch branch. One exception is during RC periods, when the stable branch is different than the patch branch. These periods are usually short, but in the case of 9.0.0 the period has lasted several months causing the CI environments between master and the stable branch to get significantly out-of-sync.
In angular#34955, we switched to Node.js v12 on master and 9.0.x. This causes the `aio_monitoring_job` CI job (which checks out files from the stable branch; currently 8.2.x) to start failing yarn's engines check (since the 8.2.x branch expects Node.js version <11). Example failure: https://circleci.com/gh/angular/angular/602499 Since the job is expected to run with files from both the stable and the master branches (and since the version of Node.js is not important here), this commit uses the `--ignore-engines` option to prevent failures due to Node.js version mismatch. NOTE: Typically, the stable and master branch are on the same Node.js version, because related PRs land on both master and the patch branch. One exception is during RC periods, when the stable branch is different than the patch branch. These periods are usually short, but in the case of 9.0.0 the period has lasted several months causing the CI environments between master and the stable branch to get significantly out-of-sync.
In angular#34955, we switched to Node.js v12 on master and 9.0.x. This causes the `aio_monitoring_job` CI job (which checks out files from the stable branch; currently 8.2.x) to start failing yarn's engines check (since the 8.2.x branch expects Node.js version <11). Example failure: https://circleci.com/gh/angular/angular/602499 Since the job is expected to run with files from both the stable and the master branches (and since the version of Node.js is not important here), this commit uses the `--ignore-engines` option to prevent failures due to Node.js version mismatch. NOTE: Typically, the stable and master branch are on the same Node.js version, because related PRs land on both master and the patch branch. One exception is during RC periods, when the stable branch is different than the patch branch. These periods are usually short, but in the case of 9.0.0 the period has lasted several months causing the CI environments between master and the stable branch to get significantly out-of-sync.
…#35004) In #34955, we switched to Node.js v12 on master and 9.0.x. This causes the `aio_monitoring_job` CI job (which checks out files from the stable branch; currently 8.2.x) to start failing yarn's engines check (since the 8.2.x branch expects Node.js version <11). Example failure: https://circleci.com/gh/angular/angular/602499 Since the job is expected to run with files from both the stable and the master branches (and since the version of Node.js is not important here), this commit uses the `--ignore-engines` option to prevent failures due to Node.js version mismatch. NOTE: Typically, the stable and master branch are on the same Node.js version, because related PRs land on both master and the patch branch. One exception is during RC periods, when the stable branch is different than the patch branch. These periods are usually short, but in the case of 9.0.0 the period has lasted several months causing the CI environments between master and the stable branch to get significantly out-of-sync. PR Close #35004
…#35004) In #34955, we switched to Node.js v12 on master and 9.0.x. This causes the `aio_monitoring_job` CI job (which checks out files from the stable branch; currently 8.2.x) to start failing yarn's engines check (since the 8.2.x branch expects Node.js version <11). Example failure: https://circleci.com/gh/angular/angular/602499 Since the job is expected to run with files from both the stable and the master branches (and since the version of Node.js is not important here), this commit uses the `--ignore-engines` option to prevent failures due to Node.js version mismatch. NOTE: Typically, the stable and master branch are on the same Node.js version, because related PRs land on both master and the patch branch. One exception is during RC periods, when the stable branch is different than the patch branch. These periods are usually short, but in the case of 9.0.0 the period has lasted several months causing the CI environments between master and the stable branch to get significantly out-of-sync. PR Close #35004
PR Close angular#34955
PR Close angular#34955
…angular#35004) In angular#34955, we switched to Node.js v12 on master and 9.0.x. This causes the `aio_monitoring_job` CI job (which checks out files from the stable branch; currently 8.2.x) to start failing yarn's engines check (since the 8.2.x branch expects Node.js version <11). Example failure: https://circleci.com/gh/angular/angular/602499 Since the job is expected to run with files from both the stable and the master branches (and since the version of Node.js is not important here), this commit uses the `--ignore-engines` option to prevent failures due to Node.js version mismatch. NOTE: Typically, the stable and master branch are on the same Node.js version, because related PRs land on both master and the patch branch. One exception is during RC periods, when the stable branch is different than the patch branch. These periods are usually short, but in the case of 9.0.0 the period has lasted several months causing the CI environments between master and the stable branch to get significantly out-of-sync. PR Close angular#35004
angular-automatic-lock-bot
bot
commented
Feb 27, 2020
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
josephperrott commentedJan 24, 2020
No description provided.