Feature Request: Assign quality profile and quality gate on new projects using project key wildcard

[Jan S]

Hi everyone,

I really like Sonar's permission template feature for project permissions on new projects. It comes in handy, because no Sonar API calls from CI systems are needed - everything is set up in Sonar UI if you have the permissions to do so.

Are there any plans to offer such functionality for quality profiles and quality gates as well?
Currently you have to use the deprecated parameters sonar.profile and sonar.qualitygate (which will be replaced by web services in Sonar 5.2). Or some project administrator has to assign profile and gate manually for every new project (i.e. every new branch) which would be a bit of a pain.

From what I understand a quality gate and quality profile should usually be assigned as follows (please correct me if I got that wrong):
Suppose I'm using a CI platform to trigger analyses.

1. Provision new project using Sonar REST API.
2. Assign a quality profile and quality gate to the project using Sonar REST API. (Which will be available in Sonar 5.2 - until then use deprecated parameters as above)
3. Analyse the project.

Note that in this process if a developer has access to CI job properties, they are able to change quality profile association. This could be prevented by providing a UI-based approach similar to permission templates. Here, only Sonar administrators would be able to change these settings.
That's why I think a UI-based solution similar to permission templates would be useful.

Cheers,
Jan

[G. Ann Campbell]

Hi Jan,

New projects are automatically analyzed with the default profiles for relevant languages, and you can also set a quality gate as the default, so that's probably what you're looking for.

Beyond that, you should be aware that project administrators (people with admin perms on a project but not necessarily on the SonarQube instance) can also edit the assigned profiles for a project.

Ann

[Jan S]

Hi Ann,

thanks for your reply.

If I'm analysing multiple projects on one Sonarqube instance, I might want to have different Quality Profiles / Gates applied to them by default. So using the default values is not an option for me.
Yes, the project administrator can change the quality profile and quality gate. But I put this topic on discussion because changing the Quality Profile or Gate is a *manual* process in the UI. Also, having projects analysed with default settings and changing the profile afterwards, I will get an awkward history of decreasing or increasing issue counts. These would just be caused by the profile change, not by source code changes.

I'd prefer a solution like the permission templates, saying projects with key ".xyz." should be analysed with profile XYZ.

Let's consider a source code project with multiple branches:
com.example (the trunk), com.example.branch1, com.example.branch2, ...
The Sonar project key is almost the same for every branch or at least contains a certain regular expression (com.example). This way I can assign project permissions to all the Sonar projects (i.e. to all branches) which belong to the area of com.example source code project. That was easy! :-)
Now, as I'm assigning these permissions automatically, dont' you think it would be handy to have quality profiles and gates assigned the same way? Why should a project administrator be bothered clicking through the UI and messing up the issue counts history if this could be done with a regular expression?

Jan

[G. Ann Campbell]

Hi Jan,

I really need you to make this reply publicly.

I may not be the best one to respond at this point in the discussion.

Thanks for understanding,

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/gxEnxGiXikw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/bf760d2a-fcdd-43b1-9cc5-650782df91a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[G. Ann Campbell]

Whoops. My apologies, Jan. I'm not used to mail from this group showing up in my inbox.

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

[hen...@halkow.com]

+1

This is exactly what I need for a SonarQube instance that I operate for multiple departments who need to use their own quality gates and profiles. Assigning the projects manually causes a lot of extra work as each git branch is treated as a separate project.

[Michel Pawlak]

Hi,

