Unable to suppress branch issue because drop down option missing

  • SonarQube Developer Edition Version 7.7 (build 23042), sonar-maven-plugin:3.8.0.2131:sonar, for full plugin list see next message
  • what are you trying to achieve: to get a green analysis in SonarQube
  • what have you tried so far to achieve this: see below

Issue is similar to Unable to suppress pull request issue because drop down option missing but in my case it’s an Java project and the external analyzer is Checkstyle. I did not find a configuration in SonarQube to disable external analyzers.

I am able to reproduce the issue by this change in the .gitignore file:

diff --git a/.gitignore b/.gitignore
index 015d6d77f..656fbda24 100644
--- a/.gitignore
+++ b/.gitignore
@@ -22,6 +22,3 @@ hs_err_pid*
 # Include Groovy binaries
 !groovy-*/bin
 !groovy-*/**/*.jar
-
-# Sharpen working directories
-sharpen

About 3K new issues have appeared. The bulk of them are about lines longer than 80 characters. Our internal coding standard is 120 characters. We have since long activated the rule squid:S00103 and configured it accordingly. We have since long deactivated the rule checkstyle:com.puppycrawl.tools.checkstyle.checks.sizes.LineLengthCheck because it is a duplicate. However these new issues have a different rule ID: checkstyle:sizes.LineLengthCheck. This rule cannot be found in the SonarQube rules. The issues are at status Open and there is no drop down to change them to Won’t Fix. Normally rules have a little link icon next to their rule ID that brings you to their detailed rule page, these don’t.
I have verified the imported checkstyle-result.xml file and it contains errors com.puppycrawl.tools.checkstyle.checks.sizes.LineLengthCheck but no errors sizes.LineLengthCheck. So it is unclear to me where these issues come from, and why they appear on the commit after the commit that made a change to .gitignore.

In trying to reproduce the issue, I created a new branch and merged in all the commits one by one and did a SonarQube analysis each time. This time, on the commit after the commit that changed .gitignore, I did not get 3K issues but over 10K issues, including “regular” SonarQube issues that do have corresponding rules and that can be closed. So about 7K closeable issues and 3K uncloseable issues. The 7K extra issues are years old and are technical debt that we in the past have accepted as-is, but now these issues are resurfacing.

After reverting the .gitignore change, all issues are gone again.

List of all installed SonarQube plugins:

3D Code Metrics 3.7
Checkstyle 4.27
Dependency-Check 1.2.6
Findbugs 3.11.1
Git 1.9 (build 1725)
Groovy 1.6
Issue resolver 1.0.2
JApiCmp Plugin for SonarQube 0.1.0-RC1
JaCoCo 1.0.2 (build 475)
Java I18n Rules 1.0-SNAPSHOT
LDAP 2.2 (build 608)
Mutation Analysis 1.5
PMD 3.2.1
Rules Compliance Index (RCI) 1.0.1
SVG Badges 3.0.1
ShellCheck Analyzer 2.2.1
SoftVis3D Sonar plugin 1.1.0
SonarABAP 3.8 (build 2034)
SonarC# 7.15 (build 8572)
SonarCFamily 6.3 (build 11371)
SonarCSS 1.1.1 (build 1010)
SonarHTML 3.1 (build 1615)
SonarJS 5.2.1 (build 7778)
SonarJava 5.13.1 (build 18282)
SonarKotlin 1.5.0 (build 315)
SonarPHP 3.0.0.4537
SonarPLSQL 3.4.1 (build 2576)
SonarPython 1.14.1 (build 3143)
SonarRuby 1.5.0 (build 315)
SonarScala 1.5.0 (build 315)
SonarSwift 4.1 (build 3087)
SonarTS 1.9 (build 3766)
SonarTSQL 1.4 (build 3334)
SonarVB 7.15 (build 8572)
SonarXML 2.0.1 (build 2020)
Vulnerability Analysis 7.7 (build 4011)
Vulnerability Rules for C# 7.7 (build 4011)
Vulnerability Rules for Java 7.7 (build 4011)
Vulnerability Rules for PHP 7.7 (build 4011)
YAML Analyzer 1.4.3
jDepend 1.1.1

I made this change to pom.xml, while keeping the change to .gitignore:

diff --git a/pom.xml b/pom.xml
index ceccfa467..e36bbdd60 100644
--- a/pom.xml
+++ b/pom.xml
@@ -288,6 +288,9 @@
                 </configuration>
               </execution>
             </executions>
