-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Allow Java coverage collection for external targets #16268
Conversation
* Removes a hardcoded filters that result in the LCOV merger filtering out coverage of external targets even if these are matched by `--instrumentation_filter`. * Lets `LazyWritePathsFileAction` write out exec rather than root-relative paths, as advertised by its javadocs, so that the paths match those that the LCOV mergers filters by.
29fd88f
to
7f7d616
Compare
@c-mita Friendly ping |
@bazel-io flag |
Hello @c-mita, As I could see we are good to merge the PR, does it require any further review? Thanks! |
@bazel-io fork 6.0.0 |
Just forgot to update the labels. |
* Removes a hardcoded filter that results in the LCOV merger filtering out coverage of external targets even if these are matched by `--instrumentation_filter`. * Lets `LazyWritePathsFileAction` write out exec rather than root-relative paths, as advertised by its javadocs, so that the paths match those that the LCOV mergers filters by. Work towards bazelbuild#16228 Work towards bazelbuild#16208 Closes bazelbuild#16268. PiperOrigin-RevId: 485580267 Change-Id: I830d3cf903462ca1799ef5f659a620dbdb92f349
* Removes a hardcoded filter that results in the LCOV merger filtering out coverage of external targets even if these are matched by `--instrumentation_filter`. * Lets `LazyWritePathsFileAction` write out exec rather than root-relative paths, as advertised by its javadocs, so that the paths match those that the LCOV mergers filters by. Work towards #16228 Work towards #16208 Closes #16268. PiperOrigin-RevId: 485580267 Change-Id: I830d3cf903462ca1799ef5f659a620dbdb92f349
merged in #16637 |
@kshyanashree Unfortunately, this PR was rolled back in 4caae75 at HEAD, can you please also cherry pick the rollback of this change? |
@bazel-io fork 6.0.0 |
Sure @meteorcloudy! I will do that. |
@meteorcloudy @susinmotion Is there any more context on the nature of the breakage this causes your could provide me with? |
Unfortunately not at the moment; we're not really sure why there's a failure. It might just be a bad test, but unfortunately we won't not be in a position to investigate in detail until after BazelCon. |
@c-mita Friendly ping, did you get a chance to investigate the failure? If you can share details about the failing test, I can also look into it. |
An internal rule also makes use of I would guess this PR would also have to change this, but it's probably best I handle it on our side. |
Thanks for looking into it. Let me know if I can help with the roll-forward, but I agree its probably easier if you do it and fix the rule usage in the same CL. I can't reopen the current PR, but feel free to use it for that. |
My guess was wrong; there's simply another lump of internal code that assumes these written to the file are root-relative. Interestingly, when consuming this file, it then appears to stick the exec path in front, so I think it could be simplified and this PR could be accepted as is afterwards, but making the required change is not proving straightforward. |
A roll-forward of #16268. LazyWritePathsFileAction has been changed to accept a custom converter parameter that can be used to specify exactly what path should be written out to the file. This is required to support the use case of an internal rule that still needs root-relative paths written out. The default case (when no converter is specified) is to output the exec path, as per the original PR. PiperOrigin-RevId: 505678128 Change-Id: Ib1d8547dcb359a9e0fb7e462850424ec4218f7fb
It seems the internal rule really does require the old behaviour to preserved. As a compromise, I've adjusted 00e9af1 is the "roll-forward" with this change. |
A roll-forward of bazelbuild#16268. LazyWritePathsFileAction has been changed to accept a custom converter parameter that can be used to specify exactly what path should be written out to the file. This is required to support the use case of an internal rule that still needs root-relative paths written out. The default case (when no converter is specified) is to output the exec path, as per the original PR. PiperOrigin-RevId: 505678128 Change-Id: Ib1d8547dcb359a9e0fb7e462850424ec4218f7fb
A roll-forward of #16268. LazyWritePathsFileAction has been changed to accept a custom converter parameter that can be used to specify exactly what path should be written out to the file. This is required to support the use case of an internal rule that still needs root-relative paths written out. The default case (when no converter is specified) is to output the exec path, as per the original PR. PiperOrigin-RevId: 505678128 Change-Id: Ib1d8547dcb359a9e0fb7e462850424ec4218f7fb Co-authored-by: Googler <cmita@google.com>
A roll-forward of #16268. LazyWritePathsFileAction has been changed to accept a custom converter parameter that can be used to specify exactly what path should be written out to the file. This is required to support the use case of an internal rule that still needs root-relative paths written out. The default case (when no converter is specified) is to output the exec path, as per the original PR. PiperOrigin-RevId: 505678128 Change-Id: Ib1d8547dcb359a9e0fb7e462850424ec4218f7fb
out coverage of external targets even if these are matched by
--instrumentation_filter
.LazyWritePathsFileAction
write out exec rather thanroot-relative paths, as advertised by its javadocs, so that the paths
match those that the LCOV mergers filters by.
Work towards #16228
Work towards #16208