Concerning Quality Gates, you can assign a Quality Gate to a project using webservices ( http://nemo.sonarqube.org/api_documentation#api/qualitygates )

Concerning Quality Profiles, i could not find a webservice that allows associating a quality profile to a project (but is should not be difficult to do it).

Michel

[Jan S]

Hi Michel,

thanks for your reply. As per SonarQube's JIRA association of quality profiles using a web service will be availible in Sonar 5.2 (http://jira.sonarsource.com/browse/SONAR-5489).

I'll put the essence of my question down again: What do SonarQube developers / architects / UX experts think about a wildcard-based approach for assignment of Quality Profiles and Quality Gates in Sonar UI?

As I mentioned before, one can possibly change Quality Profile and Quality Gate association having access to the job configuration on the CI platform.
If Quality Profiles and Quality Gates were assigned by wildcards - defined in Sonar UI - ALL the permissions and settings regarding Sonar projects would be handled consistently in one single place: the Sonar UI.

Also, I don't really see a point of assigning certain permissions to projects according to their key, but on the other hand setting profiles and gates in a different manner. (Anyway if you would like to do so, you could still call the web service yourself. I guess the web service doesn't really bother about who consumes it - Sonar UI for wildcard-based assignments or a CI system for "fine-grained" assignment.)

So all in all, that's why I labelled my initial email "feature request": I'm wondering whether anyone out there considers this wildcard-based approach useful and what your arguments are. (Thanks Hendrik for your support.)

Best regards,
Jan

[Fabrice Bellingard]

Hi Jan,

thanks for launching this interesting thread, and sorry to jump in a bit late :-)

Having a regexp pattern to define which QP (quality profile) and QG (quality gate) should be used for a given project can indeed seem a good idea. You compare this to the permission templates, which I indeed find very useful.

Still, I would like to take the chance to challenge this idea because I feel that there are some differences that make this comparison less valid as it first seems.

I feel that using regexp patterns to apply permissions can really be useful, because if your project keys are well defined, they can indeed match your organisation - and permissions are indeed linked to how your teams are organised in your company.

For QP and QG, I'm not sure that this would work as well as for permissions though. First, for quality gates, if you have multiple ones, deciding which QG to apply is more linked to the maturity level of your application - which is not bound to a specific department right? So not sure that you can define a regexp pattern to apply to project keys to decide which QG should be used. Then talking about quality profiles, this is even more complex IMO. Indeed, does the project key match the type of the project? In other words, is it possible to know - just by reading the project key, if the "Standard Java Profile" or the "Java 8 Profile" should be used? Or if the "Swing Profile" or the "JEE Profile" should be used?

Still, I agree with the original problem that is: having to manually handle the association between projects and QP/QG is not ideal for big companies. But on my side - at least for now (and such threads are a good opportunity to push new ideas!), I don't know how this human process could be done automatically (using analysis properties was the only option, but we dropped it because anyone who has commit access to the code could change them, leading to several bad side effects).

Best regards,

Fabrice BELLINGARD | SonarSource SonarQube Platform Product Manager http://sonarsource.com

--
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/590abfd0-1d5b-4951-a2b3-4972ba42c734%40googlegroups.com.

[Jan S]

Hi Fabrice,

thanks for your reply. I'm glad you joined the discussion.
I agree that QG association is not necessarily linked to department structure. But going through the manual process, what does an administrator do? - They look at the project name (~ part of the project key) to first of all identify the correct project. Or even a bunch of projects which are just branches of a certain module. The next step is to (bulk?) change QG association if that project has reached such maturity level (including its branches). But for any new (future) branch of the current maturity level I might want to apply this QG as well. So IMO a regexp would do just the same, but in an automated way for all the times when there are no QG association changes and for new branches of the current maturity level. I think the project key should always have a certain part identifying the module/component/service it accounts for, because otherwise there would be collisions of project keys: I'm imagining some modules developed in only one department and the project key containing department-related information only. That way, how would I make a difference between branches of module A and branches of module B if not by a certain naming scheme regarding the project key?
(Are we talking about something like com.department:moduleA-branchA vs. com.department.moduleA:branchA? Or am I thinking too much Java/Maven specific at this point?)

The case of profiles seems similar to me: If I assign a profile manually, I basically have to identify the right project (i.e. read the key + project name). So I'm actually deciding which QP to apply on the basis of the project key. Anyhow I agree with your concerns if we are talking about branches of a certain project, which use the same or a similar key in Sonar: I might want to override the automated (regexp-based) association here depending on what I'm doing in this branch.

