I have a gradle project which applies the sonarqube gradle plugin, version 2.6.
I run it against my team's sonarqube server, version 6.4 (build 25310).
According to documentation, new versions of sonarqube accept the property sonar.junit.reportPaths instead of sonar.junit.reportsPath.
My build runs 2 test tasks: test and integrationTest. Each test task outputs its xml into a different directory: build/test-results/test and build/test-results/integrationTest respectively.
I configured the sonarqube plugin to pick up both these directories:
project.sonarqube {
properties {
property 'sonar.junit.reportsPath', ['build/test-results/test',
'build/test-results/integrationTest']
// configure additional integration test properties that seem to be required
Collection<File> integrationTestSourceDirs = project.sourceSets.integrationTest.allJava.srcDirs.findAll { File dir -> dir.exists() }
properties['sonar.tests'] += integrationTestSourceDirs
Collection<File> integrationTestsClasses = project.sourceSets.integrationTest.output.classesDirs.files.findAll { File file -> file.exists() }
properties['sonar.java.test.binaries'] += integrationTestsClasses
}
}
This does not work. In sonarqube UI I only see unit tests (from the test directory) and don't see any integration tests.
I made sure that my integrationTest directory contains valid test reports, and it does.
It seems like sonarqube still uses the old parameter sonar.junit.reportsPath (which by default is assigned by the gradle plugin with the value build/test-results/test). I can tell this because if I remove this parameter I don't see any unit tests at all in the UI. This is how I removed the old parameter:
project.sonarqube {
properties {
properties.remove("sonar.junit.reportsPath")
}
}
As a workaround, I configured my integrationTest task to put its output into the same directory as unit tests: build/test-results/test. After doing this, all tests, including integration tests are picked up by sonarqube, and I can see them all in the UI.
However, I would prefer to keep outputs of different test tasks in different directories.
Is the described behavior intentional, or is it a bug?
Your SonarJava plugin is too old. The new property is only available from 4.11 on. In 4.10 only the old property is evaluated, so the new one is ignored. The Gradle plugin just sets the properties. The evaluation happens in the code that is downloaded from the SonarQube server and thus ignored.
Related
I have my sonarqube configured the following way on a multi-module gradle project.
sonarqube {
properties {
property("sonar.projectKey", "key")
property("sonar.organization", "org")
property("sonar.host.url", "https://sonarcloud.io")
}
}
This configuration is on the root build.gradle.kts.
I now have a integration test folder that I added using the jvm-test-suite plugin and I want these sources to show up as well on Sonarqube.
I've added this config:
property("sonar.tests", "src/test, src/integrationTest")
But made no difference. They don't show up.
Any ideas? Thanks
I have a maven project and the below step is mentioned right after executing surefire tests(for JUnit) and failsafe (for Integration tests). However, I am not able to exclude the files from generated-sources folder. However, if I use a single exclusionPattern:'/tomcat/', it is excluding tomcat folder from the report
I have tried below option:
**```
post {
always {
junit allowEmptyResults: true, testResults: '**/target/failsafe-reports/*.xml'
step( [ $class: 'JacocoPublisher', exclusionPattern: '**/target/generated-sources/**,**/tomcat/**'] )
}
}
```**
but it is only excluding the tomcat folders and not the generated-sources. Still seeing files from this folder in coverage report.
As a workaround, I am targeting the java packages inside target directory to improve coverage. It's not a very efficient way to do it as I had to add entries for multiple packages inside exclusionPattern. But, it works well for my requirement.
I have a SpringBoot application where I have application.properties file outside of project (it's not in usual place src/main/resources).
While building application with gradle clean build, it fails as code is not able to find properties files.
I have tried many command to pass vm args, gradle opts but its not working.
gradle clean build -Djvmargs="-Dspring.config.location=/users/home/dev/application.properties" //not working
It fails on test phase when it creates Spring application context and not able to substitute property placeholders. If I skip test as gradle clean build -x test it works.
Though I can run the app with java -jar api.jar --spring.config.location=file:/users/home/dev/application.properties
Please help how I can pass spring.config.location=/users/home/dev/application.properties in gradle build using command line so that build runs with all Junit tests
If I were you, I would not get involved the actual properties to junit test. So I would create a test properties for the project under src/test/resources/application-test.properties and in junit test I would load the test properties.
Example:
#RunWith(SpringRunner.class)
#SpringBootTest(classes = MyProperties.class)
#TestPropertySource("classpath:application-test.properties")
public class MyTestExample{
#Test
public void myTest() throws Exception {
...
}
}
System properties for running Gradle are not automatically passed on to the testing framework. I presume this is to isolate the tests as much as possible so differences in the environment will not lead to differences in the outcome, unless explicitly configured that way.
If you look at the Gradle API for the Test task, you can see that you can configure system properties through through the systemProperty method on the task (Groovy DSL):
test {
systemProperty "spring.config.location", "/path/to/my/configuration/repository/application.properties"
}
If you also want to read a system property from the Gradle command line and then pass that the test, you have to read it from Gradle first, e.g. as a project property, and then pass that value to the test:
test {
if (project.hasProperty('testconfig')) {
systemProperty 'spring.config.location', project.getProperty('testconfig')
}
}
Run it with gradle -Ptestconfig="/path/to/my/configuration/repository/application.properties" build
However, I would discourage using system properties on the build command line if you can avoid it. At the very least, it will annoy you greatly in the long run. If the configuration file can be in different locations on different machines (depending on where you have checkout out the repository and if it is not in the same relative path to your Spring Boot repository), you may want to specify it in a personal gradle.properties file instead.
I think there is a misunderstanding.
spring.config.location is used at runtime
As you validated:
java -jar api.jar --spring.config.location=file:/users/home/dev/application.properties
spring.config.location is used or required at runtime, not at build time.
When your spring boot app is building, an application.properties is required. An approach could be use an src/main/resources/application.properties with template values, but at runtime you will ignore it spring.config.location=file...
For unit tests
In this case as #nikos-bob said, you must use another properties, commonly inside of your src/test/resources
Environment variables instead external properties
We don't want to have hardcoded values in our main git repository src/main/resources/application.properties so the first idea is use an external properties. But this file must be stored in another git repository (equal to main repository ) or manually created.
Spring and other frameworks give us an alternative: Use environment variables.
So instead of manually external creation of application.properties or store it in our git repository, your spring boot app always must have an application.properties but with environment variables:
spring.datasource.url=jdbc:oracle:thin:#${DATABASE_HOST}:${DATABASE_PORT}:${DATABASE_SID}
spring.datasource.username=${DATABASE_USER}
spring.datasource.password=${DATABASE_PASSWORD}
spring.mail.host = ${MAIL_HOST}
spring.mail.username =${MAIL_USERNAME}
spring.mail.password =${MAIL_PASSWORD}
Advantages:
No manually creation of application.properties allowing us a more easy devops automations
No spring.config.location=file.. is required
We have a tool that runs from the command line. One of the commands is -version.
Before we converted to the nebula release plugin, the version was in the gradle.properties file, and as part of the build we copied it from there to a src/main/resources/version.txt file, that was later read by the tool to output the version.
But now the version is never in a file that's checked into git. Instead, it is only known during the nebula release process.
We want to obtain that version during the nebula release process and inject it into the jar that nebula is about to publish. For example, it could be added to the manifest.
We've tried to figure out how to do this, but don't see any examples online, and nothing about it in the documentation.
Simply create a task that caches the version that is dynamically inferred by Nebula.
Since you originally copied/created src/main/resources/version.txt, we'll use that that model our task.
Assuming a simple/standard Java project, using the Kotlin DSL:
val cacheNebulaVersion by tasks.registering {
mustRunAfter(tasks.named("release"))
doLast {
val sourceSets = project.extensions.getByName("sourceSets") as SourceSetContainer
sourceSets.getByName(SourceSet.MAIN_SOURCE_SET_NAME).output.resourcesDir?.let {
// If there are not existing resources in your project then you must create
// the resources dir otherwise a FileNotFoundException will be thrown.
if (!it.exists()) {
it.mkdirs()
}
File(it, "version.txt").printWriter().use { out ->
out.println(project.version)
}
}
}
}
When I invoke ./gradlew clean build snapshot cacheNebulaVersion, the version produced by Nebula is cached/created at src/main/resources/version.txt in the build output. The task above does not bundle it with the jar.
Hopefully that gives you an idea what to do.
I cannot get SonarQube to scan my .groovy files on sonarcloud.io. I added the following to my build.gradle:
sonarqube {
properties {
property 'sonar.host.url', 'https://sonarcloud.io'
property 'sonar.organization', System.getenv('SONARQUBE_ORG')
property 'sonar.login', System.getenv('SONARQUBE_LOGIN')
property 'sonar.inclusions', '**/*.groovy,**/*.java'
}
}
It reports indexing 5 files, but there are 0 lines of code in sonarcloud.io.
My source is in the 'sonarqube' branch at here
My sonar cloud project is at here
Here is a project that is scanning groovy, but I can't find the source code to determine how it is configured: Link
SonarCloud does not support Groovy analysis.
The project you found is an old one, not analyzed for more than a year. It's a left-over from the former version of the service (called SonarQube.com at that time) that had some sort of support for Groovy.