Some context
I am trying to configure the plugin 'Sonar Scanner' in our Jenkins, the trigger and the project validation is "working", I added the " " because it is actually validating everything, even the test files and it is not checking the coverage.
Things you should know before
I have no access to Jenkins machine
I have no access to SonarQube machine
All plugins installed from Jenkins are the most recent versions
My Config
My project folder structure looks like this (Java project):
.git
.scannerwork
bl
commons
datafeed
keyfiles
persistence
post-aggregator
project-setup
webapp
webapp-server
.gitignore
pom.xml
My Sonar Scanner config is:
#required metadata
sonar.projectKey=inventory
sonar.projectName=Inventory1
sonar.language=java
sonar.sourceEncoding=UTF-8
#sonar.tests=**/.*Test.java
sonar.exclusions=**/*Dto*, **/*Entity*
sonar.binaries=build/classes
sonar.java.binaries=/data/application/jenkins/jenkins/workspace/$JOB_NAME
#Adding more info to the log
sonar.verbose=true
#Path to source directory
sonar.sources=/data/application/jenkins/jenkins/workspace/$JOB_NAME
The problems
Test coverage is 0
Checking the report I see that the current Scanner config checks everything, even the tests
So.. the questions are:
My test files are spread all around in the project, how can (or if it is even possible) to add a regex to the "sonar.tests"? i have been trying to do it but no success, all my tests ends with Test.java
How can I avoid properly Sonar to scan the test files.
Do I need jacoco as well in order to make this work or its possible to do it without it? (we are configuring the jacoco-maven in the project)
Thank you for your time!
Related
I'm trying to make a Jenkins job that only scans the test source files, so everything under /src/test/java (using Maven). I use the SonarQube Jenkins post-action for this.
When we used to configure Sonar in the pom file directly we could do this in a profile:
<sonar.sources>/src/test/java</sonar.sources>
<sonar.tests/>
That worked fine.
But in the Jenkins job I have to specify these as 'Additional properties' and I can't seem to specify an emtpy sonar.tests element. I tried -Dsonar.tests, -Dsonar.tests=,-Dsonar.tests="", nothing works. When this element is not empty Sonar will attempt to scan the test files twice and crash.
The post-build step is specifically and explicitly a Maven operation. Your problem comes from trying to use Maven to do something un-Mavenish; i.e. ignore the convention that files in the tests directory should be treated as tests.
Since you want to scan your tests as code, your best bet is to use the build step (which uses SonarQube Scanner) and set your scanner properties manually. That will make it easy to set your sources directory and to omit the tests directory.
I would like to run Sonar plugin on Jenkins without any build process (my intent was to integrate Sonar analysis within Jenkins and take advantage of the subversion plugins and configurations we already had on there).
I do not want to run the build process since that would take up unnecessary time; I would only like to have a Jenkins job dedicated for Sonar analysis.
You can do that. You have to triggering the analysis with the SonarQube Runner.
Go to the Build section, click on Add build step and choose Invoke Standalone Sonar Analysis
Configure the SonarQube analysis. You can either point to an existing sonar-project.properties file or set the analysis properties directly in the Project properties field
When you analyse with SonarQube Runner , then you should give the following mandatory properties:
sonar.projectKey=my:project
sonar.projectName=My project
sonar.projectVersion=1.0
# Path to the parent source code directory.
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# Since SonarQube 4.2, this property is optional. If not set, SonarQube starts looking for source code
# from the directory containing the sonar-project.properties file.
sonar.sources=src
In this case you may miss some rule violations (like FindBugs), because .class files are not provided. You have to build the project manually and set the sonar.binaries property to your class files. If you never want to build the project, then you can use the SourceMeter plugin for SonarQube too. It only needs the source files, but can produce more metrics and issues if you needed.
I'm trying to get a build in Jenkins to show a coverage report of a Java unit test run. I can get the report at the high level showing that coverage has occurred at the class and method level, but part of the report where I can view the source code isn't working.
The inputs to the plugin are:
a coverage report in XML
source code
To use the plug in to create a coverage report:
Install Cobertura into Jenkins.
Create a Jenkins job with a post build to generate Cobertura report. In this step you tell it where in the Jenkins workspace to load the coverage report (often named coverage.xml).
Before you run the Jenkins job
The coverage report is created in some way (often by a build script of some kind). The report is often named coverage.xml by most people's build scripts and is placed in the Jenkin's job's workspace.
When running the Jenkins job
When the Jenkins job runs, the Cobertura plugin will read the coverage.xml and use the element to locate the source code. The plugin copies the source code into a cache located at: <Jenkins home>/jobs/<Jenkins job name>/<Cobertura>.
After running the Jenkins job
Read the coverage report by navigating to the Jenkins job that built it. If copying of the source files was successful during running the Jenkins job, you can drill down to the source code and see what lines were covered by the test run. If you can't see the source code level code coverage:
Check the cobertura cache to see if the code is there.
Check the permissions on the cache to see if the Jenkins server process owns that directory and has read, write, execute permission on that directory.
Check the cobertura.xml file and select a element and examine it's "filename" attribute and see if it's path will work as a relative path from the root of the Cobertura cache.
If the cache has old information, delete everything in the cache directory, and re-run the Jenkins job.
I have recently added several Hudson agent machines to a working controller.
Some of the builds have result files (Doxygen output, Boost unit test results, cppcheck) which are published using the relevant plugins.
If these builds run on the controller, the output files are published successfully, but if they run on an agent, the build fails because the files cannot be found.
The plugins seem to be looking for the output files on the controller, when of course, they are on the agent.
Is there a way to fix this?
Plugins used:
- Jenkins Cppcheck Plug-in V1.2
- Doxygen Plugin V0.9
- HTML Publisher plugin V0.6
Edit:
Tried archiving suggestion, but I can't get it to work. cppcheck.xml is archived correctly and exists in the relative directory ../lastSuccessful/archive/cppcheck.xml
Hudson log:
Archiving artifacts
[Cppcheck] Starting the cppcheck analysis.
[Cppcheck] No cppcheck test report file(s) were found with the pattern
'../lastSuccessful/archive/cppcheck.xml' relative to
'/home/hudson/.hudson/jobs/1.11-IntegrationDebug/workspace'.
Did you enter a pattern relative to the correct directory?
Did you generate the XML report(s) for Cppcheck?
[Cppcheck] Parsing throws exceptions. No cppcheck test report file(s) were
found with the pattern '../lastSuccessful/archive/cppcheck.xml' relative to
'/home/hudson/.hudson/jobs/1.11-IntegrationDebug/workspace'.
Workaround: copy artifacts into your workspace and publish from there.
I am new to Jenkins and just started configuring it. This is what i have done till now:
Installed and configured Jenkins to display the home page. Added PMD plugin.
Set the HUDSON_HOME to a specific directory > C:\Work\Jenkins
Configured a test build to run a simple do-nothing ant script. It runs successfully
Written an independent pmdbuild.xml to run checks on a set of files in C:\myview (I am using clearcase). This xml also copies the output pmd_results.xml to the workspace directory in $HUDSON_HOME/[job-name]/workspace
Now I added the pmdbuild.xml as a step in my primary build. So my build has 2 steps:
a. Run a simple script, do-nothing.
b. Run pmdbuild.xml which generate pmd_results.xml and place it in $HUDSON_HOME/[job-name]/workspace (HARD-CODED as Jenkins PMD plugin expects the file there)
Jenkins picks up the pmd_results.xml automatically with the plugin and displays warnings and everything.
Now the problem:
If I click on a filename in the PMD results, it gives a filenotfound exception as it is looking for the source file in $HUDSON_HOME/[job-name]/workspace.
My java code files are placed in C:\myview (a clearcase snapshot view)
My question is, do I need all my code files to be present inside $HUDSON_HOME/[job-name]/workspace ?? Meaning can't I tell Jenkins to look for the PMD input files in C:\myview or any other directory instead of $HUDSON_HOME/[job-name]/workspace ??
Sorry for the extremely long description.
Jenkins expects that all the code is in the workspace. Usually Jenkins is used to check out a copy of the code into the workspace, and then runs all build steps on the Sources in the Workspace.
Might seem restraining at first, but it saves you a lot of trouble if you need to move Jenkins to another server, or create a slave instance.
So I would suggest you let Jenkins check out your code (there should be a clearcase plugin) into the workspace, and run the analysis on the checked out code.
If there are compelling reasons why your code has to stay where it is (C:\myview in your case) you can still set the workspace of your build to that directory (find this in the job configuration page, you need to click on the 'extended' button to see the option).