SonarScanner for Maven: Fail build if error occurs

SonarQube Server / Community Build
, ,
1

I am using SonarQube version 8.9.10 and the sonar-maven-plugin version 3.9.1.2184. Is there a way to fail the maven build if some error occurs during the analyis? For example, when I tried to import an errorneous code coverage report, the log says:
[INFO] Sensor JaCoCo XML Report Importer [jacoco]
[INFO] Importing 1 report(s). Turn your logs in debug mode in order to see the exhaustive list.
[ERROR] Cannot import coverage information for file 'src/main/java/com/my/package/myClass.java', coverage data is invalid. Error: {} java.lang.IllegalStateException: Line 44 is out of range in the file src/main/java/my/package/myClass.java (lines: 32)
but the build continues and finishes with ā€œBuild successā€. Also in sonarqube I couldnā€™t find any hint that there was any problem during the analysis. Is there any way to tell the sonar-maven-plugin to fail the build if an error occured? At analysis parameters I couldnā€™t find anything.
Thank you very much for your help.

Best regards
Florian

2

Hi,

Your version is past EOL. You should upgrade to either the latest version or the current LTS at your earliest convenience. Your upgrade path is:

8.9.10 ā†’ 9.9.3 ā†’ 10.3 (last step optional)

You may find these resources helpful:

If you have questions about upgrading, feel free to open a new thread for that here.

If your error persists after upgrade, please come back to us.

 
HTH,
Ann

3

Hello Ann,

thank you for your response. I tried with the LTS version sonarqube-9.9.3.79811 and I still have the effect that the log displays

[ERROR] Cannot import coverage information for file '...', coverage data is invalid. Error: {}
java.lang.IllegalStateException: Line 44 is out of range in the file ... (lines: 32)

but at the end the log says:

[INFO] BUILD SUCCESS

As an explanation for the error: I had the stupid case that two subprojects contained the same class (identical name and package, different content) and when I created an code coverage report with jacoco, jacoco uses the fully qualified class name as a key for the code coverage and the report contained so only the code coverage for the larger class and during the import into sonar, the import fails when sonar tries to match the shorter class with the code coverage of the larger class.
Also in the UI I couldnā€™t see any hint about the problem with the code coverage (I found one warning, because Iā€™m using the property ā€˜sonar.passwordā€™, but nothing else). I have attached my whole log, just in case you need it. sonarLog.txt (15.4 KB)
So do you know if there is any chance to fail the maven build if an error occurs? At the moment I have to analyse the log file of the maven build and fail the build if I discover some messages with log level ERROR, but this seems no perfect solution for me.

Best regards
Florian

P.S.:
I have also tried to run sonarqube-10.3.0.82913, but there I got already during startup a funny exception

Caused by: java.lang.IllegalStateException: jar hell!

You wrote that the upgrade to 10.3.0 is optional, so I focused on version 9.9.3

1 Like
4

Hi,

as long as the sonar maven plugin has no parameter as i.e. strict = true|false or similar
the only way i know is to use the maven enforcer plugin, i.e.

<project>
  [...]
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <executions>
          <execution>
            <id>fail-on-specific-logs</id>
            <goals>
              <goal>enforce</goal>
            </goals>
            <configuration>
              <rules>
                <requireMavenLogMessage>
                  <message>Cannot import coverage information for file</message>
                </requireMavenLogMessage>
              </rules>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  [...]
</project>

Gilbert

1 Like
5

Hi Florian,

Congrats on your upgrade and thanks for the explanation of your situation. Iā€™m glad you got it figured out. Iā€™ll defer to Gilbert on failing the build. And if you have the time/energy to start a new thread with the jar hell error, Iā€™d much appreciate it. I havenā€™t seen that error before, but a quick search indicates itā€™s related to Elasticsearch. Iā€™d like to put it in front of the developers if possible.

 
Thx,
Ann

7

Hi Gilbert, thank you very much for your response, I tried to solve it similarly. But for me it seems strange/wrong to solve it this way and I thought that maybe I missed some configuration parameter for the sonar-maven-plugin. I hoped that if the sonar-maven-plugin knows that something went wrong, that there would be a another possibility to point the user to the problem than scanning the log file. The error was in our log files at least for half a year and was only discovered by pure chance (we didnā€™t know that we had to search for errors in the log; we simply assumed that an error would lead to failed build).

Best regards
Florian

8

Hi Ann,
I just figured out my problem. To start SonarQube I opened an cmd-shell, went into the sonarqube-10.3.0.82913\bin\windows-x86-64 directory and called StartSonar.bat. For SonarQube 9.9.3 this worked perfectly, for SonarQube 10.3.0 I got the jar hell exception. The reason for this seems to be that in my environment the variable CLASSPATH contained among others the entry ā€œC:\winapp\IBM\SQLLIB~2\java\db2jcc4.jarā€. When I unset the CLASSPATH variable, I could start SonarQube without any problems. For me it seems as if there has somethings changed between SonarQube 9.9.3 and 10.3.0 regarding the usage for the enviroment variable CLASSPATH.

Best regards
Florian

1 Like
9

Hi Florian,

of course, youā€™re absolutely right!
Just wanted to save you from implementing your own log parser.

If console log prints =

[ERROR] itā€™s an error and it should fail. Thatā€™s the usual behaviour, if no property like
ignoreErrors = true or similar.

[WARNING] itā€™s only a warning that might - has to be evaluated in context - be ignored.

[INFO] itā€™s a simple information

And if the sonar maven plugin logs an [ERROR] but runs on, itā€™s a bug that should be fixed IMO.

Gilbert

10

Hi Florian,

Thanks for the followup. Much appreciated!

 
Ann