- Often users don't take care to properly configure file exclusions and end up analyzing generated or third-party code. As a result of such analysis, they don't get the maximum value from SonarQube.
- Often the files which should not be analyzed are not pushed in SCM, they are some generated files, build artefacts, dependencies.
- Reusing exclusion information coming from SCM will ease configuration of project and will make "first mile" more use-friendly.
SonarQube should automatically exclude from analysis files which are ignored by SCM (excluding files means they are not indexed by the scanner engine, and it is not possible for analyzers to manipulate them using the SonarQube filesystem API. However that doesn’t mean analyzers can't access them directly from the OS filesystem).
SCM plugins should provide an implementation of an automatically-enabled filter which rejects SCM-ignored files.
Note currently there are following additive properties available:
1. sonar.global.exclusions (rarely used, global to all projects on SQ instance)
2. sonar.exclusions (note that as for any property, this one can be defined in many places, only one value, with higher priority, is used, e.g. highest priority is CLI parameter, and lowest SQ instance value)
This initiative adds a 3rd layer which will be considered after the first two
We understand that there are use-cases when it makes sense to analyze some SCM-excluded files (e.g. source generated based on some snippets), but as it is supposed to be minority, default behaviour is to exclude these files. A new property sonar.scm.exclusions.disabled will allow the user to turn this behavior off. The scanner is in charge to disable the scm exclusion filter when this property is set to true. We decide to keep this property out of the UI to avoid confusion, but it should be added to the Analysis Parameters documentation.
- there is a property sonar.scm.disabled which disables SCM plugin extension point, so no information on blame, new code, branches etc. is available (done by scanner-engine). It will also turn off scm-provided auto exclusions.
- there are additional exclusion properties sonar.<cpd/coverage/...>.exclusions. We don't expect these properties to be affected by these changes.
Existing users may unexpectedly have additional files excluded from analysis. It is expected that in 99% of cases this is a beneficial change. The other 1% can use the new sonar.scm.exclusions.disabled property to turn the behavior back off.
SCM Git plugin should rely on jGit library to accept or reject InputFile. See POC here.
SCM SVN plugin should rely on SVNKit to accept or reject InputFile. For implementation we should probably rely on list of SVNDirEntry instances and reject the files which don't match any SVNDirEntry. See example here how to get full list of SVNDirEntry in repository.
For both implementations:
- setting either sonar.scm.exclusions.disabled or sonar.scm.disabled to true should disable this filter.
- A Debug-level message should be logged for each rejected file.
- Integration with SonarLint, looks like doing nothing is good enough
- we don't download SCM plugins in SonarLint.
- each SonarLint already does the best to exclude "special" files based on information coming from IDE (e.g. files which are results of build)
Community SCM plugins (e.g. Mercurial) are free to provide the same functionality.