To me it feels like regexp-based association would be some kind of "advanced default" for QGs/QPs. Just wondering if this is an advantage that compensates for the development effort of such a feature, because the new quality profile web service somewhat solves this issue. Though, this mechanism seems to drag automated QG and QP association away from Sonar UI towards the CI platform triggering & configuring the analyses.

Best regards,
Jan

[Julien HENRY]

Hi guys,

If your only concern is branches, then my feeling is that when a branch is created (ie first analysis with a new value of sonar.branch) then all settings from baseline should be copied. Not only QP/QG association but also all project/module settings. The only issue here is to identify the "baseline"...

My 2 cents,

Julien

[nico.mo...@gmail.com]

Hey,

what is the status of this problem? Anything still being done for it?

We have hundreds of projects that get a new branch each time we prepare a new release, and we are starting to ramp up our release cycle. Each domain/departement decides for itself what quality profile to use. All our Sonar jobs in Jenkins are automatically created using the jobdsl Jenkins plugin.

But one person has to manually change the quality profile for each project now, this is almost becoming a fulltime job. Regex won't even be a solution because there is nothing to match on between our domains, there is no prefix or something.

I read there is now support in the REST api to attach a qp to a new project but that would mean we have to start scripting to create the new projects beforehand, nullifying the advantage of automatic project creation in Sonar.

There was a great solution for this: sonar.profile, but that is deprecated now for reasons many users do not agree with.

[Fabrice Bellingard]

On Fri, Nov 20, 2015 at 10:24 AM, <nico.mo...@gmail.com> wrote:

Hey,

Hi Nico

 

what is the status of this problem? Anything still being done for it?

We have hundreds of projects that get a new branch each time we prepare a new release, and we are starting to ramp up our release cycle. Each domain/departement decides for itself what quality profile to use. All our Sonar jobs in Jenkins are automatically created using the jobdsl Jenkins plugin.

But one person has to manually change the quality profile for each project now, this is almost becoming a fulltime job.

Why "one" person? In SonarQube, there's a project permission called "Administer". This permission allows to set all the settings of a project, access its history to modify it (versions, events), edit permissions, ... and set the wanted quality profiles and the quality gate. This permission is supposed to be granted to project leaders/managers so that there's no need for a SQ administrator to do this on the behalf of the teams. This is the way to go.

 

Regex won't even be a solution because there is nothing to match on between our domains, there is no prefix or something.

I read there is now support in the REST api to attach a qp to a new project but that would mean we have to start scripting to create the new projects beforehand, nullifying the advantage of automatic project creation in Sonar.

I agree that using the REST api is not the solution. The solution is what I described previously. Creating a new project in SonarQube is not something that should happen everyday, and if the configuration of the permissions is done correctly at day 1, then your problem is gone.

 

There was a great solution for this: sonar.profile, but that is deprecated now for reasons many users do not agree with.

On Wednesday, 15 July 2015 10:51:01 UTC+2, Julien HENRY wrote:

Hi guys,

If your only concern is branches, then my feeling is that when a branch is created (ie first analysis with a new value of sonar.branch) then all settings from baseline should be copied. Not only QP/QG association but also all project/module settings. The only issue here is to identify the "baseline"...

My 2 cents,

Julien

Le vendredi 3 juillet 2015 13:24:20 UTC+2, Jan S a écrit :

Hi Fabrice,

