Scanner fails to read swiftlint file but marks scan as successful

SonarQube Cloud
1

I am running latest version of sonar-scanner, 4.7.0.2747, scanning Swift 5.6 and uploading results to SonarCloud. I am running on Jenkins using MacOS environment. In the CI pipeline, I run swiftlint to generate issues file and I feed it to the scanner using sonar.swift.swiftLint.reportPaths CLI parameter. I am using both branch scans and PR scans, for example, a command like this:

sonar-scanner -Dsonar.branch.name=main -Dsonar.swift.swiftLint.reportPaths=linter-issues.json

Due to some problems in my MacOS CI environment (I ended up solving this), I sometimes generated an invalid JSON file. It happened since I redirect linter’s JSON output to a file and if the linter put out a warning in the output, I end up with the message followed by the JSON output, which again is not valid JSON:

Error while creating cache: You don’t have permission to save the file “0.47.1” in the folder “SwiftLint”.
[

]

As expected, the scanner would run, put out an error saying it failed to parse the file, as expected, but what surprised me is that the scanner would terminate with 0 exit code. This is why I am posting here. The issue is that it is typical in CI environments to rely on command exit codes to determine whether something worked or not, and if the flow should abort or continue. In this case, the flow should stop for a couple of reasons:

  • the input is invalid so the tool should flag it as such. The output does produce an exception however when the job is green, no one will likely notice that.

  • issues fed into the scan can drive pass/fail criteria so it is important to validate this, or the results will produce a false negative. In my scenario, I had a quality gate set to 0 issues, I did have issues present in the JSON input file, the scanner ignored them, submitted the result and my scan passed where it should have failed.

Is there a way for the scanner to be stricter on input? I can mitigate this for now by validating the files with jq but ideally the scanner should flag this and reject bad input. I don’t consider parsing scanner logs as a reasonable solution. Looking for feedback and curious if I am missing some obvious thing here.

1 Like