-
Notifications
You must be signed in to change notification settings - Fork 47
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
Coverage minima: add more fine-grained control #55
Conversation
44ab980
to
b61c01c
Compare
@gslowikowski friendly reminder to review. |
@gslowikowski are you interested in pursuing this still? |
Yes, I am. I didn't have enough time, when you created your pulls. I've created some simple test projects to compare SCoverage with Cobertura and Jacoco for similar syntax constructs and it looks very different. I wasn't sure if SCoverage properly reports overall coverage. Now I will try to find time and return to this problem. I will publish my test projects, and we will see if something in current code base should be changed before merging your pulls, or not. |
@ckipp01 rebased |
Hey @kitbellew |
and them what will happen? |
I can review and if all is good merge and release it. |
@jozic ah, no problem, will do. (did it once before, and nothing happened subsequently, hence my question.) |
@jozic сделано. |
thanks @kitbellew |
done. |
@jozic it might be easier to review one commit at a time, they are structured logically. |
dfd41a6
to
85c5796
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks very nice, left some questions/suggestions
@@ -547,6 +551,32 @@ else if ( !module.getPackaging().equals( "pom" ) ) | |||
getLog().info( "Coverage aggregated reports completed." ); | |||
} | |||
|
|||
private MavenProject findAncestorModuleWithShortestBasedir() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like this is not really related to minimums we can set, right?
seems like it's similar to #104
could you please clarify why we need this here? Can we extract that to a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, correct. the code is what we used in our production for many years, and it's likely that there were two unrelated changes to make everything work. will remove from this pr (and the linked one might be a better implementation).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a heads-up, i've merged #104, so dropping this particular change should be safe now.
{ | ||
if ( !checkCoverage( getLog(), "Package:" + pkgCoverage.name(), pkgCoverage, | ||
minimumCoverageStmtPerPackage, minimumCoverageBranchPerPackage, false ) ) | ||
ok = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like this will continue even after after first false
should we instead use something like
CollectionConverters.asJava( coverage.packages() ).stream().allMatch
?
or do you want it to run for each package no matter what?
same question for files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good question. we can either report until first failure (in which case the user would fix something and then find out there's more), or report everything. options:
- report everything
- report only first failure
- put the choice under yet another parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally generate a report on a failure, to see what's not covered. So the first failure seems fine to me.
But I can also see a point of having all the packages/files checked at once.
How about we do fail-fast in this PR and then we can do a separate PR to add an extra flag, like failFast
with true
by default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jozic good morning and happy new year.
i finally got around to working on this, and here's what i realized: we will have reporting on all packages and files if it's successful but will stop at the first error if it happens (with a single [ERROR] message after possibly a bunch of [INFO]/[DEBUG]). which is a bit weird since the opposite is probably of more interest.
so, i see several alternatives:
- report everything, just like now
- report everything, except use [DEBUG] for second and subsequent errors
- collect all info/debug messages until the first error; if there are no errors, only then log the info/debug.
thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kitbellew, happy New Year to you as well!
Good point, i guess reporting packages and files as debug for success and error for failure is a fair game. So we should probably leave it as you have it )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jozic all done and pushed.
private static boolean checkCoverage( Log logger, String metric, CoverageMetrics metrics, | ||
double minimumStmt, double minimimBranch, boolean logSuccessInfo ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo minimumBranch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do
if ( is100( minimum ) && is100( actual ) ) | ||
{ | ||
logSuccess( logger, String.format( "Coverage is 100%: %s!", metric ), logSuccessInfo ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
logSuccess( logger, String.format( "Coverage is 100%: %s!", metric ), logSuccessInfo ); | |
logSuccess( logger, String.format( "Coverage is 100%%: %s!", metric ), logSuccessInfo ); |
otherwise it fails with java.util.UnknownFormatConversionException: Conversion = ':'
would be nice to add module3 to your awesome tests checking this branch )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do
|
||
boolean ok = checkCoverage( getLog(), "Total", coverage, | ||
minimumCoverage, minimumCoverageBranchTotal, true ); | ||
for ( MeasuredPackage pkgCoverage : CollectionConverters.asJava( coverage.packages() ) ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be a large list, right? for files it will be even larger
how about wrapping this into if(minimumCoverageStmtPerFile > 0.0 && minimumCoverageBranchPerPackage > 0.0)
to avoid checking every package/file with default/0 minimum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do
@@ -0,0 +1,38 @@ | |||
def checkModule(logText, module, coverageLog) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome tests! Thank you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you added the tests, i just duplicated :)
2fbd487
to
3d9c712
Compare
perhaps windows tests will now succeed. added |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there, let's make the test maven 3.9 compatible and we should be good to merge and then hopefully release soon after
|
||
boolean ok = checkCoverage( getLog(), "Total", coverage, | ||
minimumCoverage, minimumCoverageBranchTotal, true ); | ||
ok = checkCoverage( getLog(), "Package:", coverage.packages(), x -> x.name(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor, we can do MeasuredPackage::name
instead of x -> x.name()
and MeasuredFile::filename
instead of x -> x.filename()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do. not really familiar with new java syntax, more of a scala guy myself :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, I just don't like x
variables and Intellij was kind/smart enough to suggest those :)
{ | ||
ok = false; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor, seems like this can be just ok = predicate.test(elem) && ok;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do, thank you, aligns well with what i did above.
assert new File(basedir, module + "/target/scoverage.xml").exists() | ||
assert new File(basedir, module + "/target/site/scoverage/index.html").exists() | ||
def entry = logText.find { | ||
it.startsWith("scoverage-maven-plugin:") && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i've noticed that with maven 3.9.6 ( i have that one locally) this check fails, as seems like maven 3.9 changed format from [INFO] --- scoverage-maven-plugin:2.0.1-SNAPSHOT:check (default-cli) @ module01 ---
to [INFO] --- scoverage:2.0.1-SNAPSHOT:check (default-cli) @ module01 ---
so changing to it.startsWith("scoverage") &&
seems fine for both 3.9.x and 3.8.x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do
Previously, it was only reported as such for min = 100.
Also, extract a coverage computation and logging method.
Along with existing overall coverage, add parameters for statement and branch minima at the package and file level.
@jozic all done, ptal. happy new year :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@kitbellew thanks for your contribution and for your patience during reviews and those almost 6 years :)
I see that @gslowikowski wanted to do some extra checks, but as he's no longer active we gonna move forward and merge/release this. We can always revisit things later if needed.
Happy New Year!
@kitbellew this is released in 2.0.1 |
Along with existing statement minimum, add branch minimum. Also, include
this pair of control at the package and file level.