Does anyone have a working solution for some kind of auto incrementing a version number on Sonarcloud? It’s a bit odd that you can set a rule of what a new version is but none of the options is “merge into production branch”.
We could now manually increase the version number before each merge, but that’s not really error prone. Did anyone find a better solution? Thanks for any input in advance!
Hi,
The reason to change the version number in SonarCloud is if you’re using the ‘Since Previous Version’ setting for the New Code Period.
If you are, you really don’t want to change sonar.projectVersion with each analysis because that would reset your New Code Period with each analysis and really wreak havoc on maintaining good Clean as You Code practices.
That said, if you reaaaally wanna do this, then just use your build number as the sonar.projectVersion value.
And… for context…
Would you mind providing some details here? I guess you work in develop and want this autoincrement on main?
Ann
Hi Ann,
thanks for reaching out, happy to share some more context: We are using a trunk-based versioning approach so there is only production and any other working branch, merging directly into it.
So for us, “new code” is always just the change in the working branch. And with each merge into production we basically have a new version (this is relevant for the next branch that wants to get merged into production).
Are we off track here with how we set it up on Sonarcloud? We indeed did use “Since Previous Version” setting, the other options were based on days (exact date or number of days) which is both wrong or “specific version” but this also seemed not right.
Best, Florian
Hi Florian,
I’m still a little confused.
Is each change deployed to production, granularly? Or do you save them up and deploy at a fixed interval?
At any rate, the point of all this is Clean as You Code: define a baseline (the start of the New Code Period) and make sure that all the changes that come after that are “clean” (low issues, high coverage &etc).
So… it’s possible (based on my shaky understanding) that the New Code Period on your main/production branch doesn’t matter as much as paying attention to your working branch and making sure it stays in good shape…?
The situation where that maybe falls apart is that changes that are ignorable in isolation aggregate to problems.
So for instance, when there are <20 lines of New Code, we don’t apply Quality Gate coverage conditions. That means that it’s possible to have, for instance, 10 commits of 18 uncovered lines each. They’ll all pass the Quality Gate and be “okay” New Code. But when they aggregate to an unacceptable level of coverage.
I’m a bit afraid I’m rambling, so I’m going to pull it back to your last post:
This comes back to a question of how you want to track quality and what a meaningful interval is for you. Can you come back with that, and then we can look at the best way to instrument it?
Ann
Hi Ann,
thanks for taking the time to answer with in such detail, really appreciate it! Let me share a bit more info. Are you familiar with Git-Flow branching model? Pretty much looks like this:
What we are doing is pretty much just this:
There is only one long-lived branch called “production”, this is what our customers are using. And everything else is work in progress until it gets merged and yes deployed after CI passes. We are deploying multiple times a day. It’s a much faster way to operate as we don’t have large releases anymore that might contain merge conflicts, etc. But: It does require very strict gates, in our case 100% coverage and very high quality.
What are we looking for in our CI: Tests pass, coverage report is pushed to Sonarcloud and analysed. Sonarcloud should detect the changes of that branch as new code and everything else as old code. Then gates either pass or fail. As we see every branch as a new version and there is this new code setting on Sonarcloud we were wondering how to properly use it. Our guess was an auto-version-increment but there might be an easier option. Does that help?
Best, Florian
Hi Florian,
Thanks for helping me understand your situation.
In your context, I would focus on new code in the development branches - as you’re doing. In production I would either set New Code to an arbitrary window larger than a single build/version, to aggregate those changes I mentioned earlier, or pay more attention to Overall code.
Keeping your new code clean is perfect. And since your organization seems to already be mature in this area then I’ll talk about what comes after you’ve got that down pat. To be honest, I’ve never gotten this far in the conversation with anyone before 
Even with perfect new code, it’s possible that additional issues will be raised in old code. Our analyzers are as good as we can make them, but they’re not perfect yet. But they get better all the time. That means that tomorrow’s analysis may find issues in code that we all thought was fine last week.
So for production it might make more sense to keep an eye on overall coverage just to be double-sure it’s not incrementally dropping, and on overall issues.
The default Quality Gate only has criteria on New Code, but here’s what we enforce internally:
I know this isn’t quite what you asked for, but is it helpful anyway?
Ann
Hi Ann,
thanks again for your input. We reviewed our setup again and based on what you shared we now have the exect same goals for new and overall code. We will not work based on versions then and just set new code = last 3 days (something low) and see how this goes.
Would still be cool to see if the future of Sonarcloud would add an option for new code based on “diff to main branch” or something like that.
In any case, thanks again for your help, cheers,
Florian
