Using branch name as a Leak Period

[Cagdas Cirit]

Hi,

I am using SonarQube 6.0. I am trying to integrate it with our BitBucket server and our git-flow based workflow. In our workflow; each Pull Request is creating a new project in SonarQube with different branch name (supporting branch) I want to set target branch as Leak Period. Is it possible?

I know that a new branch is equal to a new project with key: <sonar.projectKey>:<sonar.branch>

But I want to create a QG based on leak period of source branch (supporting branch) to target branch (development branch)

Scenario;

I have a project of which key is: <repo1>:<develop>

I created a supporting branch on top of it and a new project in sonar of which key is: <repo1>:<feature/a>

I want to create a leak period for PR project of based on branch name like: Leak Period: develop

So I can easily detect what is the difference between those 2 branches as a quality manner.

It is some kinda cross-project differential view? Is it possible to create a QG based on this requirement?

Thanks in advance.

[Cagdas Cirit]

I have checked the DB schema and data, and I think it is not possible without a source code change :(

19 Eylül 2016 Pazartesi 13:38:48 UTC+2 tarihinde Cagdas Cirit yazdı:

[G. Ann Campbell]

Hi Cagdas,

Making this work would be cumbersome. You'd need to initialize the branch project in SonarQube with a baseline analysis of the master branch. (Checkout and analyze master, but with sonar.branch set.) Then you can start your analyses of the actual branch content and either set your leak period to the date you analyzed master, or yes use the branch name as the version and set leak period to previous_version.


Ann

[Cagdas Cirit]

Hi Ann,

So is it possible to make a cross project differential comparison as leak period?

Is the following a correct scenario:

1. Analyse target branch with  sonar.branch. Project key <repo1>:<master>
   
2. Analyse source branch with  sonar.branch. Project key <repo1>:<feature/a>
3. Set leak period (on 2.step project) to  previous_version and parameter is master (sonarqube should find the correct project (leak base) in this case by concatenating key with branch like <repo1>+master)

If it is the case I am totally OK with it.

Please advise.

19 Eylül 2016 Pazartesi 16:52:55 UTC+2 tarihinde G. Ann Campbell yazdı:

[G. Ann Campbell]

Hi,

It's more like this:

1. Analyse master branch with  sonar.branch=featurea. Project key <repo1>:<feature/a>
   
2. Analyse feature branch with  sonar.branch=featurea. Project key <repo1>:<feature/a>

1. Set leak period (on 2.step project) 

Ann 

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://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/xluhfdOKq_4/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/cc4c1772-ec9a-470d-bfcc-8e8f2c48e28e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Cagdas Cirit]

Hi Ann,

As I said before we need to make a cross project differential comparison (between branches) not an inner project comparison between versions. Your suggestion is not a solution for our case.

I need to use branch name as leak period not a version. Sonarqube should use it and dynamically calculate target project key; <project_key> + : + <branch>

Thank you for your response. 

I think I need to browse the source code for a workaround or need to fork the repo for an update.

Regards.

19 Eylül 2016 Pazartesi 22:52:40 UTC+2 tarihinde G. Ann Campbell yazdı:

To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.

[Freddy Mallet]

Hello Cagdas,

There is no real support for branches in SonarQube and we're aware of this big limitation. Using the "sonar.branch" property is just a quick and dirty workaround. This is one of our top priority subject in the upcoming months to provide a full support for branches and so obviously a differential comparison between branches. 

I would not encourage you with the current code base to try providing this support. 

Cheers

Freddy

You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/b7cd0f97-e44c-460e-9978-70e6c81ae316%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Freddy MALLET | SonarSource

Product Director & Co-Founder
http://sonarsource.com

[Cagdas Cirit]

Hello Freddy,

I am really happy to hear from you that upcoming versions of SonarQube will support branches in true manner. 

If you are using git-flow based workflow supported by Pull Requests, this functionality is essential, but as I understand you are already aware of that.

What do you think, is expecting it in Q4 is too optimistic? :)

With my kind regards.

--

Cagdas Cirit 

20 Eylül 2016 Salı 16:19:31 UTC+2 tarihinde Freddy Mallet yazdı:

[Freddy Mallet]

Indeed Cagdas, Q4 is too optimistic but hopefully Q1 of 2017 :)

Thanks for your feedback

Freddy

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/504d7cc7-2eae-4013-8d03-09bc19307781%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Cagdas Cirit]

:) OK, Freddy.

Thanks for your reply.

Cagdas

21 Eylül 2016 Çarşamba 10:38:52 UTC+2 tarihinde Freddy Mallet yazdı:

[Çağdaş Cirit]

Hi Freddy,

Is there any update about the issue?

Thanks.

--

Cagdas

[byron....@openbet.com]

Hi,

We're attempting to use SonarQube with a gitflow like branching strategy and coming across similar issues to this.

Our intention is to ensure that branches being checked into master don't introduce additional technical debt - and would like to utilize the quality gate for this. 

We've updated to version 6.3.1, which has been a big improvement, but still having issues working with branches. 

We've worked around some of these by automatically kicking off a SonarQube analysis at the point a branch is created in order to get a reference point for the branch. 

Issues we still have are:

- Our development branches don't have versioning (master branch does, with the leak period set to previous version it works as needed here) - so it's not clear what to set the leak period to (would setting it to "BASELINE" as suggested in the leak period settings be referring to the first SonarQube analysis on that branch, or would it be looking for a version called "BASELINE").

- Updating a development branch by rebasing/merging from master will cause any issues coming from master be picked up as new issues (even if these were preexisting on master).

On smaller pieces of work these aren't too much of an issue, and it's easy to identify whether the issues are in new work or not - but on larger projects with many files being updated it quickly becomes a lengthy manual process to check. 

Have there been any updates on this or does anyone have any recommendations in working with SonarQube in a GitFlow like branching strategy?

Thanks,

-Byron

[G. Ann Campbell]

Hi,

On Thursday, 6 July 2017 16:39:05 UTC+2, byron....@openbet.com wrote:

We've worked around some of these by automatically kicking off a SonarQube analysis at the point a branch is created in order to get a reference point for the branch. 

This is a great start. When you do this analysis, pass in `sonar.version=BASELINE`. 

 

Issues we still have are:

- Our development branches don't have versioning (master branch does, with the leak period set to previous version it works as needed here) - so it's not clear what to set the leak period to (would setting it to "BASELINE" as suggested in the leak period settings be referring to the first SonarQube analysis on that branch, or would it be looking for a version called "BASELINE").

If you set the leak period to `previous_version` then it will be looking for when the version string changed. If you update your baseline version as suggested above, this should work.

 

- Updating a development branch by rebasing/merging from master will cause any issues coming from master be picked up as new issues (even if these were preexisting on master).

Yup. There's no workaround for this. However, the Issue Resolver plugin would help you keep Won't Fix, False Positive issues synched between master and branches.

 

Have there been any updates on this or does anyone have any recommendations in working with SonarQube in a GitFlow like branching strategy?

Unfortunately, there have not. Branching is rarely far from our thoughts, but life has intervened. 

Ann 

[andrew....@alcumusgroup.com]

Hi Byron

I came across this thread trying to find a solution for the same problem. what you have described sounds like it may work for us? We are using Bitbucket and Bamboo so may be different to your toolset but I am interested to know how you kick off the analysis on branch creation to create the baseline?

Kind Regards

Andrew

[Bharath ganesh kumar]

Hello,

I'm not totally sure about whether this is the right place to share my thoughts & query, however going ahead with it.

I was actually looking for the similar solution where the requirement is to have a leak period set cross project. (since our setup currently has two sonarqube projects for a single BitBucket project - one for PROD statuses i.e. the MASTER branch project && the other for all others [Develop & Release branch])

Actually my organisation uses quite old version of sonarqube i.e. the 5.6.7 and I was having some difficulties using the WebAPI method to set the leakperiod from the Jenkins pipeline script.

I do have an issue where few of the sonar quality issues are not getting baselined. i.e. I run the analysis from master branch and set the version as leak period, however legacy issues are getting popped up in the future analysis when new code is being check in. Surprisingly the Developers haven't touched the files at all in which the quality issues are shown.

It'd be very much helpful if someone could share thoughts on this.

Regards

Bharath

[G. Ann Campbell]

Hi Bharath,

You should upgrade to at least 6.7.3. Your problem with "legacy issues" being reported as new is partially solved in the current LTS. 

For the rest of your questions, please open new threads, one per question.

Ann

[gane]

Thanks much for your update.

Sure I'll start a new thread for any other queries.

Regards

Bharath B