Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CLI] Report is marked unusable when duplicate directory exists #118

Closed
Tracked by #238
osama-salman99 opened this issue Oct 22, 2023 · 11 comments
Closed
Tracked by #238
Assignees
Labels
bug For issues and unexpected behaviors

Comments

@osama-salman99
Copy link

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

@covecod covecod bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 Oct 22, 2023
@thomasrockhu-codecov thomasrockhu-codecov self-assigned this Oct 22, 2023
@thomasrockhu-codecov thomasrockhu-codecov moved this from Waiting for: Product Owner to Waiting for: Support in GitHub Issues with 👀 Oct 22, 2023
@thomasrockhu-codecov thomasrockhu-codecov changed the title Bug Report Report is marked unusable when duplicate directory exists Oct 22, 2023
@drazisil-codecov
Copy link

codecov/codecov-cli#423 May be helpful, @thomasrockhu-codecov

@thomasrockhu-codecov thomasrockhu-codecov removed their assignment Nov 9, 2023
@osama-salman99
Copy link
Author

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

@drazisil-codecov
Copy link

Hi @osama-salman99 ,

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

@drazisil-codecov drazisil-codecov moved this from Waiting for: Support to Waiting for: Community in GitHub Issues with 👀 Jan 17, 2024
@osama-salman99
Copy link
Author

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"

@covecod covecod bot moved this from Waiting for: Community to Waiting for: Product Owner in GitHub Issues with 👀 Jan 18, 2024
@drazisil-codecov drazisil-codecov added the bug For issues and unexpected behaviors label Jan 18, 2024
@drazisil-codecov
Copy link

drazisil-codecov commented Jan 18, 2024

@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.

@drazisil-codecov drazisil-codecov changed the title Report is marked unusable when duplicate directory exists [CLI] Report is marked unusable when duplicate directory exists Jan 18, 2024
@eliatcodecov
Copy link
Contributor

culprits here are likely one of the two things:

  1. not properly honoring .gitignore (could potentially port this for a fix: Honor .gitignore file 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.

@joseph-sentry
Copy link

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.

@joseph-sentry
Copy link

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.

@joseph-sentry
Copy link

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
Copy link
Author

@mohnoor94 @anssari1

@joseph-sentry
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug For issues and unexpected behaviors
Projects
Status: Waiting for: Product Owner
Development

No branches or pull requests

5 participants