--keep seems broken

[misery]

We want to use SonarQube with Code Coverage report. We already uses gcovr with jenkins which works flawlessly (thanks!!!). As sonarqube uses gcov files directly we tried "--keep" of gcovr to avoid complex excludes which are already defined in gcovr cmdline. But it looks like gcovr will delete any .gcov files even we add "--keep".

Also it seems it writes it to /tmp/tmp****/. It would be great if non-excluded gcov files could be re-used by other programs.

See: https://docs.sonarqube.org/display/PLUG/SonarCFamily+Coverage+Results+Import

[latk]

oops, this is a regression (more or less).

When gcovr runs gcov, it generates .gcov files in your build directory. This will necessarily overwrite any existing gcov files in your directory structure. As part of multithreading support (-j), we parse the gcov output to find the filenames and move them to a tempdir, so that the next gcov invocation can run before the .gcov files have been parsed. There will be at least one gcov run per object file (and possibly more, because gcovr has to guess the correct starting directory).

With --keep, gcovr should move the files back from the tempdir into the build directory, but this will be a “last one wins” situation as there will be one .gcov file per source file per compilation unit. Especially headers are present in multiple compilation units. I'm therefore not sure whether your plan to feed these files to SonarQube will work.

I'm torn between updating the docs for --keep that it should only be used in conjunction with --use-gcov-files, or re-instating the previous behaviour which is likely buggy (as in: coverage will be lost). A third option would be to write a reporter that outputs .gcov files with summarized coverage (similar to our HTML reports). But that seems fairly insane and I don't have the time. (But if anyone would be offering to do that work … hint, hint.)

Anyway, thanks for this report. I'll think more about it but I don't think I'll be able to fix it soonishly.

[misery]

Thanks! Since we use cmake I switched to test_coverage_collect_gcov and tweaked it a little bit for SonarQube.

The idea was to just move /tmp/* stuff to $localBuildDir/tmp_gcov/*. So it could still be in parallel. But of course... maybe SonarQube don't allow multiple .gcov files for the same file.

[latk]

I'm glad you found a solution that works for you. I took a quick look at CMake's test_coverage_collect_gcov function, and it seems to suffer from the gcov file name collision issue I discussed in the previous comment. So you might not get correct coverage data for header files. It seems there might be a use case for properly merged gcov files. If you or your company would be willing to contribute a rudimentary gcov file writer that would be most welcome. I recently added a simplified internal data model that should be easy to work with. Alternatively, SonarQube seems to support a simple generic XML coverage format [1], which would be very easy for me to implement. If you are willing to run development versions of gcovr to test the new format, I can do the work in the coming week. [1]: https://docs.sonarqube.org/display/SONAR/Generic+Test+Data

…

On Fri, 19 Oct 2018 at 12:22, André Klitzing ***@***.***> wrote: Thanks! Since we use cmake I switched to test_coverage_collect_gcov and tweaked it a little bit for SonarQube. The idea was to just move /tmp/* stuff to $localBuildDir/tmp_gcov/*. So it could be still be in parallel. But of course... maybe SonarQube don't allow multiple .gcov files for the same file. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#285 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABs0j4oge-G99rpINK4ANV-ukw3RZcuDks5umafggaJpZM4XTf4Q> .

[misery]

Thanks for your answer.

I don't have time to contribute in the near future even I really would do that. But yes, I can try the generic test data here with a developer version. There is no problem to add this.

Well, that should explain why Jenkins says 59 % coverage and Sonar says 52 % coverage.

[misery]

Any progress here? Can I test something? :-)

[latk]

I'm sorry you have been waiting for months, but so far there is no progress. Please understand that while I try to be responsive around administrative and support issues (like triaging issues and reviewing PRs), at the moment any work on gcovr is just a hobby and will happen if and when it happens.

[misery]

Looks like my sonarqube problem is fixed by #308

[pepsiman]

gcov has a -l option to avoid the last one wins problem with header files.
I don't know whether Sonarqube would handle multiple .gcov files for the same header.

[Spacetown]

Closed because sonarqube.xml can be generated since #308