thanks for your reply. I'm glad you joined the discussion.
I agree that QG association is not necessarily linked to department structure. But going through the manual process, what does an administrator do? - They look at the project name (~ part of the project key) to first of all identify the correct project. Or even a bunch of projects which are just branches of a certain module. The next step is to (bulk?) change QG association if that project has reached such maturity level (including its branches). But for any new (future) branch of the current maturity level I might want to apply this QG as well. So IMO a regexp would do just the same, but in an automated way for all the times when there are no QG association changes and for new branches of the current maturity level. I think the project key should always have a certain part identifying the module/component/service it accounts for, because otherwise there would be collisions of project keys: I'm imagining some modules developed in only one department and the project key containing department-related information only. That way, how would I make a difference between branches of module A and branches of module B if not by a certain naming scheme regarding the project key?
(Are we talking about something like com.department:moduleA-branchA vs. com.department.moduleA:branchA? Or am I thinking too much Java/Maven specific at this point?)

The case of profiles seems similar to me: If I assign a profile manually, I basically have to identify the right project (i.e. read the key + project name). So I'm actually deciding which QP to apply on the basis of the project key. Anyhow I agree with your concerns if we are talking about branches of a certain project, which use the same or a similar key in Sonar: I might want to override the automated (regexp-based) association here depending on what I'm doing in this branch.

To me it feels like regexp-based association would be some kind of "advanced default" for QGs/QPs. Just wondering if this is an advantage that compensates for the development effort of such a feature, because the new quality profile web service somewhat solves this issue. Though, this mechanism seems to drag automated QG and QP association away from Sonar UI towards the CI platform triggering & configuring the analyses.

Best regards,
Jan

--

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/0342bc14-1296-44a3-aedf-446d45e74d3c%40googlegroups.com.

[Nico Mommaerts]

I meant one person per domain, but even then it's cumbersome as each domain has dozens of components under its wings. 

"Creating a new project in SonarQube is not something that should happen everyday"

I find that a strange comment, in a day where microservices, agile and git etc are becoming more and more prevalent. New components are being created in our company almost on a daily basis, along with branches of them for each new release. Everything from environment to tooling is automated to handle the lifecycle of the components and applications, except for the quality profile assignment. Everyday is day 1 for us :)

[Christian Galsterer]

Hi,

we are in the similar situation with hundreds of projects using a (micro)service architecture and this new feature would simplify a lot.

As it is not a breaking change I would like to see this feature sooner then later.

br

Christian

[j...@apio.fi]

I agree on this one. New branches should inherit any manual settings from the main branch. Any "false positive" marked in the master must also be inherited to the children. 

Since sonar get's the branch on a separate parameter, it think this should be doable with the projectkey that groups them all together. 

Br,

Jan

[Michael Giroux]

> > we dropped it because anyone who has commit access to the code could change them

Our site has started using SonarQube (5.3).  We integrate with Stash and Jenkins.  Every repository in Stash is configured to start a build upon a new push.  We currently have 1,152 projects in SonarQube representing individual Stash repositories and all the branches waiting on Pull Requests.  We want consistent code analysis across all projects, and we have defined a very limited set of quality profiles for use by our teams.  But more importantly, we have defined a specific profile that is used by release management to assess new release candidates.  This specific profile has a very limited set of rules to allow the release manager to easily identify issues that we have deemed will prevent a release.  So our teams build with a complete profile (Sonar way) and the release manager uses a more refined profile.

The only way to allow for such use is to specify the sonar.profile on the command line.  If this feature is actually dropped, we have no effective way of allowing release managers to focus on the specific issues they care about.

Rather than drop the feature, it would be better (for us) if the feature could be restricted to specific user accounts.

If there is a better way to accomplish this, I would love to hear it.

Michael

[Fabrice Bellingard]

Hi Michael,

On Tue, Jun 7, 2016 at 8:01 PM, Michael Giroux <mlgi...@gmail.com> wrote:

> > we dropped it because anyone who has commit access to the code could change them

Our site has started using SonarQube (5.3).  We integrate with Stash and Jenkins.  Every repository in Stash is configured to start a build upon a new push.  We currently have 1,152 projects in SonarQube representing individual Stash repositories and all the branches waiting on Pull Requests.  We want consistent code analysis across all projects, and we have defined a very limited set of quality profiles for use by our teams.  But more importantly, we have defined a specific profile that is used by release management to assess new release candidates.  This specific profile has a very limited set of rules to allow the release manager to easily identify issues that we have deemed will prevent a release.  So our teams build with a complete profile (Sonar way) and the release manager uses a more refined profile.

