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.
Related
SonarQube has the concept of a main branch irrespective of its actual name. According to the documentation, the key is not to pass the sonar.branch.name property to the analysis.
So far, so good. However, when my Gradle build in Github does not set the property, then automatic branch detection kicks in and I get:
Detected branch/PR in 'GitHub Action'
Auto-configuring branch 'develop'
Well, that’s unfortunate, because now sonar.branch.name is set to develop, and SonarQube will not accept it as the main branch. This develop is set as the default branch in Github, but the scanner seems not able to detect this. Automatic detection will not happen when I set the property explicitly, but then of course it is still set to something.
The question is now: Can I skip branch detection in the Sonarscanner without setting sonar.branch.name? Can I influence the branch detection so it will correctly detect it is on the default branch?
We are using Github actions in a GitHub Enterprise Server 3.5.5, for reference.
I have an answer that feels more like a work-around, but seems to work. Within SonarQube, I can rename the main branch. This is more than just a cosmetic change. I set the value to develop, and the next SonarQube analysis with sonar.branch.name=develop was accepted as the main branch. This works – for now – but does not seem to be the documented and preferred way.
well i faced the same issue, while doing CICD with github action.
i use, this code to get the current branch
property "sonar.branch.name", System.getenv("BRANCH")
currentBranch is variable set in github actions
env:
BRANCH: ${{github.event.pull_request.head.ref}}
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.
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.
I have multiple VCS roots set up (Core, AuthN, Other). Due to out of control cross-cutting code, when we build Other, we need to download Core and AuthN in order to build a testing database for integration tests. Where I'm having issues is that we'll have up to 3 different branches of each active at any time: Current, Patch, Hotfix. When Other builds, the correct branch of the other 2 needs to come down as well, (e.g. if Other's Hotfix branch builds, it needs to pull Core and AuthN's Hotfix branch). Since these specific build numbers change on a regular basis, I'm uncertain how to get Other to identify which branch it needs.
I have Other set up with 3 VCS roots (one for Other, Core and AuthN), each with their own branchName parameter as the default branch. I also have a series of parameters created that identify what the current patch and hotfix version is for the next releases. I then created a PS script, that uses these values, plus the current branch name (Other's version), to set Core and AuthN branch names, but that build step doesn't run until after VCS downloads have completed. How can I get the correct version of Core and AuthN for a given version of Other
If the branches in the different repositories are with the same name, you can probably use TeamCity feature branches and snapshot dependencies between the different build configurations.
So if the build chain triggers on a change in a particular branch in one repository then TeamCity will do its best to trigger the builds for the corresponding branches in the rest of the chain.
See the screenshot:
If there's a change in 'hotfix' branch of Step1 build configuration (#8), then the corresponding branch is built in Step2. However, if there was a change in the 'alternative' branch that only exists in Step2, then Step1 will be built from default branch which is 'master' in this example (#10).
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.