How to validate a file was excluded from analysis?

[EugenePerson (Eugene)]

We’re using GitHub integration with SonarCloud and trying to exclude test files ( **/*.spec.ts) from analysis.

The pattern “**/*.spec.ts” has been added to “Test File Exclusions” section for the project but I’m not sure how to validate the impact of that change on the next analysis.

[Colin]

Hey there.

If your source/test files sit in the same directory, I think you are looking for a configuration like this – where all files are indexed but .spec.ts files are excluded from source code but included in test code (which does not count towards your LoC limit, or have much meaningful analysis done)

  sonar.sources=.
  sonar.exclusions=**/*.spec.ts

  sonar.tests=.
  sonar.test.inclusions=**/*.spec.ts

[EugenePerson (Eugene)]

Thanks for the quick response Colin.

Few follow up questions

• After I add these to the Analysis Scope, how can I verify the files are being excluded in the next scan? Is there a place that summarizes the results of applied scope filters or a way to spot check a file in the code isn’t being scanned?

• What’s the benefit of including the test files in sonar.test.inclusions after excluding them in sonar.exclusions? I read the Narrow the Scope article but I’m not sure it answers this question.

• Also, to confirm you’re recommending this configuration in the SonarCloud GUI (we aren’t storing config in our git repo):
  

  

[Colin]

Hey @EugenePerson

@EugenePerson

• After I add these to the Analysis Scope, how can I verify the files are being excluded in the next scan? Is there a place that summarizes the results of applied scope filters or a way to spot check a file in the code isn’t being scanned?

You can run analysis in DEBUG mode (sonar-scanner -X) and check how files are indexed

15:29:25.725 INFO: Indexing files...
15:29:25.726 INFO: Project configuration:
15:29:25.726 INFO: Excluded sources: **/build-wrapper-dump.json, **/*.spec.ts
15:29:25.726 INFO: Included tests: **/*.spec.ts
15:29:25.739 DEBUG: Average line length for test.js is 10
15:29:25.741 DEBUG: 'test.js' indexed with language 'js'
15:29:25.750 DEBUG: 'test.spec.ts' indexed as test with language 'ts'

If your expected files are “indexed as test” – you’re doing it right. You will still see theses files in the SonarCloud UI, but they will have been analyzed correctly (we don’t do much Test Code analysis today, hopefully we will tomorrow). Test code does not count towards your Lines of Code limit when indexed correctly.

@EugenePerson

• What’s the benefit of including the test files in sonar.test.inclusions after excluding them in sonar.exclusions? I read the Narrow the Scope article but I’m not sure it answers this question.

See above. You still want the files indexed by SonarCloud, but they ought to be indexed as test files.

@EugenePerson

Also, to confirm you’re recommending this configuration in the SonarCloud GUI (we aren’t storing config in our git repo):

You will also need to explicitly set sonar.tests=., bu this cannot be set in the UI.

[EugenePerson (Eugene)]

Got it.

To confirm - using SonarCloud and automatic GitHub integration has gaps in what’s available in the UI and we still may need to update our project files and run the Sonar Scanner CLI tool to get certain functionality working?

[Colin]

Hey there.

Thanks for the context that you’re using Automatic analysis.

There are indeed a handful of parameters that can only be set in a file like sonar-project.properties or .sonarcloud.properties file. See the documentation here about how to set these parameters in a .sonarcloud.properties.

Using Automatic Analysis also means you won’t have access to the scanner logs. If your test code appears in the Code tab but with a - for Lines of Code – you’ve also configured it correctly.