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.
Related
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.
I have just hit a roadblock and would really need some insight from someone who knows the maven-release-plugin. I am trying to use the plugin for operating with my pom file, but without having it touching/committing to the main branch, but to a separate branch so that I can later on PR from there and get the review+approval required by the branch protection policy in my repos.
Context
We use github, and the company is enforcing a new branch protection policy in our main branches for security reasons mainly.
I have been using a jenkins pipeline for releasing and delivering my code which in turn, uses the maven-release-plugin for tagging the repo, and switching the version in the pom.xml, etc.
When using github's branch protection, the release plugin cannot do the usual operations, because it cannot push straight to the main branch.
My research
I found out that the plugin supports creating a branch in the process of releasing, that would be exactly what I am looking for. So, I built the environment for trying this out:
GitHub repository
Maven project
and started running some tests. The closest to being successful, was this line (version number is not important):
mvn --batch-mode release:branch '-DbranchName=release-v1.2.1' -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false
I started with the version in the pom set to the value of the version I am releasing (it is not great, but I am willing to make that commit myself). I have checked the release:prepare docs but found nothing that would help me achieving my goal.
My question
Is there any way of telling the plugin, not to make any commits to the original branch, so that it does not get rejected by the branch protection?
I always get at least a commit to the main branch like this one:
* 934af86 2020-04-27 | [maven-release-plugin] prepare branch release-v1.2.1 (HEAD -> master) [Commiter Name]
I know it's late to answer this but I just had the same issue and maybe someone else will search for this as well.
My configuration:
Jenkins
SCM Manager (Sonia)
Git master repo restricted for PRs only
What I end up doing was checking out to new branch and do the release from there. In my SCM-Manager I removed all priviledges for this branch from other users except for jenkis to protect it from being written directly.
So in jenkins project configuration I have set "Branches to build" to "*/Master". Then I added "Check out to specific local branch" in "Additional Behaviours". In branch name I have put "master_release". Your branch should be shown when you do release for the first time.
Since this was first release I will update this answer if I encounter any issues on next iteration but from my perspective it should work.
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 am having a bit of trouble with the Branch Updater feature of Bamboo.
If a new commit is pushed on a branch that is using the branch updater, Bamboo checks if there are new commits on the dependent branch(in my case the master branch) and if this is the case it merges the changes and runs the build.
However, if this build fails, it is hard to recognize, if the new code on the branch itself is broken or if it just could not be merged correctly with the master. Therefore I would like that in these cases the branch is build independently first and only if this build is successful, the changes on the master are merged in and the branch is build again.
Is this possible using the branch updater feature?
A workaround might be to use multiple build plans and use one to build all branches isolated and another plan to integrate everything using the branch updater.
The "Branch Updater" feature is to merge the code from master branch into feature branch after a successful build of the master branch.
However, currently there is NO straight forward option in Bamboo (except the workaround mentioned in your OP) to build the branch and auto merge only if the branch build is successful.
Typically, the developer runs the build in local and commit the changes to repository if the local build is successful. There are two things that can go wrong.
1) While running the local build, the latest code from feature branch is not available in local. Some of the repos like GIT would complain if the local doesn't match with HEAD revision, you need to update to HEAD before you commit the changes. In this case, you can run the build again to ensure there is no problem.
2) When the master code merges with feature branch, something could go wrong
I understand that still there is a gap which can be addressed to resolve the point 2.
You can create a ticket in Bamboo with detailed explanation of the use case to add this feature.
Is it possible to make a release from custom branch (not develop)?
I tried to use startCommit command, but Maven JGitFlow plugin has been switched to the develop branch before release is started.
Also, when I changed git configuration manually, it was automatically changed to develop.
I would like to use following steps:
release-start - create release branch
release-finish - create tag, merge to the master and develop, update pom.xml versions.
Issue found
Create a branch from tagged version
Fix issues there
Make another release from that branch
It seems that the parameter startCommit (http://jgitflow.bitbucket.org/release-start-mojo.html#startCommit) is not enough because that provokes an exception with m5.1 (https://ecosystem.atlassian.net/browse/MJF-284). Using flowInitContext seems to work though (http://jgitflow.bitbucket.org/release-start-mojo.html#flowInitContext). You just have to adjust the develop branch (source branch for release branches) to point to your custom branch.
The only thing which cannot be achieved that way, is that during release-finish a merge back to the global develop branch is done. Usually you also don't want to merge back to master (since that may provoke git merge conflicts), which need to be resolved manually.