+            <configuration>
+              <skip>true</skip>
+            </configuration>
           </plugin>

This resulted in 7K issues, all of them several years old, that can be closed as Won’t Fix, which is what I am currently doing (one can only close 500 at a time).

From all of this, I can distill two major issues:

  • A seemingly unrelated change to .gitignore suddenly triggered SonarQube to detect thousands of issues that may have been dormant for years.
  • There is a mismatch between the IDs of issues as detected by CheckStyle and reported in checkstyle-result.xml (checkstyle:com.puppycrawl.tools.checkstyle.checks.sizes.LineLengthCheck) and the IDs of those same issues as displayed in SonarQube (checkstyle:sizes.LineLengthCheck). Had there been a proper 1-to-1 mapping of those issues, then SonarQube would have recognized them in it’s Rules database and I would have been able to close them.

It’s not just CheckStyle, it also happens with external issues imported from PMD. So I also had to tell Maven to skip PMD.

I think I found an answer to the .gitignore thing: apparently SonarQube takes that file into account when selecting files to analyze. Fair enough.

That still leaves the issue of Checkstyle and PMD issues, found by their external analyzers (Maven plugin), that have corresponding rules in SonarQube, but the external issues aren’t matched with SonarQube so that it is not possible to take any action on them.

Hi,

I feel like I’m coming late to the game here. :smiley:

First it’s incumbent upon me to point out that 7.7 is past EOL & you should upgrade immediately. Your upgrade path is

7.7 → 7.9.6 → 8.7 (last step optional)

To answer your concern, we import “external” issues as a convenience and since they’re raised externally the expectation is that you manage them (tune which rules run &etc) externally as well.

AND there are SonarQube plugins for Checkstyle & PMD which would allow you to add those rule to your SonarQube Quality Profile. The issues would then be … “internal”(?) issues with full functionality.

 
HTH,
Ann

We can’t upgrade beyond 7.7 yet because the current database is MySQL and that is no longer supported. We can’t just switch to a different sort of database without help from our IT team. It’s been on the backlog for a while.

As you can see in the list of plugins that I posted, the following plgins are installed:

Checkstyle 4.27
PMD 3.2.1

Hi,

What you’re reporting is an “external issues” experience, which indicates that while you have those plugins installed, you’re not making use of them; rather than running those rules as part of the SonarQube analysis, you seem to be running them as a separate process before analysis & importing their reports. Flip that & you’ll get the functionality you expect.

 
HTH,
Ann

Our understanding and usage of SonarQube has always been:

  • Run external analyzers: Checkstyle, PMD, Spotbugs, dependency-check,…
  • The external analyzers will produce XML reports in the target directory
  • SonarQube will pick up these XML reports and use the found issues to “enrich” its own analysis, in combination with rules from SQ plugins for these external analyzers.

Up until the day before I posted my question, we have always worked as such, and now “suddenly” (I can’t find any change from our side) it works differently.
The only thing that I can think of, is that we use mvn sonar:sonar and that has recently had a new release, from 3.7.0.1746 to 3.8.0.2131. As we don’t use an explicit version for sonar:sonar, this has been an automatic upgrade.

Now you write

Please confirm or correct me:

  • Do NOT run external analyzers
  • Run SonarQube analysis, SQ has plugins installed
  • Run external analyzers AFTER SonarQube

This begs the question: if we consider SonarQube to be our “single source of truth”, then what’s the use of even running any external analyzers at all, if they have a corresponding SonarQube plugin? We could axe a lot of external analyzers, thus significantly simplifying our builds, and make them go faster too.

If you can confirm or correct my understanding of your answer, that would be great.

Hi,

Uhm… as far as I’m aware that’s only worked for the last couple years

But never AFAIK like that^

Either you’re running the 3rd-party analyzers during analysis using rules configured through SonarQube, or you’re getting external issues.

:tada:

Sorry to be silly, but that’s exactly it. Since you already have plugins installed for all(?) the extra analyzers you want to use, simply add those rules to your profile(s) (Note you didn’t mention this step, but it’s mandatory to get what you want) and axe :axe: all the other runs.

 
HTH,
Ann

I didn’t mention adding SonarQube rules from SonarQube plugins but yes, effectively that is the case.

To further clarify, because I want to be sure that I understand this 100%. Sorry if I am too verbose.

This is our current setup:

We execute

mvn verify

In the pom.xml, the following Maven plugins are configured to run during the verify phase:

  • Checkstyle
  • PMD
  • Spotbugs
  • Dependency-Check

Then, later in the build, this is executed:

