Issues with execsync prevent codecov from installing correctly
See original GitHub issueIssue Description
Realizing this is an issue of one of your dependencies, I did decide to post it here. After all, I am not interested in your dependency, but in your project.
On Ubuntu 14.04 (vagrant box), the system hangs when compiling native extensions. No errors thrown, no exit code, it just hangs until you manually stop it:
npm verb linkBins execSync@1.0.2
npm verb linkMans execSync@1.0.2
npm verb rebuildBundles execSync@1.0.2
npm verb rebuildBundles [ 'temp' ]
npm info install execSync@1.0.2
npm info postinstall tough-cookie@2.2.1
npm verb readDependencies loading dependencies from /home/vagrant/<<company>>/node_modules/codecov/node_modules/request/node_modules/har-validator/node_modules/chalk/node_modules/strip-ansi/package.json
npm verb readDependencies loading dependencies from /home/vagrant/<<company>>/node_modules/codecov/node_modules/request/node_modules/har-validator/node_modules/pinkie-promise/node_modules/pinkie/package.json
> execSync@1.0.2 install /home/vagrant/<<company>>/node_modules/codecov/node_modules/execSync
> node install.js
[execsync v1.0.2] Attempting to compile native extensions.
On OS X Yosemite, it works… at least it doesn’t throw around exit codes, but it still logs a failure:
npm install --save-dev codecov
> execSync@1.0.2 install /Users/stephanbijzitter/<<company>>/node_modules/codecov/node_modules/execSync
> node install.js
[execsync v1.0.2] Attempting to compile native extensions.
[execSync v1.0.2]
Native code compile failed!!
codecov@1.0.1 node_modules/codecov
├── argv@0.0.2
├── urlgrey@0.4.1
├── request@2.69.0 (aws-sign2@0.6.0, forever-agent@0.6.1, tunnel-agent@0.4.2, is-typedarray@1.0.0, oauth-sign@0.8.0, caseless@0.11.0, stringstream@0.0.5, isstream@0.1.2, json-stringify-safe@5.0.1, extend@3.0.0, tough-cookie@2.2.1, node-uuid@1.4.7, qs@6.0.2, mime-types@2.1.9, form-data@1.0.0-rc3, combined-stream@1.0.5, aws4@1.2.1, hawk@3.1.3, bl@1.0.1, http-signature@1.1.1, har-validator@2.0.6)
└── execSync@1.0.2 (temp@0.5.1)
Running node 0.12.5
Issue Analytics
- State:
- Created 7 years ago
- Reactions:4
- Comments:14 (2 by maintainers)
Top Results From Across the Web
Lots of warnings when installing · Issue #134 · shelljs/shx
When I do a fresh install, I see tons of install warnings (due to deprecated packages): $ rm -rf node_modules/ $ npm install...
Read more >Angular2 Cli installation problems - node.js - Stack Overflow
Trying to debug it, I tried the minimatch installaton by running sudo npm install -g minimatch@3.0.2 , which gives me this output. minimatch@3.0 ......
Read more >How to Set Up Codecov with C and GitHub Actions in 2022
This tutorial assumes you have gcc installed and set up on your computer. The tool gcov comes bundled with GCC. Writing unit tests....
Read more >@smashwilson/codecov - npm Package Health Analysis | Snyk
Ensure you're using the healthiest npm packages. Snyk scans all the packages in your projects for vulnerabilities and provides automated fix advice.
Read more >node_modules/shelljs/CHANGELOG.md · 4.0.2 · verimag ...
Workaround codecov bug of miscalculation of coverage (#795) #838 (dwi2) ... Add a way to prevent shell-expansion on commands (this issue is not...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I strongly recommend removing execSync.
Would you accept a PR that refactored it out?
I ask because, now that node-tap uses this module as a dependency for sending coverage to codecov, it’s causing a lot of test failures on CI systems, and it appears to me to be a very straightforward refactoring that I’d be happy to help with.
The explicit purpose of this module is to be a part of a CI workflow, so using a dep that fails to build reliably on containers seems like a pretty significant problem. If synchronous exec’ing is a must-have, then I’ll have to switch back to the
codecov.io
module, which appears to be less well supported.