We are currently using Bamboo for our build tool and one of our stages contains a task to run Sonar analysis.
It works great except for the fact that results are published for both master and feature branches. Of course this means that if we build a branch then results will override the existing ones.
We have looked into Auto Branch in the Sonar task but we don't want a large number of branch projects in Sonar so this is a no-go for us.
How else can we selectively run Sonar analyses depending on the branch? I heard that using a property in our Maven pom.xml could work, I wonder if anyone has an example of that?
I add the -Dsonar.projectVersion=${bamboo.repository.branch.name} at runtime. That adds the branch as the project version.
I am using sonar-runner to execute the sonar analysis so since you're using maven, your mileage may vary - in other words convert that to whatever the maven version of that argument is.
So when I run the sonar-runner task I include that -D argument on the command line. Even running it with maven you should be able to pass it in on the command line. Whatever branch is building that's the one that will show up on the SonarQube dashboard.
Related
I'm using gitlab-ci pipeline, it will run a new docker container with following commands:
mvn --batch-mode verify sonar:sonar
-Dsonar.analysis.mode=preview
-Dsonar.gitlab.project_id=$CI_PROJECT_ID
-Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA
-Dsonar.gitlab.only_issue_from_commit_file=true
-Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME
-Dsonar.host.url=xxx
-Dsonar.test.inclusions="/src/test/java/**/*.java"
-Dsonar.login=xxx
It becomes quite slow for my project, almost run for 20mins.
I found it will scan all files instead of only the commited files.
Is there anything wrong with my configurations?
In some past SonarQube versions we changed the preview mode to only scan changed files. But it has some drawback, like not being able to properly detect cross file issues.
In recent SonarQube versions, the preview mode is deprecated in favor of pull request analysis. But even this PR analysis feature is scanning all files, for the same reasons (cross file issues, coverage measures, duplication detections, ...).
We stopped trying to do partial analysis, and are instead trying to optimize full analysis duration. How big is your project? Is SonarQube analysis time long compared to your regular build (compile + tests)? If yes, then I suggest you report you case on the SonarSource community forum.
I recently started using SonarQube on my Maven Java Project. The problem is that I modified a single line in a Class which causes Sonar failing to load the project into the database. Why does Sonar know that my project is checked into a SVN and why does mvn sonar:sonar fails with "can not blame XXX on line YYY" if a class is not committed into the SVN?
I am the only one working on this and I dont want to check in every single change or experimental code snipet. How can I turn this feature off?
Thank you!
SCM integration (which detects that your projects uses SVN) allows SonarQube to track changes to source code, e.g to compute coverage on new code, new issues etc.
A standard analysis is supposed to be performed from commited code (e.g by a continuous integration server) to serve as a reference.
In your case, I would advise you to use the incremental mode: this will allow you to perform an analysis on your local code changes, which will not be persisted to the central server, but which will show you which issues your new code introduced/fixed (this is the analysis mode used by the IDE integration plugins).
I am pretty new to TeamCity and was hoping to get some best practice advice. We are using the Maven-Release plugin to do our releases and it works great, however we have a situation where we would like to have releases both off the trunk for test teams and then branch when we feel the codebase is stable enough for a proper release candidate. Ideally I'd like to have a single TeamCity release project, that by default will do a 'test release' off the trunk unless a build parameter is passed (e.g. project.release.type = branch) and then TeamCity will execute a different build configuration which will perform a mvn release:branch instead of a prepare.
Basically, can I conditionally execute TeamCity build configurations & how? Otherwise is there a suggested was to cater for the above scenario other than having multiple TeamCity release projects.
Cheers
I know that there is no "new project" button on SonarQube UI. However, I have two branches of the same project that I want to do analysis on. The thing is that since the project names are the same, SonarQube will upload the analysis results of the two branches into the same project on SonarQube Server. How do I configure SonarQube so that one branch will upload analysis results to one project and the other branch will upload results to another project on SonarQube server?
You might want to look at this part of the Sonar documentation, specifically at the sonar.branch parameter. It seems to be designed for what you want to do, and is working that way for us.
As the sonar.branch parameter is deprecated and the Developer Edition costs money, one possible option it to use the already mentioned branch plugin for SonarQube Community Edition (LGPL).
Update: seems like the repo is gone, not sure why. Active fork can be found here.
If you use SonarQube Runner, then you have to change the sonar.projectKey property to different values. If you use maven based analyses, then add -Dsonar.projectKey="Something" to your command. Example:
mvn sonar:sonar -Dsonar.projectKey="My project in first branch"
mvn sonar:sonar -Dsonar.projectKey="My project in second branch"
You can change the project name in a similar way with the sonar.projectName property.
This blog post by the SonarQube team suggests that treatment of branches will be improved in version 6.
Additionally, if you are using pull requests, have a look at its pull request analysis plugins (both GitHub and BitBucket at the moment).
The sonar.branch parameter is deprecated from sonar version 7.1 so, for alternative for that and having separate branch analysis on sonarQube version 7.1 on-words you can use something like this.
I assume you have maven project. if not just remove -D from it and use it.
mvn sonar:sonar -Dsonar.projectKey=<projectname>
mvn sonar:sonar -Dsonar.projectName=<project-name>
The project key should be unique. Otherwise it will combine the result of other branches who has the same project key.
The group that I work in has standardized on Jenkins for Continuous Integration builds. Code check-in triggers a standard build, Cobertura analysis and publish to an Artifactory SNAPSHOT repo. I've just finished adding a new target to the master build file that'll kick off a Sonar run but I don't want that running on every check-in.
Is there a way to schedule a nightly build of a specific build target in Jenkins? Jenkins obviously facilitates scheduled builds but it'll run the project's regular build every time. I'd like to be able to schedule the Sonar build target to run nightly.
I could, of course, create a separate Jenkins project just to run the Sonar target on a schedule but I'm trying to avoid that if I can. Our Jenkins server already has several hundred builds on it; doubling that for the sake of scheduling nightly builds isn't very desirable. I looked for a Jenkins plug-in that might facilitate this but I couldn't find anything. Any suggestions?
Here's one way to do it, if you are ok with triggering the build using cron or some other scheduling tool:
Make the build parameterized, and use a parameter in your build file to decide if the Sonar build target should run or not.
Trigger the build remotely by HTTP POST:ing the parameter values as a form to http://[jenkins-host]/jobs/[jobname]/buildWithParameters. Depending on your Jenkins version and configuration, you might need to add an Authentication Token and include this in your url.
Authenticate your POST using a username and password.
wget --auth-no-challenge --http-user=USERNAME --http-password=PASSWORD "https://[jenkins-host]/job/[jobname]/buildWithParameters?token=<token defined in job configuration>&<param>=<value>&<param2>=<value2>"
I am also looking for a solution for this. My current solution in my mind is to create 2 triggers in the regular build, one is the nightly build, another one is Polling SCM
In the sonar plugin configuration, it has the options to skip the builds triggered by the SCM change. Therefore, only the nightly build will start a sonar analysis.
I didn't get a chance to test it now, but I suppose this will work.
Updated on 12/19/2011
The above solution doesn't work if the sonar analysis is invoked as a standalone build step. To make the sonar analysis run conditionally, you could use the following 2 plugins:
Conditional BuildStep Plugin - this allows the sonar analysis to be run conditionally
Jenkins Environment Injector Plug-in - this allows you to inject the variables to indicate how the build is triggered.