codecov/feedback

[CLI] Report is marked unusable when duplicate directory exists

Closed this issue · 11 comments

Describe the bug
When uploading coverage reports for a module (core) in our repo while having a duplicate of that module in another directory (release/core), Codecov results declares that report unusable.

Environment:

  • System: CI

To Reproduce
Steps to reproduce the behavior:
Report is marked as “unusable report”
Tried cases in detail:

  1. Upload coverage report for core without the duplicate: Codecov succeeds. (Uploading core without release/core)
  2. Upload coverage report for core with the duplicate missing one file: Codecov succeeds. (Uploading both core and release/core, however removing one file from release/core so that they’re not identical)
  3. Upload coverage report for core with the duplicate: “unusable report”.
  4. Upload coverage report for core with the duplicate and adding an ignore config in codecov.yml as shown below: “unusable report”.

codecov.yml

coverage:
  status:
    project:
      default:
        # basic
        target: auto
        threshold: 0%
ignore:
  - "release"

We have tried many different variations of ignore including:

  • "**/release
  • "**/release/
  • "**/release/**/*
  • "release/**/*
  • "/release/**/*

but none of them seem to actually ignore the “release” directory.

Note: The actual path to the duplicate ‘core’ is “release/{dir1}/{dir2}/{dir3}/{dir4}/{dir5}/{dir6}/{dir7}/core”, however I use “release/core” in this topic for simplicity.

Expected behavior
Report processing succeeds and coverage passes.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
A link to the CI/CD run.
Commit SHA: 3f55bc87446b999f6a5771cc075315c92fa57731

Hello @drazisil-codecov , are there any updates regarding this issue?

Hi @osama-salman99 ,

Can you check if https://docs.codecov.com/docs/the-codecov-cli has the same issue?

Yep, just tried it and it gives the same error - "unusable report"

@osama-salman99

Thanks for confirmation. I believe we are currently preferring the CLI over the uploader, so let me get this tagged and setup so we can review again in our next bug sync meeting.

culprits here are likely one of the two things:

  1. not properly honoring .gitignore (could potentially port this for a fix: codecov/codecov-cli#423)
  2. not traversing contents using git ls-files, so we're picking up files that aren't actually tracked in the repo and being added to the network of the uploaded report.

Possibly something else is happening here, but these are the two scenarios I'd run down first. Will assign for investigation in Sprint 134.

I don't think this issue is related to the CLI. I think the CLI would also behave correctly in this case (it runsgit ls-files when collecting the network), it's actually the path matching on the backend that seems to have been broken here.

I just checked the repo and the consequences seem to be that reports are being processed, but they are only detecting one file.

I would reframe this issue as a path matching issue.

Hi, @osama-salman99

I think using path fixes will help fix this issue.

I think a path fix of ::core/src/main/kotlin/ should fix your specific case

Right now what's happening is that your coverage report refers to part of the files paths for example:

com/expediagroup/sdk/core/configuration/Credentials.kt

In your git repo there are 3 files that exist that Codecov finds can possibly match with this one:

release/rapid/src/main/kotlin/com/expediagroup/sdk/core/configuration/Credentials.kt
core/src/main/kotlin/com/expediagroup/sdk/core/configuration/Credentials.kt
release/fraudPreventionV2/src/main/kotlin/com/expediagroup/sdk/core/configuration/Credentials.kt

because of this Codecov does not know which one to match it with, it ignores all of them.

By applying the path fix, you would turn the file path in your coverage report into:

core/src/main/kotlin/com/expediagroup/sdk/core/configuration/Credentials.kt

which would exactly match with that file in your git repo.

It seems the underlying problem is that the ignore option in the YAML is applied after it's able to match a file from the coverage report to a source file in the repo. cc: @rohan-at-sentry

@osama-salman99 I'm going to mark this as done. If you have any more questions feel free to reopen the issue and ping me.