Cannot delete Built-in profiles with zero rules

Hello,
Yesterday I upgraded SonarQube from 7.1 to 7.3. I had to uninstall some plugins because they are incompatible. One of the uninstalled plugins has introduced 4 built-in quality profiles. Right now all have 0 rules. Unfortunately, I couldn’t remove them because they are built-in profiles.

How could I remove them without executing SQL commands? If it is impossible, could you clean them automatically (by database cleaner)?

2 Likes

Hey Adam,

I feel like this relates to behaviour described in SONAR-10363, however not entirely sure at this stage whether that explain what you’re observing (especially as ticket was fixed in 7.2). I let you go through it already though, see if it prompts some thoughts.

I don’t see any commits or comments (except an one that it has been tested and works correctly), but I found this:

I see it checks a default quality profile. My empty quality profiles are not default. I think the error path is different:

  • SONAR-10363:
    • stop the server
    • uninstall a plugin which defines a built-in quality profile which is also a default quality profile
    • install a new plugin which defines a built-in quality profile
    • start the server
      SonarQube chooses a new default quality profile because the old one has zero rules. It also deletes the old one.
  • my case:
    • stop the server
    • uninstall a plugin which defines a built-in quality profile which is not a default quality profile
    • start the server
      All default quality profiles have not been changed. The selectDefaultBuiltInProfilesWithoutActiveRules doesn’t return any of my empty quality profiles because they are not default. Finally, none of them have been removed.

Hi,

Thanks for finding and reporting this Adam. I’ve created

SONAR-11256 - Built-in profiles from deleted plugins are zombies

Ann

Hi Ann,
Thank you for the ticket. I have an one solution proposal. If you afraid of removing profiles (inheritance problems etc.), then maybe you could only remove built-in flag from those profiles? System administrators would be able to remove them by themselves :slight_smile:

1 Like

I agree that that’s a potential solution Adam. :slight_smile:

Feel free to add it in a comment on the ticket.

1 Like

Hello @ganncamp, Active zombie profiles with no rules confuse the users and also allows them to select those profiles for the projects they own to bypass quality gates. This is very problematic. We are on 8.9 LTS.

Do you know if this issue ( SONAR-11256) will be prioritised and assigned to someone? It has been more than 3 years and it has not been looked into. I also posted on the issue itself in March 2021, but didn’t get any response.

Is it possible to get this one looked at? Simply speaking, a setting that will control whether quality profiles with no rules are visible or can be used in projects would solve the most if it.

Saurabh

1 Like

Hi Saurabh,

As you’re aware, this ticket is still open in the backlog. It’s not high priority and I can’t give you any kind of ETA on it, but your comment on the ticket is helpful in gaining ‘traction’ to eventually get it fixed.

 
HTH,
Ann

Hi Ann,

Thank you for your response.

To provide better understanding, we are really not that concerned with dead profiles on the Quality Profiles page. But we do not want our users to be able to select a profile with no rules for their projects.

Any of the two simple options would do the trick without going into the rather complex matter of removing built-in flag from the profiles. First one seems a rather clean and a very natural approach to me.

  1. Ability for admin to deactivate a non-default and/or non-sonar profile and prevent non-admin users from seeing the deactivated profiles.
  2. Ability for admin to specify whether or not the profiles with zero rules can be used in projects.

I hope it makes sense to you and that the issue is soon put on the roadmap for an upcoming release.

Best
Saurabh

Hi Saurabh,

I totally get that. To flesh this out a little, is it something you’ve already experienced, or are you being proactive? And if the former, would you characterize the action as accidental or … “crafty”?

And for a little more context, I’m guessing you’re in a very large organization?

 
Thx,
Ann

Hello Ann,

Knowing our user base, we need to be proactive. I like to believe that (we) programmers are always “crafty” as that’s the demand of the job.

Yes, in deed. We are a large IT services organisation and my group is part of one of the many business units, focusing on Salesforce projects (Apex, JS etc.). We have two SonarQube instances running - an older Community Edition and the latest Enterprise Edition 9.3. CE has been running for many years, while EE is a couple of years old and hasn’t seen much adoption in comparison to the CE one, due to lack of Apex rules etc.

We intend to sunset the CE in a few weeks time and before we do that, we want all the CE projects and users to migrate to EE. There will be a large number of projects and users using EE once the transition is complete. And we want to be ready to enforce code quality analysis without giving the projects/users the ability to bypass this using the Zero rule profiles. These profiles were left there when we uninstalled the CheckMark plugin that was in use previously.

I hope I am not causing much confusion and that I was able to clarify why we need this.

Best,
Saurabh

Hi Saurabh,

No confusion at all! This additional context is very helpful and elevates the topic from a minor annoyance to a potentially more serious issue. Because of that, I’m going to give it a nudge internally. No promises tho.

 
Ann

1 Like

Hi Ann,

Much obliged!

No promises needed. I think, you considering this a more serious issue itself would help in getting this over the line with one of the upcoming releases. :crossed_fingers:

Best
Saurabh

Hello Ann,

we observed that on the sbaudoin/sonar-yaml: SonarQube plugin to analyze YAML files (github.com).
Seems like the built-in profile was renamed from “Sonar way” in 1.5.x to " YAML Analyzer" in 1.7.0 - propably to make obvious that’s a 3rd party built-in profile and not from your company.

Hi @milbrandt,

I think I’m missing something here. Could you be more explicit?

You somehow ended up with a ghost/empty profile when a plugin renamed its default profile?

 
Ann