Fail to generate coverage and cannot run a report without it.

[amdonov]

Trying to follow the example project you mentioned in issue #1

WORKSPACE

http_archive(
    name = "bazel_sonarqube",
    sha256 = "336b9b9953257d927ba74ff9423f21b4d406be48dfcb7dc9ab21adedbc91709d",
    strip_prefix = "bazel-sonarqube-7b84f80f5d852cab94e8148cbf2255136078e466",
    urls = ["https://github.com/Zetten/bazel-sonarqube/archive/7b84f80f5d852cab94e8148cbf2255136078e466.zip"],
)

load("@bazel_sonarqube//:repositories.bzl", "bazel_sonarqube_repositories")

bazel_sonarqube_repositories()

Added the following ~/.bazelrc

coverage --collect_code_coverage
coverage --combined_report=lcov
coverage --coverage_report_generator=@bazel_sonarqube//:sonarqube_coverage_generator

running bazel coverage //... produces the following error

bazel_sonarqube/BUILD.bazel:16:1: declared output 'external/bazel_sonarqube/coverage.launcher' was not created by genrule. This is probably because the genrule actually didn't create this output, or because the output was a directory and the genrule was run remotely (note that only the contents of declared file outputs are copied from genrules run remotely)

If I try to remove coverage_report from the sonarqube rule, I get the following error

object of type 'NoneType' has no field 'short_path'

It's probably worth mentioning that I get the same thing if targets is removed. However, I was able to set it to an empty list.

[Zetten]

@amdonov Thanks for the report. Which bazel-sonarqube commit are you running with? And what's your build environment - particularly are you using a remote cache or buildfarm/buildbarn? Commit
4f62b4c fixed a caching issue I'd found.

I'll make the coverage_report attribute properly optional to solve the workaround case.

[Zetten]

@amdonov Ok, I've made a couple of fixes for Bazel 2.1.0 compatibility - I don't think this was affecting you, but maybe.

I've also fixed the None check for coverage_report, which hopefully unblocks you while we investigate the report generation issue.

[amdonov]

I tried building the coverage report with the latest commit. Initially, I received the error:
/home/vagrant/.cache/bazel/_bazel_vagrant/3732180162b4a634568314dd07cc3cc8/external/bazel_sonarqube/defs.bzl:122:25: name 'false' is not defined (did you mean 'False'?)
After making that change, it hit the following:

Unable to find package for @bazel_version//:bazel_version.bzl: The repository '@bazel_version' could not be resolved.

Same issue when I tried running the sonarqube target without the coverage report.

I'm running bazel 1.2.1 locally on CentOS 7.

[Zetten]

To capture the Bazel 2.1.0 compatibility issue the dependencies are now mandatory - bazel_skylib and a version visibility hack. Do you have in your WORKSPACE:

load("@bazel_sonarqube//:repositories.bzl", "bazel_sonarqube_repositories")

bazel_sonarqube_repositories()

I've cleaned up the dependency import (in case you already have bazel_skylib) and fixed the typo in master now.

[amdonov]

That was my mistake, I must have dropped those lines from WORKSPACE at some point. I can now run scanning without specifying a coverage report. However, I still unable to get a coverage report to generate successfully. Have you tested it on a golang project? This is the output I'm seeing.

INFO: LCOV coverage report is located at /home/vagrant/.cache/bazel/_bazel_vagrant/3732180162b4a634568314dd07cc3cc8/execroot/ipds/bazel-out/_coverage/_coverage_report.dat and execpath is bazel-out/_coverage/_coverage_report.dat INFO: From CoverageReport _coverage/_coverage_report.dat: Feb 10, 2020 5:51:06 PM com.google.devtools.coverageoutputgenerator.SonarQubeCoverageGenerator getTracefiles INFO: Found 4 tracefiles. Feb 10, 2020 5:51:06 PM com.google.devtools.coverageoutputgenerator.SonarQubeCoverageGenerator parseFiles SEVERE: Parsing file bazel-out/k8-fastbuild/testlogs/audit/templates/go_default_test/coverage.dat Feb 10, 2020 5:51:06 PM com.google.devtools.coverageoutputgenerator.SonarQubeCoverageGenerator parseFiles SEVERE: Parsing file bazel-out/k8-fastbuild/testlogs/audit/api/go_default_test/coverage.dat Feb 10, 2020 5:51:06 PM com.google.devtools.coverageoutputgenerator.SonarQubeCoverageGenerator parseFiles SEVERE: Parsing file bazel-out/k8-fastbuild/testlogs/audit/archive/go_default_test/coverage.dat Feb 10, 2020 5:51:06 PM com.google.devtools.coverageoutputgenerator.SonarQubeCoverageGenerator parseFiles SEVERE: Parsing file bazel-out/k8-fastbuild/testlogs/audit/xml/go_default_test/coverage.dat Feb 10, 2020 5:51:06 PM com.google.devtools.coverageoutputgenerator.SonarQubeCoverageGenerator getGcovInfoFiles INFO: No gcov info file found. Feb 10, 2020 5:51:06 PM com.google.devtools.coverageoutputgenerator.SonarQubeCoverageGenerator getProfdataFileOrNull INFO: No .profdata file found. Feb 10, 2020 5:51:06 PM com.google.devtools.coverageoutputgenerator.SonarQubeCoverageGenerator main WARNING: There was no coverage found. ERROR: output '_coverage/_coverage_report.dat' was not created ERROR: not all outputs were created or valid

