I have a question regarding our current workflow and what would be the recommended SonarQube (Developer edition) setup to achieve what we need (or if it’s at all possible/intended to be used that way). We work with three long living branches:
master (main)
develop, branched from master
features, branched from develop
Any case specific branches for bug fixes are branched from develop, those for new features are branched from features and those for hotfixes are branched from master. We use the originating branches as reference branches for new code, so the master branch as the reference branch for develop, develop as the reference branch for features, and so on. We do this mainly to make sure resolved issues don’t need to be addressed more than once.
This all seems to work well when we merge a branch back into its respective reference branch. However, sometimes we need to merge the other way around, like from develop into feature to bring it up-to-date. We use Jenkins integration with SonarQube and Jenkins itself is triggered from Bitbucket, where we manage our pull requests and perform merges. However, we do not use pull request decoration in Bitbucket and would prefer to keep it that way for now. Also what we want to avoid is having to manually change the reference branch once or twice each time we want to do this.
What would you recommend in this scenario, to ensure issue resolutions will also be kept when reverse merging, is there an intended way to do this? And if I misunderstand the functionality, please let me know.
From your phrasing, I’m intuiting that there’s something that doesn’t work well when you rebase the reference branch into it’s… “child”. But I’m not sure what that something is.
Is it that when you mark an issue False Positive, for example, in develop, and then rebase develop into a bug fix branch, you want that issue automatically marked False Positive in the bug fix branch too?
If so, I’m sorry but that functionality simply doesn’t exist.
And if not, could you be more explicit about the problem you’re trying to solve? (And also tell us what version of SonarQube you’re using?)
Thanks for your reply, I’m sorry if I wasn’t entirely clear.
The main thing we want to solve is that when we resolve an issue as False Positive or Won’t Fix in, say, the develop branch and want to merge this branch into a child branch such as the features branch (instead of the usual merge into the reference branch, which is the master branch) to bring it up-to-date, we want to be able to copy the resolutions to the child branch as well.
I think we are saying the same thing.
My remaining question is whether you (or anyone else) know of an alternative way to achieve what we want using the possibilities SonarQube offers and the setup that we have, even if that means using custom code or analysis parameters situationally. I am assuming we are not the only ones who run into this problem, so perhaps there’s a view on this.
We are using version 8.9.2 at the moment, however we are thinking of upgrading to a later supported version, especially if it helps us solve this.
Regarding your version, it’s past EOL. You should upgrade to either the latest version or the current LTS at your earliest convenience. Your upgrade path is:
Thanks Ann, I’ll have a look at this option and the guide you sent. I did have a brief look at the Web API before and I have two questions about this. I’m hoping you can help me answer them so I can determine the best decision to make.
Is it only possible to create a branch together with an initial scan? Because if I understand correctly, using our version we can only do the following: create a branch and perform an initial scan > update the reference branch > perform another scan. Can you confirm whether I’m correct?
And secondly, would sonar.newCode.branchReference be the right alternative to use in newer versions in our situation?
Uhm… huh? You mean the initial analysis of a project? Or are you asking if something can be made into a branch retroactively? If the latter, no. The analysis has to be identified as being a branch analysis at analysis time.
That parameter (in newer versions) is used for setting the New Code definition on first analysis of a new branch.
Okay, thank you. What I meant was that it is not possible for a branch to exist in SonarQube without having run an initial analysis.
That seems to suggest the New Code definition of the branch will revert back to the project settings after the initial analysis, is that correct? I don’t find the documentation to be very clear on this.
It is not correct. Use the parameter on the first analysis of a branch to set the branch’s New Code definition, and it will stay that way until you change it manually.
In fact, it’s not possible for branches to exist in SonarQube before they’re analyzed. You can establish the project before its first analysis (via the onboarding wizard) but branches have to be analyzed to exist.