mvn sonar:sonar

So if I understand you correctly, what we need to do, is to delete from pom.xml the configuration of all the aforementioned analyzers, and we will still get exactly the same result as before? Is this true for all analyzers? I’m not sure abou that, because at least for Dependency-Check, it says on the GitHub repo:

This SonarQube plugin does not perform analysis , rather, it reads existing Dependency-Check reports. Use one of the other available methods to scan project dependencies and generate the necessary JSON or XML report which can then be consumed by this plugin. Refer to the Dependency-Check project for relevant documentation.

Source: GitHub - dependency-check/dependency-check-sonar-plugin: Integrates Dependency-Check reports into SonarQube

SonarSourcer Colin wrote on this forum in September 2019:

SonarQube, natively, cannot run PMD and Checkstyle, only consume the reports those tools generate. You’ll need to run those tools to generate the reports prior to your SonarQube analysis. Adding the analysis parameters won’t do that for you.

Source: How to integrate pmd and checkstyle using sonar-project.properties

In the Official SonarQube Documentation about Third-Party Issues, it says:

SonarQube doesn’t run your external analyzers or generate reports. It only imports pre-generated reports. Below you’ll find language- and tool-specific analysis parameters for importing reports generated by external analyzers.

Source: Importing Third-Party Issues | SonarQube Docs

So I’m really confused now. I understand that you are saying “don’t run external analyzers, SonarQube will run them during analysis”, and all the documentation I can find, says the exact opposite.
I don’t want to imply that you are wrong, what I’m trying to say is, I have trouble in understanding what you mean. English is not my first language so something might get lost in translation.

Hi,

Yes, you should be able to fully replace the pre-run of these analyzers by enabling the relevant rules in your Quality Profile.

I’m glad you listed out your 3rd-party analyzers explicitly, because IIRC this one will still need to be run before analysis.

This is true but incomplete. Maintainers of those other analyzers have also maintain SonarQube plugins which, during analysis, invoke their analyzers. From the SonarQube PMD Plugin README

Usage

Usage should be straight forward:

  1. Activate some PMD rules in your quality profile.
  2. Run an analysis.

AND, yes we will import PMD issues from a pre-generated file as external issues. We added that as a convenience for those people who for whatever reason don’t want to manage their rule sets for those external analyzers within SonarQube. So it’s down to what experience you want, and from your initial complaint you seem to want the fully-integrated experience you get with rules managed inside SonarQube.

Just to be really clear, SonarQube analysis won’t natively run an external process to generate a file to then be consumed by SonarQube analysis. AND when you install a plugin for a 3rd-party analyzer, that plugin is generally going to run its own, extra analysis as part of SonarQube analysis. And if it doesn’t its documentation should clearly state what you need to do to make it work. Or at least that’s what I expect of plugins available through the Marketplace.

Does this help?

 
Ann

Thank you! Yes! This helps.
It would really help if this would be made as obvious in the documentation, as you have written here.
I’ve shared this with our team and we’ll think about how to continue. For the QA team, it’s enough to have it in SonarQube only, but our dev team may still want the external analyzers in Maven builds. I’m waiting for feedback on that.

I found one more external analyzer that is run as a Maven plugin, generates a report, has a SonarQube plugin and has SonarQube rules that are activated: japicmp. This plugin creates new issues in SonarQube based on available XML reports of the maven plugin of japicmp.
Sonar-japicmp-plugin currently has a bug, which I have reported in December 2020, and it looks like the SonarQube plugin of japicmp is no longer maintained. I know that this is not a concern of SonarQube, I’m just giving the information.
I know that SonarQube maintains a table of compatible plugins at Plugin Version Matrix | SonarQube Docs and japicmp isn’t in there. Does that mean that the japicmp plugin is not compatible? Or that there simply isn’t any information available?

Hi,

I’m glad you’re working through this. :smiley:

It means the maintainers of that plugin never requested that their plugin be added to the Marketplace.

 
Ann

At first glance it looks like, with the 3 aforementioned Maven plugins removed, SonarQube does not find less but more issues.

Compare:

(It’s open source so I am permitted to share these links - anyone could clone the GitHub repo and do the same analysis on their own infrastructure.)

The additional issues found by SonarQube, come from the SonarQube plugin fb-contrib.

More is better, I guess?

Please also note that for the Maven plugins, we are able to use the latest versions, but for the SonarQube plugins, we are stuck with the versions that are compatible with our SonarQube version 7.7 (which is End of Life).
That might explain some of the differences.