SonarQube does not know how to handle what you want to achieve - actually not the way you want to achieve it. For a given source code, there's only 1 project in SonarQube on which analysis reports are processed, one after the other. If you are analysing the source code with profile A all along the development lifecycle, and then at the end you decide to run an analysis with profile B, then the history of your project on SonarQube will be inconsistent. What's more, I'm not sure that this is a good idea that developers and the QA/Release team don't share the same quality requirements for going into production: the teams should all be aligned.

 

The only way to allow for such use is to specify the sonar.profile on the command line.  If this feature is actually dropped, we have no effective way of allowing release managers to focus on the specific issues they care about.

Rather than drop the feature, it would be better (for us) if the feature could be restricted to specific user accounts.

If there is a better way to accomplish this, I would love to hear it.

Our position on this is that everyone involved in a project should follow the same quality requirements and use the concept of quality gate to determine if an application can go into production or not. The quality gate represents the conditions that must be reached to go into production. These conditions can be defined by the Release team. During the development lifecycle, analyses might break those conditions (= the quality gate fails - it's red) but for the application to go into production, then the conditions must be met (= the quality gate passes - it is green). If your Release team wants to enforce some specific rules, then they can make sure that those rules are configured with the blocker severity (for instance) in the quality profile, and then have a "0 blocker issue" condition in the quality gate. This way, everybody is aware of all the *same* requirements all along the development lifecycle. No team can lie to itself about the ability to go into production.

Best regards,

Fabrice BELLINGARD | SonarSource SonarQube & SonarLint Product Manager http://sonarsource.com

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/2da2cea6-ab92-4805-a97f-7e5b6542f883%40googlegroups.com.

[Michael Giroux]

> For a given source code, there's only 1 project in SonarQube

But as I understand it, a branch represents a new source code.  Is this correct?  We see many projects in sonar for the same git repository, one for each branch that has been analyzed.  

>  the history of your project on SonarQube will be inconsistent.

OK, very good point regarding use of different profiles and impact on history.  But I do believe the release management team has a valid requirement.  Keeping in mind that the code is already in production, and has been for years, and was developed long before we started using Sonar, there are hundreds of sonar issues which we are addressing as modules come into maintenance.  So for development, we want the full analysis enabled.

Our release managers have complained that there is no easy way to identify new issues between current release version and a release candidate.  What they want is a profile that includes a fairly limited set of rules such as PCI related, any blocker and a few critical.  This limits the scope of their review to the set of issues that would prevent a candidate from being promoted to production.  Our first thought was a separate profile, but we overlooked the impact on history that you noted.

If it is the case that every branch is a separate project in Stash, it seems (and I could be wrong here) that developers could use one profile for pull requests on branches, and release management could do a build on a "release candidate" branch that uses a different profile.

> Our position on this is that everyone involved in a project should follow the same quality requirements 

I understand your official position for all participants using the same profile, but for an existing code base with millions of lines of code, that approach is very burdensome on release managers, at least here at this site.

> If your Release team wants to enforce some specific rules, then they can make sure that those rules are configured with the blocker severity (for instance) in the quality profile, and then have a "0 blocker issue" condition in the quality gate.

I will definitely review this approach with the team.  This might be the solution, at least for the use case where release managers want an easy way to identify blockers.

I posted a separate question that overlaps a bit with this thread.  I'll go refine that topic a bit based on your very good advice here.

Thanks

Michael Giroux

[Jan S]

Hi everyone,

 

thank you for all your comments and contributions. I'd like to sum up the discussion so far.

 

I feel that these two points sum up the dicussion pretty well:

 

a) There are supporters out there for this feature.

