How to make sonarqube-scan-action fail if encounters coverage issues?

SonarQube Cloud
, ,
1

Currently sonarqube-scan-action seems to only display some deeply hidden warning messages in its execution log when it encounters problem processing the coverage files and I was not able to find any parameters that I can pass to it to make it fail if it does this, or at least to produce GHA annotations so the issues would be more visible.

Due to this it seems impossible to keep the coverage being reported and checked consistently as it is too easy for some changes to degrade it in an invisible way.

11:34:51.269 INFO  Analysing [/home/runner/work/vscode-ansible/vscode-ansible/logs-unknown-test-wsl-1.zip/coverage/e2e/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-unknown-test-wsl-1.zip/coverage/unit/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-ubuntu-24.04-test-linux-1.zip/coverage/e2e/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-ubuntu-24.04-test-linux-1.zip/coverage/unit/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-macos-15.7.3-test-macos-1.zip/coverage/e2e/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-macos-15.7.3-test-macos-1.zip/coverage/unit/lcov.info]
11:34:51.442 WARN  Could not resolve 313 file paths in [/home/runner/work/vscode-ansible/vscode-ansible/logs-unknown-test-wsl-1.zip/coverage/e2e/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-unknown-test-wsl-1.zip/coverage/unit/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-ubuntu-24.04-test-linux-1.zip/coverage/e2e/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-ubuntu-24.04-test-linux-1.zip/coverage/unit/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-macos-15.7.3-test-macos-1.zip/coverage/e2e/lcov.info, /home/runner/work/vscode-ansible/vscode-ansible/logs-macos-15.7.3-test-macos-1.zip/coverage/unit/lcov.info]
11:34:51.444 WARN  First unresolved path: out/server/external node-commonjs "buffer" (Run in DEBUG mode to get full list of unresolved paths)
11:34:51.445 INFO  Sensor JavaScript/TypeScript Coverage [javascript] (done) | time=226ms

In fact I even seen the ‘SonarCloud Code Analysis’ check being reported as passing when coverage files were not uploaded at all.

Note: keep in mind that this action runs on a separated secure workflow which is triggered by workflow_run event, as that is the only way to perform the scan securely on any kind of pull-request (including those from forks). This makes the failure of the action not really visible in GHA action runs as only the actions that run due to pull-request event are displayed there.

2

Hi,

Welcome to the community!

I take it you would prefer analysis to fail if coverage import doesn’t succeed? I believe this is the first time I’ve seen this request.

If coverage is that important, surely it’s included in your quality gate? Thus a failed coverage import → 0% coverage → quality gate failure? At that point, it’s just a matter of failing your pipeline for a failed quality gate, which is pretty standard.

 
HTH,
Ann

3

I am almost sure that I seen the quality gate passing when the coverage was either not uploaded or it was as partial upload (with some warnings being seen in that case).

So if I cannot make the analysis to fail i risk on getting a false sense of security and worse allow some changes to accidentally reduce coverage.

And yep the passed report had 0% coverage reported as passing because it did say it was not able to find any lines of code.

4

Hi,

That sounds like you need to adjust your quality gate criteria.

 
HTH,
Ann