Renewal due tomorrow, need help before

Good afternoon

We’re trying to setup Sonarcloud within our trial but struggling, and need to know if this will work before our renewal tomorrow

We were struggling with the automatic analysis, as often it wasn’t showing up on Github PRs until the PR had been approved and merged. So based on community advice, we turned off the automatic analysis and added the Github Action

This is now running OK, but we’renow noticing it’s running twice on each PR (presumably on from the Github Action and one from the integration, even though automatic analysis is off)


Also, the Github action analysis seems to be scanning files which aren’t part of the PR - it’s picking up bugs that are on completely unrelated files which weren’t committed?

We want to just check files which were changed in that PR?

Please help :slight_smile:

Template for a good new topic, formatted with Markdown:

  • ALM used: GitHub
  • CI system used: Github Actions
  • Languages of the repository: PHP
  • Error observed: Code is being scanned twice, once by Github Actions, Once by Sonarcloud integration, yet automated scanning is turned off.
  • Steps to reproduce: Create PR
  • Potential workaround: None. Often results differ between scans!

Hello @benseb,

That should not be happening. I would be happy to help you troubleshoot Automatic Analysis. We’ve had some exceptional delays in processing in the past week which could explain your experience.

The fact that you are seeing two checks related to SonarCloud is expected when using GitHub actions. One check is reported when the GitHub action that scans the code is successfully executed, this does not mean that there were no issues found. In fact this action will usually never fail.

The results of the scan are sent to the SonarCloud servers and processed there. Based on this processing there is an additional check reported with the Quality Gate status. This is the check that will fail if a PR introduces too many issues for example.

This is probably because the git history is not fully available while scanning the code. You can set fetch-depth: 0 when using GitHub Actions to make sure only relevant issues are being reported. See the sonarcloud-github-action repo for more information.

Hope that helps!

1 Like

Thanks Tom. I think the main issue for us, is that when using Github, the pending actions will block the Pull Request from merging until complete. That’s a good thing as it ensures the checks run and pass.

With the automated analysis, there is no visibility anything is running until it’s complete, so the developers don’t know to wait and we have quite a few instances of the PR being merged and closed off before the check could even complete.

Using Github actions has solved this mostly as we can see the check is pending. If it appears as two checks, that fine now I understand the logic, at least we can see it’s performing the checks now.

We did initially have it set to that, but then reading some docs were advised to set it to fetch-depth: 1 due to the time it would take (we have 300k+ lines of code)

What’s best here? We obviously don’t want it checking code that isn’t in the PR

You could mark the SonarCloud check as required, that way it is always clear that the SonarCloud scan has to complete before merging in a protected branch is possible. This is how we have set it up ourselves.

In the context of a PR we need at least a history long enough to include a reference to the target branch of the PR. This means that for a PR with 5 commits you would need to have at least a fetch-depth of 6 to make sure you get correct results. It’s up to you to balance the fetch-depth value with the time it takes to checkout the code.

Hi Tom

I’ve set the depth to 100, which should be by far the max size of our PRs.

A PR just went up which affected 2 files. It was very minor changes (about 5 LOC)

However the sonar scan is showing this:

INFO: Sensor HTML [web] (done) | time=2039ms

[2]( Sensor XML Sensor [xml]

[3]( 8 source files to be analyzed

[4]( 8/8 source files have been analyzed

[5]( Sensor XML Sensor [xml] (done) | time=146ms

[6]( Sensor JaCoCo XML Report Importer [jacoco]

[7]( 'sonar.coverage.jacoco.xmlReportPaths' is not defined. Using default locations: target/site/jacoco/jacoco.xml,target/site/jacoco-it/jacoco.xml,build/reports/jacoco/test/jacocoTestReport.xml

[8]( No report imported, no coverage information will be imported by JaCoCo XML Report Importer

[9]( Sensor JaCoCo XML Report Importer [jacoco] (done) | time=25ms

[10]( Sensor JavaScript analysis [javascript]

[11]( 207 source files to be analyzed

[12]( Failed to parse file [httpdocs/applets/jscalendar/lang/calendar-hr.js] at line 3: Unexpected character '?'

[13]( Failed to parse file [httpdocs/applets/jscalendar/lang/calendar-he-utf8.js] at line 86: Unexpected token ?????

[14]( Failed to parse file [httpdocs/applets/jscalendar/lang/calendar-al.js] at line 92: Unterminated string constant

[15]( 119/207 files analyzed, current file: httpdocs/applets/responsive/home.js

[16]( 207/207 source files have been analyzed

[17]( Sensor SonarJS [javascript]

[18]( 207 source files to be analyzed

For example, zero .js files were commited, so why are there 207 files to be analyzed?

Hello @TomVanBraband ?

Hello @benseb,

The scanner will always scan all files, and not just the changed files. Some rules require context from other files to raise an issue.

However SonarCloud will only report on issues raised in the changed lines of the PR, this filtering happens after the scan is complete though.

1 Like