b) "Creating a new project in SonarQube is not something that should happen everyday" (as stated by Fabrice)

 

I'd like to challenge point b) though: Suppose a team develops new features using branches. A reasonable decision would be the GitFlow branching model - because of its vast tool support. As a developer I press buttons to start and finish features and in between I can concentrate on development.

A new branch (e.g. a new feature) in my SCM equals a new project in SonarQube, using sonar.branch analysis parameter. Why? Because I'd like to see code quality measures on my branch and I'd like to see issues before merging back on the development line.

And this is where automated QP assignment in SonarQube could kick in: On a central SonarQube instance hosting a bunch of products (e.g. facilitaed by SonarSource Views plugin) there is no easy way of provisioning this branch.

Which alternatives are there?

1.) Give developers the "provision project" permission and make them copy and paste group id, artifact id etc. for there branch. Which doesn't sound too convenient.

2.) Have a script within the CI platform doing the provisioning against SonarQube REST API. This approach would work but also doesn't feel too convenient.

3.) Use SonarLint in my IDE - which is convenient, but not comprehensive as PMD, Findbugs and Checkstyle rules are missing.

4.) Have SonarQube decide on a wildcard on the project's group id decide on the QP. <- Still my favorite...

 

Maybe we just have different approaches of SonarQube integration in mind. That's why I'm looking forward to discussing this with some of you in Frankfurt tomorrow at SonarSource City Tour.

 

Best regards,

Jan

[G. Ann Campbell]

Hi Jan,

In regard to 

3.) Use SonarLint in my IDE - which is convenient, but not comprehensive as PMD, Findbugs and Checkstyle rules are missing.

I'd like to point out that the vast majority of rules from all three plugins have been replaced in the SonarAnalyzer for Java. So the functionality is only missing if your profile is out of date. ;-)

I know this point is largely irrelevant to the larger discussion in this thread, but I just couldn't let it go by unchallenged.

:-)

Ann

[Fabrice Bellingard]

On Wed, Jun 15, 2016 at 1:55 PM, Jan S <jan.s...@gmail.com> wrote:

Hi everyone,

 

thank you for all your comments and contributions. I'd like to sum up the discussion so far.

 

I feel that these two points sum up the dicussion pretty well:

 

a) There are supporters out there for this feature.

b) "Creating a new project in SonarQube is not something that should happen everyday" (as stated by Fabrice)

 

I'd like to challenge point b) though: Suppose a team develops new features using branches. A reasonable decision would be the GitFlow branching model - because of its vast tool support. As a developer I press buttons to start and finish features and in between I can concentrate on development.

A new branch (e.g. a new feature) in my SCM equals a new project in SonarQube, using sonar.branch analysis parameter. Why? Because I'd like to see code quality measures on my branch and I'd like to see issues before merging back on the development line.

And this is where automated QP assignment in SonarQube could kick in: On a central SonarQube instance hosting a bunch of products (e.g. facilitaed by SonarSource Views plugin) there is no easy way of provisioning this branch.

Which alternatives are there?

1.) Give developers the "provision project" permission and make them copy and paste group id, artifact id etc. for there branch. Which doesn't sound too convenient.

2.) Have a script within the CI platform doing the provisioning against SonarQube REST API. This approach would work but also doesn't feel too convenient.

3.) Use SonarLint in my IDE - which is convenient, but not comprehensive as PMD, Findbugs and Checkstyle rules are missing.

4.) Have SonarQube decide on a wildcard on the project's group id decide on the QP. <- Still my favorite...

 

Maybe we just have different approaches of SonarQube integration in mind. That's why I'm looking forward to discussing this with some of you in Frankfurt tomorrow at SonarSource City Tour.

Excellent Jan, I'll be presenting tomorrow, it will be a pleasure to talk about all this with you :-)

My main points are:

