Codecov no longer merges multiple reports correctly

Hi there

Since today, Codecov only respects one of my reports. Till yesterday, both reports have always been respected and merged automatically.

As you can see, in my repository,

with the latest commit made yesterday, https://github.com/ContextMapper/context-mapper-dsl/commit/5add2071d52d8e86a3207c0e1195e0cd671026c5, both projects (org.contextmapper.dsl.ide as well as org.contextmapper.dsl) were respected: https://codecov.io/gh/ContextMapper/context-mapper-dsl/tree/5add2071d52d8e86a3207c0e1195e0cd671026c5.

Today, I created an empty commit (to trigger this issue) https://github.com/ContextMapper/context-mapper-dsl/commit/553fffc7f83230db700643a03cbf7b6c8431fe2f, and the report of project org.contextmapper.dsl.ide is just ignored now: https://codecov.io/gh/ContextMapper/context-mapper-dsl/tree/553fffc7f83230db700643a03cbf7b6c8431fe2f. Without changing anything.

According to the log of Travis, both reports were found:

==> Reading reports

+ ./org.[secure].dsl.tests/build/reports/jacoco/test/jacocoTestReport.xml bytes=5449843

+ ./org.[secure].dsl.ide.tests/build/reports/jacoco/test/jacocoTestReport.xml bytes=5196078

It looks to me that both reports are detected, uploaded, but only one is finally processed.
Would be nice if this could be fixed, as it decreases my test coverage now and I can no longer control the test coverage of one of the projects.

Thanks and best regards,
Stefan

I have something very similar (or maybe the exact same issue) on my private project, using maven + github actions: although multiple jacoco reports are submitted simultaneously in one upload, only the first one seems to be processed

Sounds like exactly the same issue.

I hope Codecov fixes this issue or presents a workaround quickly. Because this one of the kind of issues where you can wait a few days and then have to look for another tool if it is not fixed :frowning:

The tool got completely useless for me today.

@stefan-ka, this looks like a Travis issue. If you look at the build logs on Travis, you’ll see that this build does not have a Codecov step run, while the other build does.

I have no idea why this is now coming to be, but I would guess that you need to add another after_success section to the first script section here

@laurentgo, please feel free to open another issue in the channel as I’ll need similar details to debug.

As it is a private project, what should I report for codecov to be able to diagnose the issue?

@laurentgo, you’ll find a template that requests the most common information we need when you open a new issue. Please do make sure that you check the above solution (are all the builds you expect to be sending coverage reports actually doing so).

Thanks @tom for looking into this, but unfortunately your analysis is not correct. I admit it might be confusing that I have two scripts in Travis. But this has nothing to do with the first one. Both my test coverage reports are generated by the second build script.

As you can see in the log, the second build in fact has a Codecov run step: https://travis-ci.com/github/ContextMapper/context-mapper-dsl/jobs/388981884
And as you can also see in this Codecov run step: there are two reports found by Codecov. They are both there and found by your script. But in the end only one of them is processed.

I really cannot understand why this should have anything to do with Travis.

Hello,

I see the same behavior with Github Actions. For the last few days, it only considers the first report. The project is https://smallrye.io/smallrye-mutiny/.

2020-09-22T20:37:36.1608090Z e[0;90m==>e[0m GitHub Actions detected.
2020-09-22T20:37:36.1708461Z     e[0;90mproject root:e[0m .
2020-09-22T20:37:36.1830957Z     e[0;90mYaml found at:e[0m .github/codecov.yml
   ....
 2020-09-22T20:37:36.3739350Z     e[0;90m->e[0m Found 6 reports <- so far so good
  ....    

However, the analysis only considers the first report and ignore the 5 other reports.

Hi @stefan-ka and @cescoffier, we had an issue here. Would you be able to see if this is still happening?

Hello @tom. I can confirm, the issue is gone on our side! Thanks!

1 Like

Yes, @tom. Works again…

1 Like