Depreciating Soon Please see https://github.com/codecov/codecov-node Thank you!
Codecov.io support for node.js. Get the great coverage reporting of codecov.io and add a cool coverage button ( like the one above ) to your README.
Add the latest version of codecov.io
to your package.json:
npm install codecov.io --save
This script ( bin/codecov.io.js
) can take standard input from any tool that emits the lcov, gcov or standardized json data format and send it to codecov.io to report your code coverage there.
Once your app is instrumented for coverage, and building, you need to pipe the coverage reports output to ./node_modules/codecov.io/bin/codecov.io.js
.
This library currently supports the following CI companies: Travis CI, Appveyor, CircleCI, Codeship, Drone, Jenkins, Shippable, Semaphore, Wercker.
Jenkins, Travis CI, Codeship, Circle CI, Semaphore, drone.io, AppVeyor, Wercker, Magnum, Shippable, and Gitlab CI. Otherwise fallbacks on git
.
Repo tokens are not required for public repos tested on Travis, CircleCI or AppVeyor.
Repo tokens are neccessary to distinquish your repository from others. You can find your repo token on your repository page at Codecov. Set this unique uuid to CODECOV_TOKEN
in your environment variables.
export CODECOV_TOKEN=":uuid-repo-token"
With Mocha:
istanbul cover ./node_modules/mocha/bin/_mocha -- -R spec && cat ./coverage/lcov.info | ./node_modules/.bin/codecov
With Jasmine:
istanbul cover jasmine-node --captureExceptions spec/ && cat ./coverage/lcov.info | ./node_modules/.bin/codecov
With Tape:
istanbul cover test.js && cat ./coverage/lcov.info | ./node_modules/.bin/codecov
Codecov does support partial line coverage. However, some node projects do not report partial coverage accurate enough.
You can decide to upload the partial coverage report by chaning the target upload file to ./coverage/coverage.json
.
View your report on Codecov, if the reports are not accurate then switch back to the lcov
provided above.
We are working on improving this implementation and appreciate your patience.
I generally don't accept pull requests that are untested, or break the build, because I'd like to keep the quality high (this is a coverage tool afterall!).
I also don't care for "soft-versioning" or "optimistic versioning" (dependencies that have ^, x, > in them, or anything other than numbers and dots). There have been too many problems with bad semantic versioning in dependencies, and I'd rather have a solid library than a bleeding edge one.