With sonarqube running on my project, I created a new branch other than main, as the default one and started working on the same. While running sonar, only the main(master) branch is taken into consideration by default. I tried this short-lived branch feature, but it compares the files with master branch and shows only the files which are modified in the new branch. The files which are created in the new branch are not shown. How to fix that ? or how to change the default branch in sonar.
Sonar : Community Edition : version 7.9
If you are asking about the default branch in SonarQube, the community edition is seen to be showing all the projects as with 'master' branch.
Could refer https://docs.sonarqube.org/latest/branches/overview/
Master / Main Branch This is the default branch and typically
corresponds to what's being developed for your next release. This is
usually known within a development team as "master" or "head" and is
analyzed when no specific branch parameters are provided. It is
labeled "Main Branch" and defaults to the name "master" but can be
renamed from the project settings at Administration > Branches and
Pull Requests. When you are using Community Edition, this is the
only branch you see.
With community edition, I found a fix. Provide the value to sonar.branch.name to the intended branch. In my case sonar.branch.name=sprint7_bugfixes. The sonar will run for whole of the branch and will update the content in dashboard, but still the name will be shown as master.
Another way of doing that is changing the project key and project name along with branch name.
Related
We have configured a VCS per project defining "branch specification" and a "default branch" like shown on the image below.
There is no new commit on the default branch in Bitbucket (our VCS) since the last successful build. Nevertheless pending changes appear on TeamCity when selecting the "default branch". These pending changes are commits from another branch.
Do you know what could be the issue ?
For information, we use TeamCity Professional version 10.0.4 (build 42538).
Is it possible to copy/duplicate a SonarQube branch (using the Branch Plugin) to a new branch? Or would analysis have to be re-run with new branch's name?
Here's an example:
The master branch is the main branch of a project. Now let's say version 2.0 of the product is being released. Before version 3.0 code is created and analyzed, we want to spin-off a release-2.0 long-lived branch from master. What is the most efficient way to do this?
Is there an option to duplicate the main branch in SonarQube to a new branch with a new name?
Or Would you have to re-perform analysis on the code but specify the sonar.branch.name property as release-2.0?
There is no functionality within SonarQube to duplicate. You must perform analysis with the new branch name to create your long-lived branch.
When I try to analyze my project using sonar-scanner, the scan fails with the following error message:
Caused by: Branch does not exist on server: develop
Apparently, this only happens when it analyzes a Pull Request from GitHub. I could reproduce the error, when I add the following configuration to sonar-project.properties:
sonar.branch.name = source-branch
sonar.branch.target = target-branch
What could be the cause for this problem?
I solved the problem by deleting my Sonar project that was watching the develop branch. Then I added the develop branch as a long-living branch to the Sonar project analyzing the master branch. Before, I had a Sonar project for each long-living branch, because I was using the branches property in travis.yml (which is getting deprecated now).
To add a new branch to Sonarqube you need to add the sonar.branch.name property with the name of the desired branch to the sonar-project.properties file. E.g.: sonar.branch.name=develop
Then you run sonar-scanner and your branch will be available inside the Sonar-Project.*
* Make sure to check if the Regex for long-living branches is appropriate to your new branch on Sonarqube. You can't change a long-living branch to a short-living branch or vice-versa after the branch is added to Sonarqube.
The result is that I have only one project on Sonarqube now that watches all my branches. It's a lot cleaner and works better.
More information on the branch plugin.
I use sonar-runner (2.8) to launch analysis in Jenkins job.
The Sonar Branch plugin is installed on SonarQube 6.7.1 server that I use.
Regardless of what values I put in params:
sonar.projectKey
sonar.projectName
sonar.branch.name #from branch plugin
sonar.branch.target #from branch plugin
I cannot set up the Main branch name. It's always called the "master" which is the default name for Main branch. I also played with the regex responsible for detecting long-live branches.
I can change the branch name of the Main branch by hand on the SonarQube server side (via UI). I'd like to set it up on the parameters side (before the analysis is launched) to avoid manual work.
Is it possible at all?
The support for branches is part of the SonarQube Developer Edition, which is a commercial package. You will not be able to change the name of the default name if you haven't purchased a license for it.
If you did purchase a license, then you can change the name of the default branch in the "Administration > Branches and Pull Requests" page. You can read more about support for branches on the documentation page.
I am working with Team City for .net and use it for continuous integration - works well. I have it running off my main branch.
I now have a release branch - how I can I configure to set up a release branch in team city. What is the best way to do this?
What I've done before is to copy the build configuration of my trunk build and then just create a new VCS root pointing at the other branch and use that in the new configuration.
Your can track several branches using Branch Specification field of VCS root. Specify wildcard for you branches like
+:refs/heads/release_* (for release branches) or
+:refs/heads/* (for all branches)
More details in docs.
Some notes:
Run build button runs it for default branch. Click ellipsis -> Changes tab to select specific branch.
Now you cannot use artifact dependencies for specific branch. Such dependencies will always use the default branch.
Regarding issues with artifact dependencies, it's not easy to create deployment configurations from branch specific artifacts. In this case I'd go using separate configurations for each branch. Otherwise you should rely on API and/or some artifact path name parsing logic.
If you don't need per branch deployments, it's completely ok to just use branch specs approach.