Bug: Jest and TravisCI "X Failed to read file at"

[KL13NT]

Describe the bug
Running codecov from TravisCI yields X Failed to read file at when locating files even when coverage folder exists in the same level. Works when passing -f ./coverage/clover.xml though.

I tried pwd before running codecov and apparently travis cds into the project folder, meaning that running codecov should allow it to easily locate coverage using relative paths such as ./coverage without having to pass it manually.

To Reproduce
Steps to reproduce the behavior:

1. Configure travis to run jest to output coverage to coverage folder
2. Set after_success to codecov

Expected behavior
Should easily locate coverage reports when available relative to project root.

Screenshots
Failing build: Travis Failing Build Report
Passing build: Travis Passing Build Report

Additional context
Full passing .travis.yml configuration (remove -f ./coverage/clover.xml to make it fail):

language: node_js
node_js:
  - '12.16.0'
scripts:
  - npm install -g codecov
  - npm run build
before_deploy:
  - if [ "$TRAVIS_BRANCH" = "development" ]; then npm run alpha; fi
  - if [ "$TRAVIS_BRANCH" = "master" ]; then npm run release; fi
cache:
  directories:
    - node_modules
deploy:
  provider: npm
  cleaup: false
  skip_cleanup: true
  on:
    tags: true
branches:
  only:
    - master
    - development
after_success:
  - codecov -f ./coverage/clover.xml # remove -f ./coverage/clover.xml to make it fail

Full jest.config.js configuration:

module.exports = {
	testEnvironment: 'node',
	setupFilesAfterEnv: ['jest-extended'],
	coverageDirectory: './coverage',
	collectCoverage: true
};

[KL13NT]

I'm open to work on this if it's fixable with a PR, just point me in the right direction (e.g. what to modify).

[uatuko]

Could this be related to a recent release where automatic detection has been changed (or broken)? We've been using npx codecov -t <token> to upload coverage reports but seems to have stopped working today.

We have coverage.lcov generated using nyc and even running this locally gave me the error saying X Failed to read file at.

[adnanaylan]

I have the same problem. Also running codecov locally is giving me X Failed to read file at error even though coverage directory and necessary files exist.

[KL13NT]

For me running it locally runs flawlessly. Seems to recognise the folders without a problem. I'm on Win8.1

[adnanaylan]

For me running it locally runs flawlessly. Seems to recognise the folders without a problem. I'm on Win8.1

I just passed -f ./coverage/clover.xml as you said in the above post and it worked both on local and Travis. BTW, I'm on Ubuntu 20.04.

[yhatt]

I also have met the same in CircleCI. It's getting back to normal behavior by downgrading to v3.7.0, so probably there are any breaks in the latest v3.7.1. v3.7.0...v3.7.1

[julien-amblard]

Hello, I have the same problem here but with circleci
This is weird because I have the same problem even when I try reruning any previous successfull workflow... or on another project I haven't changed since months.
I'm not sur if it's circleci or codecode issue.

@yhatt

I also have met the same in CircleCI. It's getting back to normal behavior by downgrading to v3.7.0, so probably there are any breaks in the latest v3.7.1. v3.7.0...v3.7.1

I've try rollback on a previous version but still have the issue

[the0neWhoKnocks]

Pinning to v3.7.0 in Travis worked for me as well.

I'm curious why, if no reports were found (or there were errors during the scan), why it seemingly proceeded with the upload.

==> Scanning for reports
    X Failed to read file at 
==> Uploading reports
    Success!
    View report at: <URL>

[julien-amblard]

Pinning to v3.7.0 in Travis worked for me as well.

I'm curious why, if no reports were found (or there were errors during the scan), why it seemingly proceeded with the upload.

The report seems to exists, I succeffully uploaded it in circleci artifact on the same workflow, but codecov failled

[yhatt]

I think removing brackets \\( and \\) from find's arguments was causing the change of search condition for coverage files on UNIX environment.

UPDATE: This change seems to make no effects to the reported error X Failed to read file at.

[the0neWhoKnocks]

To @yhatt 's point, for future clarity, perhaps that code should be refactored to:

