spring-projects / spring-security

Spring Security
http://spring.io/projects/spring-security
Apache License 2.0
8.72k stars 5.87k forks source link

SonarQube jobs are not reporting code coverage #6092

Closed jzheaux closed 5 years ago

jzheaux commented 5 years ago

We haven't seen code coverage on our SonarQube analyses for a while.

raphaelDL commented 5 years ago

I think I may have parts of the solution, will submit al PR tomorrow, midnight already but I needed to know what was going on with this Local SonarQube

raphaelDL commented 5 years ago

Hey!

I tried the next:

a) Edited build.gradle and added right after the buildscript section

plugins {
    id "org.sonarqube" version "2.6.2"
}

apply plugin: 'io.spring.convention.root'
apply plugin: 'jacoco'
apply plugin: "org.sonarqube"

b) Ran:

./gradlew clean jacocoTestReport sonarqube -PexcludeProjects='**/samples/**' -Dsonar.jacoco.reportPaths='**/build/jacoco/*.exec'

I tried it with a fresh new sonarqube container and so far it looks like it is working.

Q: I'm not sure if that plugin declaration is defined elsewhere, I couldn't find it :( Is it transitive? if so, what version are we getting?

What do you think @jzheaux ???

PD: Happy thanksgiving day ๐Ÿฆƒ

raphaelDL commented 5 years ago

Turns out the step a) is not needed, I just ran:

./gradlew clean jacocoTestReport sonarqube -PexcludeProjects='**/samples/**' -Dsonar.jacoco.reportPaths='**/build/jacoco/*.exec'

and got the coverage report shown again in a fresh new sonar container. Maybe what we were missing was telling sonar where the reports are located.

I think we just need to edit the command in the Sonar step.

As stated in build.gradle we need to explicitly call jacocoTestReport to get the report, otherwise it will not be generated.

My question is: what do we use wen calling the Sonar routine, Jenkinsfile or travis.yml?

Knowing this I think I can submit a PR

jzheaux commented 5 years ago

@raphaelDL wow, thanks for your extra research here! You are the man.

We use Jenkinsfile for the sonar routine.

Are you saying that when you run with ./gradlew clean sonarqube -PexcludeProjects='**/samples/**' you don't see code coverage in the Sonar report, but when you do ./gradlew clean jacocoTestReport sonarqube -PexcludeProjects='**/samples/**' -Dsonar.jacoco.reportPaths='**/build/jacoco/*.exec' then you do see code coverage in the report?

Makes sense, just want to make sure we are on the same page.

If so, then I think that is enough to submit a PR, yes.

raphaelDL commented 5 years ago

Absolutely ยก, let's try it

raphaelDL commented 5 years ago

@jzheaux @rwinch

I'm posting a comment here instead of the gradle-plugins repo, 'cause I think is more related with what we have in this project.

Here's what I've found

when the Jacoco plugin is applied coverage reports should be generated when calling check and test tasks.

We are preventing the reports being generated here: https://github.com/spring-projects/spring-security/blob/7618d236c4562491fb2cead8f866c04dabdca21f/build.gradle#L24

A quick read into the provided issue link suggests something about caching tests results, so in order to prevent report generation every time we call test or check it is decided to generate them only when needed, that's why we need to explicitly call the task jacocoTestReport,

Having a look at https://docs.gradle.org/5.0/release-notes.html it seems that now is solved.

With the current gradle version 4.10.2 I removed that restriction and now I have the reports generated when I call test and check

Before the change I submitted we had in the Sonar stage ./gradlew clean sonarqube....

what was going here? coverage data generated in the previous step (with test and check) were being erased because we included clean and and they were not generated again resulting in sonarqube not having that data.

Finally.... spoiler alert -Dsonar.jacoco.reportPaths='**/build/jacoco/*.exec' is not needed after all ๐Ÿ˜… I thought we needed cause sonar wouldn't find them, but in fact the coverage data was there all the time but was gone/erased when sonarqube was executed.

rwinch commented 5 years ago

@raphaelDL Thanks for the updates! Would you like to submit a PR to fix this?

raphaelDL commented 5 years ago

Sure,

just to be sure, in this pull request I would include:

a) the deletion of the code that force us to call jacocoTestReport explicitly in build.gradle b) revert the command called in the Jenkinsfile sonar stage from ./gradlew clean jacocoTestReport sonarqube to ./gradlew sonarqube removing the jacocoTestReport and clean tasks

๐Ÿค”

rwinch commented 5 years ago

Looks good to me @raphaelDL! Thanks :)

raphaelDL commented 5 years ago

I've submitted #6199