Scans not running after moving to .sonarcloud.properties file

SonarQube Cloud
1

I recently setup a .sonarcloud.properties file following these instructions and matching the same settings as we had previously configured in the admin UI:

sonar.sources=.
sonar.exclusions=shared/messages/*, server/config/*, packages/builder/**/*, cypress/**/*, **/__tests__/**/*, extension/src/pendo.xhr.js
sonar.cpd.exclusions=server/models/migrations/*

sonar.tests=.
sonar.tests.inclusions=cypress/**/*, **/__tests__/**/*

However, after I took the settings out of the admin UI, we have not had any scans run on subsequent PRs or merges to main. I toggled the Automatic Analysis off and back on, and it seems to take the .sonarcloud.properties file into account in it’s assessment, since it’s showing 100% of our code being in supported languages (with is true for the files we had configured it to scan, but not for our entire project):

Screen Shot 2022-12-21 at 4.03.40 PM
Screen Shot 2022-12-21 at 4.03.40 PM1102×470 63.4 KB

I checked the Background Tasks to see if any were stuck in pending or showing errors there, but I don’t see any background tasks since I removed our config from the admin UI.

1 Like
2

Hey there.

I would suggest two things! First of all…

Frustratingly, sonar.test.inclusions is the real analysis parameter, even though you use sonar.tests to define the scope of test code.

Can you try correcting this and see if the scans start running?

3

@Colin to confirm - does this field behave differently when being used in a .sonarcloud.properties file vs in the UI (which indicates that this property is just for test file inclusion):

Screen Shot 2022-12-27 at 8.47.05 AM

This also contradicts the SonarCloud documentation around file exclusion and inclusion, what matches what is shown in the UI.

I can give this a try, but if this actually fixes the issue, I’d strongly suggest that this is a bug that needs to be fixed (or, if there’s a reason for keeping this behavior, the documentation and UI should be updated to reflect this).

Edit: Also, if sonar.test.inclusions is actually the main analysis parameter, is there another field I can use to set the test file inclusions? I can’t use sonar.tests, because that only accepts simple paths, and does not support the use of wildcards. I’m not sure if there’s any way to invert this and set it all through sonar.test.exclusions, but even if that’s possible it’d be extremely convoluted and hard to maintain properly.

4

They should behave the same.

I think you might misunderstand what I’m saying – I’m not contradicting the docs or the UI, just saying that sonar.tests.inclusions is an invalid analysis parameter and sonar.test.inclusions is the correct one (tests vs. test). It’s frustrating in the sense that it isn’t consistent with sonar.tests.

5

Yes, I overlooked the test vs tests and thought you were saying something completely different - sorry about that!

I’ll try changing this to test and see if that fixes things :crossed_fingers:

6

@Colin our scans are working after I fixed that :sweat_smile:

Thanks again for the help (and the patience)!

1 Like
7

Great to hear. :slight_smile: Thanks for the follow-up!