Java-coverage: Add logic to exclude dependencies in JVM coverage report #10860
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
arthurscchan
force-pushed
the
fix-jvm-coverage
branch
2 times, most recently
from
880cf34
to
22108da
Compare
DavidKorczynski
requested changes
Aug 21, 2023
arthurscchan
force-pushed
the
fix-jvm-coverage
branch
3 times, most recently
from
63e07c3
to
9e61819
Compare
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
arthurscchan
force-pushed
the
fix-jvm-coverage
branch
from
7dfed98
to
39d59c8
Compare
|
I'll review this tomorrow! |
|
It is found that it maybe better to do this per project by separating the dependencies jar and project code jar to avoid Jacoco generating the reports for those dependencies jar. Currnetly, Jacoco only generate reports on all jar existing in the $OUT directory. Putting dependencies in inner directory like $OUT/dependency will exclude them from Jacoco report which is an alternatives. Thus closing this PR. |
centic9
added a commit
to centic9/oss-fuzz
that referenced
this pull request
Dec 29, 2023
…included in coverage report Introduce two jar-files to separate .class files into two jar files, one which is included in coverage reporting and one which contains libraries which should not appear in the coverage report. Unfortunately this only allows control on "artifact" level, which means single uninteresting classes/packages cannot be excluded. Related to google#10826 and google#10860 (cherry picked from commit 2b48e656646d4c3aa61ea44b5b3edef59942f142)
DavidKorczynski
pushed a commit
that referenced
this pull request
Dec 29, 2023
…eptions (#11418) As a general solution for handling excluding classes from JaCoCo coverage counting was not merged (See #10860#issuecomment-1870891873 ), this PR tries to implement a different approach which separates the class-files into two jar-files and this way at least allows to exclude code of third-party libraries when reporting coverage of fuzzing. Also add two expected exceptions and adjust one limit to match the amount of memory which oss-fuzz uses here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR resolves #10826 by using the COVERAGE_EXTRA_ARGS from project.yaml or helper.py script to retrieve a TARGET_PACKAGE_PREFIX list to specify what class packages to be included in the Jacoco HTML report for JVM projects.
Sample result for project Joni before the PR
Sample result after the PR is applied
The additional field added to project.yaml
coverage_extra_args: TARGET_PACKAGE_PREFIX=org.joni.*