patterns = (
    "-type f \\(" +
        "-name '*coverage.*' " +
        "-or -name 'nosetests.xml' " +
        "-or -name 'jacoco*.xml' " +
        "-or -name 'clover.xml' " +
        "-or -name 'report.xml' " +
        "-or -name 'cobertura.xml' " +
        "-or -name 'luacov.report.out' " +
        "-or -name 'lcov.info' " +
        "-or -name '*.lcov' " +
        "-or -name 'gcov.info' " +
        "-or -name '*.gcov' " +
        "-or -name '*.lst'" +
    "\\) " +
    "-not -name '*.sh' " +

And the commented out test in bb79335#diff-0fd0e07cf6d02bf7cf00f18cebb8e6eaL109 could be refactored to try parsing the list of file types from patterns

[KL13NT]

I won't be able to test v3.7.0 myself but it seems an issue with the pattern indeed. As stated, it's perfectly able to locate the coverage files on my local Windows machine but fails on Travis' Ubuntu Xenial 16.04 default environment. And it does upload said failed reports for no reason. Is this by design?

[the0neWhoKnocks]

In relation to my first comment

I'm curious why, if no reports were found (or there were errors during the scan), why it seemingly proceeded with the upload.

It looks like there's been a PR open since August of last year that seemingly would address the issue https://github.com/codecov/codecov-node/pull/144/files.

[yhatt]

CVE-2020-15123 security advisory has been published, affects to < v3.7.1. Pinning 3.7.0 is a workaround for failing to read coverage files but may make to allow command injection attack.

Probably the most safe workaround is using v3.7.1 with -f, to specify coverage files for uploading manually.

[the0neWhoKnocks]

Using the -f with 3.7.1 did not fully work for me in Travis. It did upload the report, but CodeCov is stuck in a Processing state, and the build status in GitHub never updates.

[yhatt]

codecov-node/lib/codecov.js

Line 493 in 29dd5b6

_files = execFileSync('find', _findArgs)

I've found out _files always got empty in the current find conditions.

In v3.7.1, ' in arguments of find is recognized as the part of filename for the search condition, because find command is no longer running on the shell environment by changing from execSync() to execFileSync(). It would be recovered by just removing quotes.

[josepot]

Works when passing -f ./coverage/clover.xml though.

I also got hit by this issue. In my case passing the option -f ./coverage/clover.xml was giving me really weird/wrong reports. What worked for me was to pass the lcov.info file instead, like this:

codecov --disable=gcov -f ./coverage/lcov.info

[julien-amblard]

Works when passing -f ./coverage/clover.xml though.

I also got hit by this issue. In my case passing the option -f ./coverage/clover.xml was giving me really weird/wrong reports. What worked for me was to pass the lcov.info file instead, like this:

codecov --disable=gcov -f ./coverage/lcov.info

Works for me ! Thanks @josepot
I still keep an eye on @yhatt PR #185

[the0neWhoKnocks]

@josepot that's pretty much exactly what I had in Travis, but the reports were stuck as Processing in CodeCov, and GitHub wasn't getting the build status anymore.

[josepot]

@josepot that's pretty much exactly what I had in Travis, but the reports were stuck as Processing in CodeCov, and GitHub wasn't getting the build status anymore.

I got the exact same problem... Then I thought:

What if I've been over-stressing codecov? I'm going to give this thing a rest...

and a few hours later the codecov "in progress" reports had finished and after that things started working fine again 🤷 My guess is that at some point they decided to kill all the stale "in progress" stuff, but I have no idea I'm just guessing.

[yhatt]

I think it was affected by degraded Codecov web in separately from codecov-node.
https://status.codecov.io/incidents/wmhy3b01nvdg

I hope to notice Codecov to this problem after that regression calmed down. 🥺

[thomasrockhu]

Hi everyone and sorry for the delay here. We really appreciate all the conversation, and we are investigating the outage. Thanks @yhatt for this PR. If it looks good, we'll merge and push a new version 3.7.2

[thomasrockhu]

Hi all, we just pushed 3.7.2, let me know if that fixes the issue, and I'll close this out.

[yhatt]

@thomasrockhu Thank you for taking care of pull request. In my related project, I've confirmed v3.7.2 is getting back it can find out coverage files at CI environment correctly.

Outputs in v3.7.1...

$ yarn run codecov

yarn run v1.22.4
$ /home/circleci/jsx-slack/node_modules/.bin/codecov
  _____          _  
 / ____|        | |  
| |     ___   __| | ___  ___ _____   __  
| |    / _ \ / _` |/ _ \/ __/ _ \ \ / /  
| |___| (_) | (_| |  __/ (_| (_) \ V /  
 \_____\___/ \__,_|\___|\___\___/ \_/  
                                v3.7.1
==> Detecting CI Provider
    Circle CI Detected
==> Configuration: 
    Endpoint: https://codecov.io
{
  commit: '3b9c444cfc47b48a6213284d86a11677316aed2b',
  branch: 'upgrade-dependencies',
  package: 'node-v3.7.1'
}
==> Building file structure
==> Generating gcov reports (skip via --disable=gcov)
    Failed to run gcov command.
==> Scanning for reports
    X Failed to read file at 
==> Uploading reports
    Success!
    View report at: https://codecov.io/github/speee/jsx-slack/commit/3b9c444cfc47b48a6213284d86a11677316aed2b
Done in 0.95s.

Outputs in v3.7.2...

$ yarn run codecov

yarn run v1.22.4
$ /home/circleci/jsx-slack/node_modules/.bin/codecov
  _____          _  
 / ____|        | |  
| |     ___   __| | ___  ___ _____   __  
| |    / _ \ / _` |/ _ \/ __/ _ \ \ / /  
| |___| (_) | (_| |  __/ (_| (_) \ V /  
 \_____\___/ \__,_|\___|\___\___/ \_/  
                                v3.7.2
==> Detecting CI Provider
    Circle CI Detected
==> Configuration: 
    Endpoint: https://codecov.io
{
  commit: '5a24cccbdfed600f23381fda005fad026bad3c43',
  branch: 'upgrade-dependencies',
  package: 'node-v3.7.2'
}
==> Building file structure
==> Generating gcov reports (skip via --disable=gcov)
    Failed to run gcov command.
==> Scanning for reports
    + /home/circleci/jsx-slack/coverage/lcov.info
    + /home/circleci/jsx-slack/coverage/clover.xml
==> Uploading reports
    Success!
    View report at: https://codecov.io/github/speee/jsx-slack/commit/5a24cccbdfed600f23381fda005fad026bad3c43
Done in 0.92s.

[alexkli]

Had the same issue on Travis CI with 3.7.1 not finding and uploading reports. (We only got 3.7.1 yesterday/today since dependabot pushed it as security vulnerability fix). Can confirm that 3.7.2 fixed it!

[julien-amblard]

@thomasrockhu 3.7.2 fixed it on circleci, thanks you !

[thomasrockhu]

Looks like this has been resolved, thanks everyone!