search

codeclimate / test-reporter

Code Climate Test Reporter
MIT License
156 stars 76 forks source link

Receive an ERR0, when running code coverage on mono-repository #427

Closed awentzel closed 3 years ago

awentzel commented 4 years ago

Everything has been working great on Linux platforms. First running on Circle CI for two years and recently migrated to GitHub Actions using the same script to execute as recommended for Circle CI. GitHub Actions has been working with this same configuration for 8 weeks, until, Jest was updated.

  1. The documentation is limited, and you're depending on a 3rd party Actions provider which has no documentation so no explanation how to use the Action for mono-repositories.
  2. All of a sudden after upgrading Jest related libraries to 25.x, test coverage is failing on not found and appears to be looking in wrong directories all together. I'm not seeing a correlation between Jest or test-reporter so it's a bit strange.
DEBU[0000] coverage path packages/react/fast-components-foundation-react/coverage/lcov.info 
DEBU[0000] using formatter lcov                         
DEBU[0000] checking search path packages/react/fast-components-foundation-react/coverage/lcov.info for lcov formatter 
INFO[0000] trimming with prefix /Users/foo/bar/Projects/fast-dna/ 
DEBU[0000] getting fallback blob_id for source file src/foundation/foundation.ts 
ERRO[0000] failed to read file src/foundation/foundation.ts
open src/foundation/foundation.ts: no such file or directory 
Error: open src/foundation/foundation.ts: no such file or directory
awentzel commented 4 years ago

hi @efueger, I've tried everything in our repository including now trying with a local batch script. I've resolved the errors above by passing in the required Git environment variables, however still get "failed to read file" when executing against a mono repository. To clarify, a mono-repository, includes many packages each which may have its own coverage configureable in package.json.

The only time I have success is when running within the same package. I'm sure this is a pathing issue, and if you recall above, this used to run just fine until Jest v25.

Directory structure each of which holds packages configured with code coverage in the package.json file.

root/packages/react
root/packages/web-components
root/packages/utilities
root/packages/tooling

Questions:

  1. Is it possible to have cc-test-reporter at the root of the project?
  2. if so, should I be able to --output back up to the root/coverage folder?

Further help is necessary as the documentation doesn't cover this scenario.

Thanks,

awentzel commented 4 years ago

Hi @davehenton, you helped me get the first iteration of mono-repository working on Circle CI. We've recently switched to GitHub Actions and having some difficulties getting code reporter to work. Maybe you have some ideas? I've tried what feels like hundreds of different things. I have created a bash script file also to localize and troubleshoot. Any help you can provide would be greatly appreciated. Thanks

wesgur commented 4 years ago

@awentzel I was having the same issue so went in and had a look at the source code. I've made a PR and made an example that worked for me. The binary I am using is built on top of the PR I made. Hope this works for you too! https://github.com/wesgur/cc-test-reporter-monorepo-example/blob/master/.github/workflows/app.yml

efueger commented 4 years ago

Hi @awentzel and @wesgur -

Thanks for reaching out and for the PR! I've just added this to the queue for our dev team to review.

noelia-lencina commented 3 years ago

Hi @wesgur and @awentzel, apologies that it has taken us this long to get to this issue. I'll copy the response I gave @wesgur in his PR here for reference.

The issue you are referencing here has a root cause not in our test reporter, rather than in the tool used in the express project you built as an example. That tool is not following the lcov standard format which is causing this unexpected behavior. You can see more information about this problem here and here. Unfortunately, this is an ongoing issue in that tool, so I'd suggest using another tool or submitting the issue there. The code in this PR, though it fixes the problem for this particular case, is using the --prefix option in the opposite way it's supposed to be used in the rest of the code, which may cause problems for other projects. Besides that, accommodating to a particular tool that has a bug will probably cause more issues.

Let me know if you have questions or comments about this. I'll be closing this issue for now.