• We want to treat long-living branches as first class citizens in SQ, and this is in our 1-year plan
• We want to add more features to handle short living branches (currently managed through the PR plugins), and this is also in our 1-year plan
• Every stackholder on a project should assess the project quality on the same basis, otherwise it breaks the "Leak" and Quality Gates concept (=> it's easy to lie to yourself if everybody does not use the same quality profiles nor quality gate)

  

Let's talk about this tomorrow Jan!

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/05b8c421-2d5f-4b4c-84df-6f00daba86c2%40googlegroups.com.

[Jan Nylund]

Just wanted to mention my 2 cents here.

Some background:

- We have ~40 developers, working in at least 10 projects in at least 5 languages, all being analysed by SQ.
- All projects are using a branching strategy very similar to GitFlow (branching out in JIRA, merging through PR in Bitbucket Server.) Some projects are using GitHub flow instead, which is essentially the same thing but master + develop is just one branch.

- We want to review Sonar Issues as part of the Code Review, before allowing a Merge.

- Currently, we are trying out the sonar for bitbucket plugin, which is a step on the way, but not perfect..

Since all branches get a new project in sonar, we both miss the possibility to select quality profile, as well as the history for false positives. This is extremely annoying, since for every new branch created, you'll get spammed by sonar about a bunch of old issues that are marked as false positives in the master. This makes the developers immune to seeing the mails, and instead, we are seeing that Issues are not handled properly.

I really hope that the ideas that Fabrice is mentioning would solve this problem. For example, one solution would be to simply group all branches (projects) with the same key into one project, and have a feature inside Sonar to select which is the Base branch. Then all false positives, quality profiles, etc, could be inherited from that higher level project (or from the master branch). 

Br,

Jan Nylund

[Michael Giroux]

> b) "Creating a new project in SonarQube is not something that should happen everyday" (as stated by Fabrice)

In fact new projects are created every few hours at this site.  We do not allow code to be pushed to the master branch.  All changes to a project are pushed to a NEW branch.   Stash notifies Jenkins when the new branch is created, and a build is run on the branch.  The build runs the jenkins sonar plugin which pushes analysis to a new project in Stash.  So contrary to Fabrice, new projects are created quite frequently.

We need a mechanism that allows us to configure a profile based on the project key, which is in our case, maven groupId:artifictId:*  Otherwise, we need to be able to specify the sonar.profile in the maven pom.  

It is easy to agree that once statistics are collected it is a bad idea to change the profile, so I have no problem with locking in a profile on an existing project (disable -Dsonar.profile) but I see now problem with allowing the option (command line, or pom property) if the analysis is causing a new project to be created.

Michael

[Andreas Mandel]

Hi,

I hope I do not just repeat something already said in the long thread. Actually we also desperately demand a "branching" support in a way that for new branch project (all same but new "sonar.branch" property) all settings (quality profiles, quality gates, false positive filters) from the main (sonar.branch = trunk, master, develop, or empty) project are copied over. Not having this gives us a lot extra work plus it is a blocker to mark false positives through the SQ UI.

That said, for the short lived "feature / hotfix / topic" branches we do the approach that we execute a client side analysis only (-Dsonar.analysis.mode=preview with SQ 5.3) on the CI server and use the Jenkins Sonar Gerrit plugin to push the found issues as comments to the Gerrit Changes. The result will never hit the SQ server and will not be in the Database, which matches what we want here - there is no need to store this short living result in the SQ Database but in whatever review tool is used.

Thoughts?

Kind Regards,
Andreas.

[Fabrice Bellingard]

I think my last email perfectly answers your thoughts Andreas! First citizen support in SQ for long-living branches + management of short-living branches using the GitHub/Gerrit/Bitbucket/GitLab plugins that indeed run "preview" analyses which 1/ use the right quality profile of the project and 2/ don't push things to the server.

Best regards,

Fabrice BELLINGARD | SonarSource SonarQube & SonarLint Product Manager http://sonarsource.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/199eb7e3-a7a8-4cb1-b1a8-ec35e28289a7%40googlegroups.com.