The individual test folders are producing coverage.dat files. They're just not be aggregated correctly. Thanks for your help.

[Zetten]

I'm afraid I haven't done any testing with golang projects. That said, I would hope that if bazel's own coverage report is correct, the SQ format conversion will be fine. Then again I think bazel's approach to coverage isn't really final at the moment, so I don't know if there are language-specific oddities.

Have you managed to get the lcov format aggregate coverage report working?

IIRC you can do this with the param --coverage_report_generator=@bazel_tools//tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator:Main. If you take the resulting combined .dat file into an empty directory you should be able to run genhtml ./_coverage_report.dat (usually comes with lcov) and get a nice HTML report. If that all looks good, then there must be something wrong with the SQ conversion...

[prashilgupta]

@amdonov Did you get it working? I am trying with golang project and seeing lot of issues

[amdonov]

Nope

…

On Thu, Feb 4, 2021 at 10:36 AM Prashil Gupta ***@***.***> wrote: @amdonov <https://github.com/amdonov> Did you get it working? I am trying with golang project and seeing lot of issues — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOCFGS4NDO5XUT6FTMMUDS5K5JNANCNFSM4KQQURXQ> .

[Zetten]

Hi @amdonov, @prashilgupta, in a recent commit I updated the coverage collector to copy the latest changes from the upstream lcov coverage aggregator. Maybe this has had some effect on your issues?

Since there were some changes upstream, I'd just like to re-verify: if you use the default lcov aggregator, do you definitely get a properly aggregated coverage report?

I do really want to figure out if there's an issue here, so we need to pin down whether the issue is in "Bazel's coverage collection" or "bazel_sonarqube's coverage aggregation". Cutting this library out of the loop and checking the built in tooling will help there.

The reason I ask is that one problem we found in #12 was a misconfigured java toolchain which was not actually generating coverage in the individual coverage.dat files (let alone the aggregation). The files appeared, but were empty - and when the coverage report generator ran the overall _coverage_report.dat was similarly an empty file. This would have been an issue even without using bazel_sonarqube!

[prashilgupta]

I used the following command and yes bazel command itself doesnt merge all coverage file into one dat for golang. But my issue was that I wasn't able to successfully use the sonarqube module with such wildcard target

bazel coverage --combined_report=lcov --runs_per_test=1 --flaky_test_attempts=1 -- //... -//<exclude_target>

[pvcnt]

Hello, I am hitting the exact same error with the latest commit from master and Bazel 4.0.0. I noticed that coverage-launcher is generated at the root of the output tree (it's a sibling for bazel-out, _tmp, _coverage, etc.) and is a broken link:

$ ls -lh bazel-myproject/coverage.launcher
lrwxr-xr-x  1 myuser  wheel    61B 14 Feb 15:58 bazel-myproject/coverage.launcher -> bazel-out/host/bin/external/bazel_sonarqube/coverage.launcher
$ ls -lh bazel-myproject/bazel-out/host/bin/external/bazel_sonarqube
total 176
-r-xr-xr-x  1 myuser  wheel    12K 14 Feb 15:53 SonarQubeCoverageGenerator
-r-xr-xr-x  1 myuser  wheel   284B 14 Feb 15:57 SonarQubeCoverageGenerator-native-header.jar
-r-xr-xr-x  1 myuser  wheel    11K 14 Feb 15:57 SonarQubeCoverageGenerator.jar
-rw-r--r--  1 myuser  wheel   1.1K 14 Feb 15:57 SonarQubeCoverageGenerator.jar-0.params
-rw-r--r--  1 myuser  wheel   170B 14 Feb 15:57 SonarQubeCoverageGenerator.jar-1.params
-r-xr-xr-x  1 myuser  wheel   396B 14 Feb 15:57 SonarQubeCoverageGenerator.jar_manifest_proto
-r-xr-xr-x  1 myuser  wheel   213B 14 Feb 15:57 SonarQubeCoverageGenerator.jdeps
drwxr-xr-x  7 myuser  wheel   224B 14 Feb 15:53 SonarQubeCoverageGenerator.runfiles
-r-xr-xr-x  1 myuser  wheel    38K 14 Feb 15:53 SonarQubeCoverageGenerator.runfiles_manifest
drwxr-xr-x  3 myuser  wheel    96B 14 Feb 15:53 _javac

It works if I use --coverage_report_generator=@bazel_sonarqube//:SonarQubeCoverageGenerator.