lerna: Lerna bootstrap fails due to concurrency (with npm)
The latest RC version fails when running lerna bootstrap
. I’m not sure when it was introduced, though, because only today builds started failing on Travis while RC3 was released 8 days ago. So, I may be actually running into two separate issues. Both turned to have the same solution, though, switching off concurrency.
The issue, at least now, can be reproduced in the following way:
p@m /workspace/test> git clone git@github.com:ckeditor/ckeditor5.git
Cloning into 'ckeditor5'...
remote: Counting objects: 6484, done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 6484 (delta 32), reused 0 (delta 0), pack-reused 6407
Receiving objects: 100% (6484/6484), 1.16 MiB | 336.00 KiB/s, done.
Resolving deltas: 100% (3672/3672), done.
p@m /workspace/test> cd ckeditor5/
(master cbe80fd) p@m /workspace/test/ckeditor5> lerna bootstrap
Lerna v2.0.0-rc.3
Bootstrapping 1 packages
Preinstalling packages
Installing external dependencies
Installing hoisted dependencies into root
Pruning hoisted dependencies
FileSystemUtilities.rename ("./package.json", "./package.json.lerna_backup")
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
at Error (native)
NpmUtilities.installInDir (".", ["guppy-pre-commit@^0.4.0"], {})
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
at Error (native)
Errored while running BootstrapCommand.execute
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
at Error (native)
When I try with --concurrency=1
the issue doesn’t seem to appear:
(master cbe80fd) p@m /workspace/test/ckeditor5> lerna bootstrap --concurrency=1
Lerna v2.0.0-rc.3
Bootstrapping 1 packages
Preinstalling packages
Installing external dependencies
Installing hoisted dependencies into root
Pruning hoisted dependencies
Symlinking packages and binaries
Postinstalling packages
Prepublishing packages
Successfully bootstrapped 1 packages.
It also proved to help with a bit more complicated situation I had on Travis: https://travis-ci.org/ckeditor/ckeditor5/builds/226105896. It worked well after disabling concurrency: https://travis-ci.org/ckeditor/ckeditor5/builds/226101027.
I can see that similar issues were already reported: https://github.com/lerna/lerna/issues/397 and https://github.com/lerna/lerna/issues/616. However, this may be the first scenario in which the issue can be easily reproduced.
Your Environment
Executable | Version |
---|---|
lerna --version |
2.0.0-rc.3 |
npm --version |
4.0.3 |
node --version |
6.9.1 |
OS | Version |
---|---|
macOS Sierra | 10.12.4 |
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 10
- Comments: 22 (7 by maintainers)
Unfortunately, I didn’t save it as I went straight to
npm-debug.log
(which is usually more helpful so Lerna could mention that to the user). In the console, as I recall, there was just an info about crashing processes.I know that the npm log indicates that some JSON was missing/invalid, but I’ve seen the same error many times in the past. Usually, a second
lerna bootstrap
run would help with that. So, my assumption now, when I discovered thatlerna bootstrap --concurrency=1
helps even more consistently is that:/Users/me/.npm
) but it isn’t or is temporarily invalid at that moment,And why does it work when running
lerna bootstrap
for the second time (even concurrently)? Because the cache is already hot and all JSONs are usually already unpacked there.Anyhow reasonable?
We finally have a reliable workaround!!!
where the makefile does
The key is
travis_retry
where it will attempt the installation 3 times. So far we have 100% success.In our case I narrowed the bug down to npm version 6.10.2. I can successfully run 6.10.1 with concurrency=8, whereas using 6.10.2 it fails every time. Looking at the changelog there were changes in this version to cache file ownership, so this sounds likely.
We’re using node 12.13.0, although I’m not sure this is relevant.
(To be clear, I’m referring to the cache lock issue, e.g. ENOENT: no such file or directory, lchown ‘/Users/xxx/.npm/_locks/staging-5e1c07f26fab6251.lock’)
nope. npm5 does not.
Do you think it would be fruitful to make an integration test that demonstrates this behavior?