angular: Parallel build fails: Another process, with id XXXXX, is currently running ngcc

๐Ÿž bug report

Affected Package

The issue is caused by package @angular/compiler-cli/ngcc

Is this a regression?

The previous version in which this bug was not present was: angular 6 (I upgrade from angular 6 to 9 (6->7, 7->8, 8->9) following the steps in the https://update.angular.io/

Description

I have a shared node_modules/ in a Linux environment. It is used by CI and others users to build their local angular 9 app. After upgrade to angular 9 many builds fail. Re-triggering them work sometimes.

๐Ÿ”ฌ Minimal Reproduction

Create a repo and issue many (I don't know, maybe 50) build commands at the same time.

๐Ÿ”ฅ Exception or Error


Another process, with id 372274, is currently running ngcc.
Waiting up to 25s for it to finish.
Error: Timed out waiting 25s for another ngcc process, with id 372274, to complete.
(If you are sure no ngcc process is running then you should delete the lock-file at /proj/pt/tools/nodejs_modules/nodegui_dep_3_0_0/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__.)
    at AsyncLocker.<anonymous> (/proj/pt/tools/nodejs_modules/nodegui_dep_3_0_0/node_modules/@angular/compiler-cli/ngcc/src/locking/async_locker.js:91:31)
    at step (/proj/pt/tools/nodejs_modules/nodegui_dep_3_0_0/node_modules/tslib/tslib.js:139:27)
    at Object.next (/proj/pt/tools/nodejs_modules/nodegui_dep_3_0_0/node_modules/tslib/tslib.js:120:57)
    at fulfilled (/proj/pt/tools/nodejs_modules/nodegui_dep_3_0_0/node_modules/tslib/tslib.js:110:62)
An unhandled exception occurred: NGCC failed.
See "/tmp/ng-USvOMI/angular-errors.log" for further details.

๐ŸŒ Your Environment

Angular Version:


./node_modules/.bin/ng version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / โ–ณ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 9.1.1
Node: 12.6.0
OS: linux x64

Angular: 9.1.2
... animations, common, compiler, core, forms, platform-browser
... platform-browser-dynamic, router
Ivy Workspace: error

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.901.3
@angular-devkit/build-angular     0.901.3
@angular-devkit/build-optimizer   0.901.3
@angular-devkit/build-webpack     0.901.3
@angular-devkit/core              9.1.3
@angular-devkit/schematics        9.1.1
@angular/cli                      9.1.1
@angular/compiler-cli             9.1.3
@angular/language-service         9.1.3
@ngtools/webpack                  9.1.3
@schematics/angular               9.1.1
@schematics/update                0.901.1
rxjs                              6.5.5
typescript                        3.8.3
webpack                           4.42.0

Anything else relevant?

Is there a way to increase this 25s timeout or a reliable way to make parallel builds without those timeouts? For me creating multiple node_modules/ is not an option. Prior to angular 9 I had the same set up and didnโ€™t have any problems with parallel builds.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 4
  • Comments: 33 (17 by maintainers)

Most upvoted comments

That PR has now landed. Closing this.

Do you fancy providing a PR for it?

You misunderstood me, I think. I donโ€™t want the config file to be added but just the retries changed. The not-configurable code already is there, it only needs to be set from 50 to 500 as it is the default with 10.

The configurable timeout is only available in v10. But the ability to recover from workers being killed (https://github.com/angular/angular/pull/36626) was landed on the patch branch 9.1.x and should appear in 9.1.5.

@arthurspa - I am sorry you couldnโ€™t fix the problem, but very pleased you have a workaround. We can certainly update ngcc to fail with a unique code if it times out but we may need to get the CLI team to pass that through. Also we are going to update the timeout to be 250 secs, which may solve the problem anyway.