Generic issue report reading fails for missing file

Versions:

  • SonarQube 9.9.1
  • sonar-scanner: 4.8.0.2856
sonar-scanner -v
INFO: Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
INFO: Project root configuration file: /builds/incharging/iac/sonar-project.properties
INFO: SonarScanner 4.8.0.2856
INFO: Java 11.0.19 Alpine (64-bit)
INFO: Linux 5.4.241-150.347.amzn2.x86_64 amd64

I’ve identified that for SARIF reports if the sonar.sarifReportPaths=no-file.sarif has a file that doesn’t exist, it will show an error, like:

WARN: Failed to process SARIF report from file 'no-file.sarif', error: 'Failed to read SARIF report at '/builds/incharging/iac/no-file.sarif''

and the sonar-scanner process will finish correctly and upload the others reports to SonarQube.

However, for Generic Reports with a file that doesn’t exists sonar.externalIssuesReportPaths=no-file.json the sonar-scanner fail

ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: Failed to read external issues report '/builds/incharging/iac/no-file.json'
        at org.sonar.scanner.externalissue.ReportParser.parse(ReportParser.java:45)
        at org.sonar.scanner.externalissue.ExternalIssuesImportSensor.execute(ExternalIssuesImportSensor.java:72)
        at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:88)
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:61)
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:79)
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:61)
        at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(SpringModuleScanContainer.java:82)
        at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
        at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
        at org.sonar.scanner.scan.SpringProjectScanContainer.scan(SpringProjectScanContainer.java:403)
        at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(SpringProjectScanContainer.java:399)
        at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(SpringProjectScanContainer.java:368)
        at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
        at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
        at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(SpringGlobalContainer.java:137)
        at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
        at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
        at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
        at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
        at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
        at com.sun.proxy.$Proxy0.execute(Unknown Source)
        at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)
        at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
        at org.sonarsource.scanner.cli.Main.execute(Main.java:126)
        at org.sonarsource.scanner.cli.Main.execute(Main.java:81)
        at org.sonarsource.scanner.cli.Main.main(Main.java:62)
Caused by: java.nio.file.NoSuchFileException: /builds/incharging/iac/no-file.json
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
        at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
        at java.base/java.nio.file.Files.newByteChannel(Files.java:371)
        at java.base/java.nio.file.Files.newByteChannel(Files.java:422)
        at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420)
        at java.base/java.nio.file.Files.newInputStream(Files.java:156)
        at java.base/java.nio.file.Files.newBufferedReader(Files.java:2839)
        at org.sonar.scanner.externalissue.ReportParser.parse(ReportParser.java:42)
        ... 31 more
ERROR: 
ERROR: Re-run SonarScanner using the -X switch to enable full debug logging.

Is there an option to ignore non-existing files on externalIssuesReportPaths and not fail the whole sonar-scanner process?

Hi,

There’s not an option to not fail on missing files in Generic Issue Report processing. It’s a fail-fast mindset.

Why is SARIF processing not also fail-fast? Good question. Perhaps it should be.

 
Ann

Let me share a use case, maybe is easier to understand.

On my pipeline I have a job called sq-send-report to send reports from previous jobs. These jobs generate Generic Issue Report, SARIF each job generate different report format.

The sonar-project.properties contains:

sonar.externalIssuesReportPaths=job1.json, job2.json
sonar.sarifReportPaths=job3.sarif

However, the job2 only runs if there are changes on some files, otherwise don’t need to run the scan and generate the reports.

Which means, when the job2 is not included on the pipeline, because no changes on the files job2 files, the sq-send-report fails because the job2.json doesn’t exist.

The same situation I have with job3, however, when the job3 is not included on the pipeline, the sq-send-report doesn’t fail, it just ignore that the job3.sarif doesn’t exist

Hi,

So it’s not that the reports reference missing files, it’s that the report files are missing.

Yes, this was definitely a fail-fast choice. And again, I’m not sure why it’s inconsistent. I’d say you need to conditionally populate those property values. Perhaps you can pass them on the analysis command line with a dynamic value.

 
HTH,
Ann

Yes, the report file is missing. It would be nice if sonar.externalIssuesReportPaths have the same behaviour as sonar.sarifReportPaths for ignoring missing report files. I will try to dynamically populate the sonar.externalIssuesReportPaths thanks for the help.

1 Like

Hi again,

I’ve raised this internally, and FYI in future versions we’ll likely fail fast when the SARIF report is missing. The fact that we don’t (yet) was a misunderstanding in the implementation.

 
Ann

thank you in advance, by the way the SARIF is working, the problem is with Generic Reports :slight_smile:

Hi,

Yes, currently the SARIF failure doesn’t error out analysis. What I’m saying is that it should. And it likely will.

 
Ann

oh ok, so it will break the SARIF job on pipeline as well. I will need to implement a second workaround. Would be possible to add a flag/option to ignore some report files? Or make sonar.sarifReportPaths and
sonar.externalIssuesReportPaths support wildcard?

1 Like