I'm using Sonarqube 7.9 and Gitlab with a maven docker image that calls my Sonarqube using mvn --batch-mode verify sonar:sonar -DskipTests=true -Drevision=$REVISION_UNSTABLE $SONAR_OPTS -Dsonar.analysis.mode=issues.
The thing is that the parameter sonar.analysis.mode is not used anymore since version 7.4 but I can't find out what parameter do I need to use instead.
At the build development branch I just want to check the issues related to the code and I don't want to publish anything. Only when I publish a tag or a production code I must publish results to Sonarqube interface. So what do I need to run my code with the previous issues and publish parameters? Is there any alternative to sonar.analysis.mode?
The direction SonarSource are pushing people in is to use branch/pull-request analysis to detect new issues across branches. I'd suggest you want to be using feature branches for your typical analysis if you're not wanting to retain history for a long time.
The branch analysis feature requires you use Developer Edition to work out-the-box, however there is a plugin that provides branch support on developer edition should you want to try it.
Your build/scan command would then become something similar to:
mvn verify sonar:sonar -DskipTests=true -Drevision=$REVISION_UNSTABLE $SONAR_OPTS -Dsonar.branch.name=develop
Related
I'm using maven release plugin to deploy new versions of software.
When running
mvn release:prepare
mvn release:perform
Everything works as expected.
If I tell maven to release version 2.1, it publishes an artifact 2.1 as well as a 2.2-20210205.061032-1, which I guess is some kind of snapshot. I'm wondering if it´s possible to perform a release for a new snapshot version ONLY?
The use case being that I have made some changes I want to publish for testing, before commiting to a final release. Something like 2.2-SNAPSHOT, or something like 2.2-YYYYMMDD.HHmmSS-X.
When prompted by maven to enter the next version, if I enter 2.2-SNAPSHOT, it just repeats the question again.
Please advice on how to achieve this, or if I'm thinking about this the wrong way.
If you want to deploy a SNAPSHOT, just run
mvn clean deploy
The Maven Release Plugin is meant for release versions.
SNAPSHOTs are meant to be very fluid, to the level of a dependent project "immediately" picking up changes to the SNAPSHOT dependency, whatever "immediately" means: it could be directly in an IDE, or while doing rapid builds on a command line but also on a CI server. I agree with the answer of J Fabian Meier that you can deploy a SNAPSHOT using mvn deploy.
However, if you are delivering a pre-release version for testing to a different team, you probably want them to have something that is more stable than a SNAPSHOT. When testing it is often important that you can reason about what version (or constellation of versions) you are running, and this is not quite the case with SNAPSHOTs (you may push up a new version then by quasi-accident, users may or may not force-update their SNAPSHOTs, or Maven may not look for new SNAPSHOTs until tomorrow).
You may be better off with versions that are released (from Maven's perspective) using the Maven Release Plugin (and benefit from the safeguards it offers), but just using version "numbers" that indicate it is a pre-release: 2.2-rc, 2.2-beta (I'm sure SemVer has ideas of the exact pattern to use, and so does Maven).
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.
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.
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.