[Andreas Mandel]

Hello Fabrice,

thanks for your feedback.

I did not read the new branch (copy) support functionality in your post. :-) - this is IMHO really important.

I assume "use the right quality profile of the project" for the "preview" analysis also includes other relevant project settings like false positives etc.

Kind Regards,

Andreas.

[Jan S]

Hi everyone,

from SonarSource City Tour in Frankfurt I'd like to share one of my main take-aways from the discussion with Fabrice:

I was living in the "SVN world" for quite some time and only recently started using Git. With Git there is very good tool support coming in and finally I can see why problems occurred that only few other people were facing. This might also be caused by the type of branching model you choose.
In essence: Using Pull Requests (PRs) and SonarQube plugins for whichever SCM supporting tool you are using (GitHub, Bitbucket, ...) the problem of creating too many new SonarQube projects (one per branch) should be vanishing pretty quickly. Analyzing PRs means reviewing issues only on actual code diffs between your branch and the development line (master/develop). If SonarQube posts issues to PRs, the review process is pretty clean yet strict.

All in all, for short living branches (feature, hotfix, bugfix, ...) there should only be PR analysis. For long living maintenance branches (if any) Fabrice already mentioned in this thread the plan to make them first class citizens in SonarQube, which of course will come along with a mechanism for Quality Profile assignment. (probably inheriting the profile of the main/parent project?)

For me this also solves the need for Quality Profile assignment by wildcards - replace that approach by PR analysis. I can live with that perfectly, but I'm aware that using SVN without PRs things might be a bit of a hassle.
How do the other supporters of this matter feel about it?


G. Ann Campbell:

> In regard to

>> 3.) Use SonarLint in my IDE - which is convenient, but not comprehensive as PMD, Findbugs and Checkstyle rules are missing.

>

> I'd like to point out that the vast majority of rules from all three plugins have been replaced in the SonarAnalyzer for Java. So the functionality is only missing if your profile is out of date. ;-)

Thank you for coming back on this, I will review our profile to see which rules can be substituted.


Best regards,
Jan Schawo

[Michael Giroux]

Regarding "preview" analysis.  Our site uses the Stash (BitBucket Server) "sonar4stash" plugin to display sonar issues in pull requests.  If the preview mode is used, the issues are not pushed to SonarQube. How do the issues show up in the Pull Request?

Currently, the sonar4stash plugin has an option to delete the project from SonarQube when the branch is merged suggesting that the data must reside in SQ for the PR data to be available.  I do not see how preview mode helps this problem.

Michael

[Fabrice Bellingard]

Hi Michael,

I've described our position at SonarSource regarding this topic. What other software vendors do with SonarQube is not necessarily aligned with our vision, and this is exactly the case of this "sonar4stash" plugin. You can't assume that "data must reside in SQ for the PR data to be available" just because this software vendor decided to implement a product which tries to solve the "branch analysis" topic this way. We say that:

• yes, for long-living branches, data should be indeed available on the SQ server
• no, for short-living branches, it should remain on the code review tool side where it is best located (this is where developers do code review) in order to not "pollute" the server with transient information => this is what the "preview" mode allows. Obviously, when you don't have a SQ integration with your code review tool (or when you just don't have a code review tool), then it's less easy to put this in place. This is in our plan to find the best way to cover this use case for most people.

Best regards,

Fabrice BELLINGARD | SonarSource SonarQube & SonarLint Product Manager http://sonarsource.com

--
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/aa634414-06ef-431d-8d93-4b5232df2b19%40googlegroups.com.

[Michael Giroux]

OK, this explains a bit.  I was not aware that there was not direct coordination of these tools.  I will contact the sonar4stash project developers to make them aware of this.

Michael

[Alexis Kochetov]

Hello, Michael, Have you talked with sonar4stash team about this issue?

[Michael Giroux]

Not yet.

Sent from my iPad