Share your experience on the integration of SonarCube and SonarCloud

[ShellyXueHan]

Hello SONARers!

I'm here to collect feedback, insights and knowledge base from your experience using SonarCube and SonarCloud!

Background:

SonarCube has been a community supported common component that many teams use for their code quality checks. Recently several teams have also started exploring with the SonarCloud. Due to a set of feature and integration differences the two offers, some teams continue using SonarCube while some others migrated to the cloud service. Here are the great work done to document the usage of both tools. What's missing is some more guidance on which one to pick when new teams onboard. As there are a lot of work and research done already, let's not waste it and form this knowledge base.

Action!

Please provide your thinks with the following format:

We are using Sonar[Cloud | Qube]
Reasons for going with this are:
- 
Pros:
- 
Cons:
- 
Other thoughts and ideas:
- 

Example:

This is some information gathered:

We are using SonarQube
Reasons for going with this are:
- The deciding factor was that we use NET Core for our backend and SonarCloud doesn't provide automated scans of "compiled" languages (C# or Java)

Pros for SonarQube:
- Integration with ZAP Scanning

Pros for SonarCloud:
- I liked the feature that checks every PR and emits a report in the PR

Cons for SonarCloud:
- doesn't provide automated scans of "compiled" languages

Other thoughts and ideas:
- Wondering how to setup projects in sonarcloud for monorepos to have multiple dashboards/reports within a single "sonar project"?

[wenzowski]

Clarification: this is related to the SonarCloud automated scanner or the SonarCloud server replacement for SonarQube server? Two very different things.

We are using SonarCloud for the CAS GGIRCS project.

Reasons for going with this are:

Pros:

• our scan results are published publicly for all to see
• our scan results are collected in a single org-wide dashboard
• our pipeline is driven by status checks (the jenkins build-breaker plugin rotted out)
• we need to have some budget left to build apps; we already have lots of services to maintain

Cons:

• loss of sovereignty
• some release management & communication issues (though all issues nicely resolved)

Other thoughts and ideas:

• our full scans for our STRA have been conducted with a commercial product not ZAP
• we would still benefit from a full ZAP scan with xml report uploaded to Sonar (cloud or otherwise)
• the SonarQube Runner reports equally well to SonarCloud and soverign SonarQube

cc @matthieu-foucault @Maralsotoudehnia @NickCorcoran correct me here if I'm off base

[ShellyXueHan]

@wenzowski thanks for your feedback! Please correct me if I'm wrong, I got the understanding that with SonarCloud integration, teams do not need to host the either server or scanner anymore. Can you elaborate a bit on 'loss of sovereignty'?

[GeorgeWalker]

We are using SonarQube with a stable version 7 image.
Reasons for going with this are:

We can easily install the plugins we need to scan our C# (dotnet core) and angular application.

Pros:

Sonar results have been used to complete STRA, WAVA activities.
Sonar has been running fine for several years, with little training required for the team.

Cons:
None so far.

Other thoughts and ideas:

I did try the stock image supplied by the platform but it was too dated at the time and it was easy to simply run the latest stable V7. At some point we may upgrade the image to V8 but it is not a priority.

[Sybrand]

We are using SonarCloud

Reasons for going with this are:

Pros:

• It just works.
• Don't have to maintain our own SonarQube instance.
• Works beatifully with github actions.

Cons:

• Lose some ability to tinker with settings.
• ZAP scan plugin would be nice.
• Had to do some extra work to get code coverage working - but still a lot easier than bothering with SonarQube.

Other thoughts and ideas:

• Love getting to use SonarCloud. Our project simply isn't big enough at this point in time to warrant the investment of spinning up and then maintaining our own version of SonarCloud.
• We run a Baseline ZAP scan in github actions, as nice as it would be to have a Zap scan report in SonarQube, we can live without it.

[wenzowski]

teams do not need to host the either server or scanner anymore

If teams wish to customize the scanner with plugins they must continue to run it from their own CI infrastructure, and configure the scanner to report to the sonarcloud server url for the project exactly the same as before. The official github action just runs the same SonarScanner we're all familiar with. The automated scanning of supported languages is super helpful and helps get started quickly, and under the hood is just running that same SonarScanner for free on infrastructure sponsored by SonarSource. The committed-in-repo sonar-project.properties file can be used to customize the auto-configuration behaviour of SonarScanner for supported languages running on SonarSource infrastructure.

Can you elaborate a bit on 'loss of sovereignty'?

Yes, by migrating the sonar-server component of SonarQube from the free software running in our sovereign pathfinder cluster to free software running on a free 3rd party cluster sponsored by SonarSource we don't have direct control over release management, backups, or business continuity.

I'm not talking about the data sovereignty provisions of FOIPPA here: all this information is derived from public data and published as public data. Since we didn't have a managed shared service to begin with, it's not much of a loss in my opinion. In fact, I also see the effect as a huge value-add: one less thing that can distract from delivery of business value.