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

How to get location of code coverage.dat files? #8217

Closed
codesuki opened this issue May 2, 2019 · 11 comments
Closed

How to get location of code coverage.dat files? #8217

codesuki opened this issue May 2, 2019 · 11 comments
Labels
coverage P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-Server Issues for serverside rules included with Bazel type: support / not a bug (process)

Comments

@codesuki
Copy link

codesuki commented May 2, 2019

We are running codecov through bazel. (not sure this is the best way but seems ok)
Running locally it works:


filegroup(
    name = "coverage_files",
    srcs = glob(["bazel-out/**/coverage.dat"]),
)

codecov(
    name = "codecov",
    runfiles = ["//:coverage_files"],
    token_file = ":codecov.token",
    tags = ["manual"],
)

But on the CI it doesn't work because bazel-out seems not to exist.
Is there any other way to get those files? By a query or rule?
I searched but couldn't find anything useful.
Best idea I have so far is querying for all tests and then build the file paths manually from that. Doesn't seem very neat though.

@jin jin added team-Rules-Server Issues for serverside rules included with Bazel untriaged labels May 2, 2019
@codesuki
Copy link
Author

codesuki commented May 3, 2019

Just noticed a different use case but similar problem.
To run prototool on the protobuf files I made a rule and added dependencies to it like this:

in the proto folders:

filegroup(
    name = "proto_files",
    srcs = glob(["*.proto"]), # works compared to coverage.dat because those are not generated
    visibility = ["//:__pkg__"],
)

in BUILD.bazel

filegroup(
    name = "proto_files",
    srcs = ["//proto/v1:proto_files"],
)

prototool(
    name = "prototool_lint",
    runfiles = ["//:proto_files"],
)

now I have to add the filegroup rule to every subfolder in the /proto tree and also to the /BUILD.bazel.
Is there a better way?

@lberki lberki added P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed untriaged labels May 6, 2019
@lberki lberki added the coverage label May 6, 2019
@dflems
Copy link
Contributor

dflems commented Jul 11, 2019

You could emit a build event protocol file during your test run(s). The coverage files generated during the run should be available in there. Just write a script to parse them out.

@codesuki
Copy link
Author

Thank you :) I'll have a look at that.

@jinfwhuang
Copy link

What would it take for the coverage.dat file to be available as an output file?

@jerrode
Copy link

jerrode commented Aug 19, 2019

Hey @jinfwhuang, Jerrod from Codecov here, interested in supporting Bazel further, but need to know a bit more about the coverage.dat file and what it looks like. Can you send me a link or attach an example .dat file so we can see?

cc: @codesuki

@codesuki
Copy link
Author

@jerrode I made a, somewhat hacky, Bazel rule that works for us. I'll make it available soon. Regarding the example .dat file, do you have an email address where I could contact you?
Just uploading the files worked for a week and suddenly even though the upload script succeeds there are no contents on the codecov dashboard. Maybe you could have a look.

@jerrode
Copy link

jerrode commented Aug 20, 2019

@codesuki thanks! jerrod [at] codecov.io please :)

Interesting the files worked for a week and then stopped working. My initial guess is that the .dat uploaded file is being recognized as a coverage file by Codecov but then not processed (we see similar behavior in unique coverage files from Xcode --> .xccov).

For checking this out, can you tell me the github org / repo in question so I can also investigate our logs?

@jinfwhuang
Copy link

@jerrode @codesuki

I made a simple example in the following. The goal would be able to so to speak, "call test coverage", within a rule's implementation.

https://github.com/jinfwhuang/bazel-examples

@devjgm
Copy link

devjgm commented Sep 16, 2020

@jerrode I'm trying to upload bazel's coverage.dat files to codecov.io now and I see a generic "There was an error processing coverage reports." message. Should I expect codecov.io to work with bazel's coverage.dat files now?

@jerrode
Copy link

jerrode commented Nov 18, 2020

Hey @devjgm, sorry for delayed response:

No, at this time we do not support coverage.dat format. You can see our exhaustive list here.

https://docs.codecov.io/docs/supported-report-formats#exhaustive-acceptable-report-formats

I'd be interested in working with someone from the BazelBuild community to make it happen, though!

Jerrod

@sgowroji sgowroji added the stale Issues or PRs that are stale (no activity for 30 days) label Feb 15, 2023
@sgowroji
Copy link
Member

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

@sgowroji sgowroji closed this as not planned Won't fix, can't repro, duplicate, stale Feb 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
coverage P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-Server Issues for serverside rules included with Bazel type: support / not a bug (process)
Projects
None yet
Development

No branches or pull requests

9 participants