-
Notifications
You must be signed in to change notification settings - Fork 74
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
Build process needs to run twice to produce a working coverage report #111
Comments
Strange, from your travis log I see 2 interesting sections The first time coveralls only analyses one files, the second time it analyses 'a lot'. https://travis-ci.org/GlPortal/RadixEngine/builds/212253813#L506
https://travis-ci.org/GlPortal/RadixEngine/builds/212253813#L715
Very strange. |
Attempted reproduction steps roughly following https://github.com/GlPortal/RadixEngine/blob/master/COMPILE.md
so it seems to be correctly generating coverage report sfor 890 source files after a single run. Are you still able to produce this? if so please provide reproduction steps. |
The test target does not exist so iirc coveralls not running wasn't the problem but it reporting 0% coverage when there is 3% coverage. Variations can be easily tested on a branch and I'll be happy to change the line accordingly: I tried to tackle this problem multiple times and I always had to revert to the run twice method. |
Am I misunderstanding something? I guess I can try find time to setup my own coveralls and travis for a clone of RadixEngine and see what I can get out of it |
So in RadixEngine it looks like:
I've setup travis and coveralls for my clone, will play and around and then report results back, might take a while |
As a side effect of investigating this I noticed an issue in that you have a public .coveralls.yml (only needed for private travis, not needed for open source.) I created an issue on your repo to describe this That should just work as-is unless I am misunderstanding something. |
Okay, I now have coveralls running outside the docker container and I'm able to reproduce the 0% coveralls report on my clone. |
tests and output: Running:
gives 0% coverage
Running:
gives 0% coverage
Running:
gives 0% coverage
Running:
gives 0% coverage
Very strangely, only this last one produced a huge log.
only the last one (running cmake/make/ctest twice, coveralls once) produces the output we expect
but it still seemed to generate a coverage of 0% unless something else went wrong. I think the problem is at least in part due to your make process not producing coverage data the first time it is run, possibly due to cmake not correctly settings that variable you pass in. I'll keep poking around. |
Confirmed that the single build isn't producing the profile data
Log: https://api.travis-ci.org/v3/job/401354549/log.txt output
running just ctest twice
Log: https://api.travis-ci.org/v3/job/401354666/log.txt outputs
running cmake/make/ctest twice
Log: https://api.travis-ci.org/v3/job/401354576/log.txt outputs
So the problem looks to be that your build tooling requires running cmake/make/ctest twice before it produces the gcno and gcda files. Cpp-coveralls doesn't appear to be the problem here. |
So poking around in CMakeFiles/ with grep looking for 'coverage' we get single run of everything
Log: https://api.travis-ci.org/v3/job/401359763/log.txt output
So no gcno, no gcda, and only 2 mentions of 'coverage' running cmake twice
Log: https://api.travis-ci.org/v3/job/401359814/log.txt output
3 mentions of coverage, 54 gcda files, 172 gcno files running 'everything' twice inside docker
Log: https://api.travis-ci.org/v3/job/401359864/log.txt
Again 3 mentions of coverage, 54 gcda, 172 gcno files. |
So at the very least, your cmake config is buggy, as these two commands produce different outputs:
|
I have filed GlPortal/RadixEngine#175 for the cmake config issue |
I'm still seeing a lot of noise in the genereated output, lots of mentions for system included files which will throw your coverage stats way off. |
I have fiddled with support for code coverage for our project GlPortal/RadixEngine#30
However it only started producing proper results after I ran the build process twice
GlPortal/RadixEngine@59a6968
Any idea what the problem is?
Here is a log of the build:
https://travis-ci.org/GlPortal/RadixEngine/builds/212253813
The text was updated successfully, but these errors were encountered: