Feature request - copy / clone project

[pavel.s...@morosystems.cz]

Hi all,

we are using SonarQube in our company and have the following situation:

• Git as version control
• code review flow based on pull requests (to be approved, the code to be merged must pass the Quality Gate)
• we have several legacy projects with long history with hundreds of issues of severity Major or above
  
• projects are tested and in production => we cannot simply fix the issues without significant effort and regression testing
• we address the issues step by step in smaller batches => this results in Sonar analysis ending up with above Major issues and failing Quality Gates

Even though we have old issues in the projects, we want the continuous Sonar analysis to prevent new issues being brought in. Therefore, we mark the old issues as won't fix so that the project passes the Quality Gate - we want it to fail only in case new issues appear.

We end up with a project in SonarQube with sometimes complex issue settings (marked as won't fix etc.). The Sonar analysis is usually triggered by Jenkins on the main development branch (lets say master).

Now a developer comes in, creates a feature branch, implements the feature and creates a pull request. Both the code reviewer and developer are supposed to run the Sonar analysis against the feature branch (with sonar.branch property set). This creates a new project in the SonarQube (which is desirable) but this is where our troubles come into play. Even though the developer did not introduce new issues implementing the feature, the analysis fails the Quality Gate because of the legacy issues not marked as won't fix.

Of course, the developer can run the analysis first on the clean feature branch, mark all issues coming from master as won't fix... BUT, this leaves our code quality process at the mercy of developer being honest - nothing prevents him to mark newly introduced issues as won't fox...

So, it would be really great to be able to clone the project in SonarQube with new project key => ALL the issue settings would be in place in the new project.

I googled a bit and it seems that there is no possibility to do this (clone a project - http://stackoverflow.com/a/33625537/5048604). I can image that it really wouldn't be very complex task to implement such functionality.

Or is there some misunderstanding or misuse of SonarQube in our code quality process? Can our goal be achieved with the SonarQube as is?

Thanks a lot for reply.

Regards

Pavel

[G. Ann Campbell]

Hi Pavel,

Your situation with a hoary old project with many production-tested issues is exactly why we advocate paying attention mainly to the Leak Period. Let's say that you set your leak period to previous_version and update your Quality Gate to use not absolute values but changes in the leak period. That highlights for remediation newly-introduced issues, and keeps you from having to deal with old issues at all - until you're ready to. 

However, setting the leak period to previous_version doesn't really help with your feature branch problem. 

We know there are issues (no pun intended!) with how we (don't) handle branches. It's on our list of "important things" but it's a big topic, and it's not currently on our short list. However, it should still be possible to find an acceptable answer for you in the short term.  

But a little sleight-of-hand might be required. Let's say I'm going to create a feature branch. The first thing I do is create my Git branch and analyze it to lay down a baseline. Then there's a choice: update the version string for my branch to "my_feature_branch" (or some such), or update the leak period for the branch project to "since [today's date]" and wait a day before analyzing any changes. Either way, that should keep existing issues out of the Leak Period and give you a fighting chance to pass a Quality Gate that's Leak Period-based. (Note that I haven't tried this myself, so some tweaks to the scheme might be required.)

HTH,

Ann

[pavel.s...@morosystems.cz]

Hi Ann,

thanks for quick answer. I will look into what you've suggested and see if it can help us.

I still think that project cloning is worthy feature that wouldn't require significant effort. Regardless our particular issue with branches, I think it can be useful and is by far nothing as complex as bringing branch handling to SonarQube :)

Thanks for your help, it's really appreciated.

Pavel

Dne pátek 6. května 2016 15:09:28 UTC+2 G. Ann Campbell napsal(a):

[G. Ann Campbell]

BTW, I should have mentioned pull request analysis. This is available with GitHub and a couple other major providers. This is how we manage most issues on feature branches internally, but it doesn't cover all types of issues (such as duplicated blocks or test coverage).

Ann

[pavel.s...@morosystems.cz]

Looks VERY interesting. We are using BitBucket but there seems to be a BitBucket plugin for SonarQube that does exactly the same.

Thanks!

Pavel

Dne pátek 6. května 2016 15:46:21 UTC+2 G. Ann Campbell napsal(a):