Quality Gates in multi-branch setup

[m...@thomaskeller.biz]

Hi all!

We've set up a CI pipeline that continuously analyzes all our feature branches in Sonarqube.

Now, while having a second look, I wonder how Quality Gates like "No new bugs" are supposed to work in such a set up for a feature branch without knowing its "baseline", i.e. the analysis / project of the base branch.

Is there any option in Sonarqube with which I could link those during analysis or how is this supposed to work otherwise?

Thanks,

Thomas.

[G. Ann Campbell]

Hi Thomas,

No, you haven't missed anything, it's just not there. At least, not in a built-in way.

To accomplish what you're after, you'll need to do something like:

* Create branch project in SonarQube

* Analyze master with branch name to set baseline

* Branch code

* Analyze with branch name and a version number that's different from the one master was analyzed with.

OTOH, how long-lived are your feature branches? Won't SonarLint and Pull Request Analysis handle it for you?

Ann

[m...@thomaskeller.biz]

(Cross-posting here again manually, because Google rejected my Cc: sona...@googlegroups.com)

Hi Ann!

G. Ann Campbell schrieb:

No, you haven't missed anything, it's just not there. At least, not in a
built-in way.

To accomplish what you're after, you'll need to do something like:

* Create branch project in SonarQube
* Analyze master with branch name to set baseline
* Branch code
* Analyze with branch name and a version number that's different from
the one master was analyzed with.

OTOH, how long-lived are your feature branches? Won't SonarLint and Pull
Request Analysis handle it for you?

Hrm... am I correct that setting the branch name to "baseline" is the
thing that is mandatory in order to let this work?

Our branches are not long-lived, they're typical feature branches. As
such, we want Sonarqube to report us possible violations before they
sneak into the main development branch.

On a related note - what if there are multiple "baseline" branches
(think multiple release branches) which get features / bugfixes
"cherry-picked"?
A single, static "baseline" branch would then not suffice, because I
could still not tell the feature branch project which _exact_ branch it
was forked off from, right?

Thanks in advance,
Thomas.

[G. Ann Campbell]

Hi Thomas,

Each branch needs a unique `sonar.branch` value. Your baseline analysis of master will pass in `sonar.branch=[branch identifier here]`, and perhaps something like `sonar.version=master`.

Then you'll analyze the branch code with `sonar.branch=[branch identifier here]` and `sonar.version=branch`.

The version numbers/names don't have to be unique, but the branch names do.

Ann

Ann

[PSReddy]

Hi Ann,

         We are not yet in master / trunk based release model and have long-lived branches say R1 and R2 and have CI pipeline on these branches. There are frequent merges from R1 to R2.

Can you please suggest if we should analyze R1 and baseline R2 sonar branch before each merge?  Will branch plugin in EE simplify / work in our scenario? Thanks in advance.

[G. Ann Campbell]

Hi,

This thread well over a year old and not really related to your question. If you wish to pursue this, please start a new thread and clarify your question, because from my current, meager understanding the only advice I think anyone would be able to give is "that's up to you."

Ann 

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/1BHxFagAq5Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/4097bf63-4404-468e-93fd-904f96572d8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.