The last analysis has failed. ID: bb213039-7fc9-4644-9286-1a8d30c70944

SonarQube Cloud
, ,
1

Template for a good new topic, formatted with Markdown:

  • ALM used (GitHub)
  • GitHub Actions
  • Scanner command used: dotnet-sonarscanner begin /k:“${{ env.SONAR_PROJECT_KEY }}” /o:“${{ env.SONAR_ORGANIZATION_KEY }}” /d:sonar.qualitygate.wait=true /d:sonar.token=“${{ env.SONAR_TOKEN }}” /d:sonar.cs.vscoveragexml.reportsPaths=“**/TestResults/coverage.xml”
  • Languages of the repository: C#
  • Url ( SonarQube Cloud )
  • URL to PR (AB#230: Add CI workflow by BlaiseD · Pull Request #1 · BpsLogicBuilder/LogicBuilder.Samples.Enrollment.ChatHub · GitHub)
  • Error observed (No feedback on the error page except the message annalysis failed with guid to report): The last analysis has failed. If it keeps on failing after several attempts, please contact us on Community forum (opens in new tab) and provide the following failing analysis ID: bb213039-7fc9-4644-9286-1a8d30c70944
  • Just run the CI build - fails every time.
  • Potential workaround: can’t see one.

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

3

I had to exclude all coverage in the dotnet-sonarscanner call (/d:sonar.coverage.exclusions=“**/*”). There’s a discrepancy between the 100 percent coverage noted by the cobertura report and the reported 0% coverage on new code - 1st project, and 53% coverage on new code - 2nd project. Here are the two projects: SonarQube Cloud

5

Hi Blaise,

Thanks for the additional details. We found two separate issues that were being shown together.

The failed-analysis IDs you shared:

  • `bb213039-7fc9-4644-9286-1a8d30c70944`
  • `1f1b8214-bd47-47a2-8171-cc5456a06d08`

are from Automatic Analysis, not from your GitHub Actions workflow.

In plain words: Automatic Analysis jobs were still queued after Automatic Analysis had been disabled for the project. When those jobs ran, they stopped because Automatic Analysis was disabled.

These jobs should have been skipped rather than displayed as failed analyses. The “last analysis has failed” message is therefore misleading in this case. The IDs do not indicate a problem with your source code, tests, coverage report, or GitHub Actions scanner configuration.

Your GitHub Actions scan is separate. Its report was uploaded successfully, but the workflow then failed because it waited for the Quality Gate result:

  Analysis report uploaded
  ------------- Check Quality Gate status
  ERROR: QUALITY GATE STATUS: FAILED
  The scanner engine did not complete successfully
  Post-processing failed. Exit code: 1

This is expected with: /d:sonar.qualitygate.wait=true.This setting makes the GitHub Actions job fail when the Quality Gate is red. It does not mean the scanner failed to upload or process the analysis.

The remaining issue to investigate is the Quality Gate failure, specifically coverage on new code.

Excluding all coverage may make the Quality Gate pass by removing coverage from its calculation, but it does not resolve the coverage setup.

We reviewed the workflow in your pull request and can see that it first merges the test coverage into

TestResults/coverage.xml

for SonarQube Cloud, then converts that same report to Cobertura format for Codecov.

The PR’s failed CI log says:


  Parsing the Visual Studio coverage XML report .../TestResults/coverage.xml
  Coverage Report Statistics: 4 files, 4 main files, 4 main files with coverage, 0 test files, 0 project excluded files, 0 other language files.

So SonarQube Cloud did find and import the report successfully. The issue is not a missing or unreadable coverage report.

The GitHub Actions scan uploaded successfully, but the Quality Gate failed for one specific reason:

53.3% Coverage on New Code (required ≥ 80%)

The scanner log also confirms the report was read successfully, so the remaining question is why the tests/report provide coverage for only 53.3% of the PR’s new-code lines.

One possibility is that the paths in the coverage report do not match the paths of the files analysed by SonarQube Cloud.

The coverage troubleshooting guide explains the relevant coverage-import checks.

Have you had a chance to go through this guide?

Action items on our side:

  • We are investigating why these queued Automatic Analysis jobs were attempted and surfaced as failures, even if you use CI analysis.
  • We will investigate why the Quality Gate is not computed and surfaced in the user interface for you, even if the backend computed the QG failure and this is why your CI job failed.
7

Thanks for checking this Andrei. Consider these two projects

The first one reported 53.3% Coverage on New Code (required ≥ 80%) and the seocnd one reported 0.0% Coverage on New Code (required ≥ 80%). They both had 100% coverage according to cobertura and somewhere around 90% in the xml format. First, the numbers do not appear to be valid. Second, the blocking problem for me was I couldn’t find what was being referred to as uncovered in the Sonar portal. Checking the second project (Contoso.ChatHub) right now, some of the tabs are missing - no issue tabs etc.. That’s how the first project (Enrollment.ChatHub) appeared when I reported the error. I can see how it’s possible to enter one new line of code which is uncovered and therefore reported as 0% coverage on new code but it would help to know where the uncovered line is.

I suspect you have a broken deployment somewhere. I’m currently seeing two open issues in the first project (Enrollment.ChatHub) yet the lines no longer exist in the master repository.

8

Did you redo an analysis after you removed the lines?

9

Ah - good point:

I have the CI setup as follows which runs the dotnet-sonarscanner:
on:
pull_request:
branches: [ master ]

Maybe it should run on push also:
on:
push:
branches: [ master ]

The push workflow file does not run dotnet-sonarscanner.