Scope of Analysis: Types of Files
SonarQube can perform analysis on 2520+ different languages. The outcome of this analysis will be quality measures and issues (instances where coding rules were broken). However, what gets analyzed will vary depending on the language:
- On all languages, a static analysis of source code is performed (java Java files, Cobol COBOL programs, etc.)
- A static analysis of compiled code can be performed for certain languages (.class files or jars in Java, .dll files in C#, etc.)
- A dynamic analysis of code can be performed on certain languages (execution of unit tests in Java, C#, etc.)
Scope of Analysis: Which Files
There are three different paradigms for SonarQube analysis: full analysis (or just plain "analysis"), preview analysis, and incremental analysis. You switch among the three modes using the
sonar.analysis.mode analysis parameter with one of these three values:
analysis- this is the default. This mode analyzes everything that's analyze-able for the language in question and saves the results to the database.
preview- is typically used to determine whether code changes are good enough to move forward with, E.G. merge into the Git master.
incremental- is used on the developer's localhost to examine changed files for added technical debt before checking them in.
Analysis mode performs a full analysis on the entire code base and saves the results to the database. Assuming code changes, you will ideally analyze once a day in this mode - typically over night. Use this mode to update the central server and keep the team at large abreast of your current code quality.
If you're using continuous integration, you don't want to add full analysis to your CI job. Doing so would cause needless churn in the SonarQube metrics and make the "Since previous analysis" differential nearly useless for most people. Instead, you'll want to set up a separate analysis job that polls your SCM on a nightly basis.
If you're not using continuous integration, but only building intermittently or at most daily, then by all means include SonarQube analysis in your regular build job.
Preview mode performs a full analysis on the entire code base and does not save the results to the database. Typically this mode is used on the continuous integration server as part of the continuous integration job. To take full advantage of preview mode in this scenario, you'll want to install the Build Breaker Plugin, and set up a quality gate. Together, these two mechanisms allow you to automatically mark the build broken when the quality of newly checked in code is not up to standard.
Incremental mode performs a fully analysis only on changed code, and does not save the results to the database. It is used on the developer's machine to check the quality of code changes before checking them in. It is the default in the Eclipse plugin. If you're not using Eclipse, you can still take advantage of incremental mode using a local installation of sonar runner and the Issues Report Plugin. In either case (Eclipse or Issues Report), you'll be able to see the issues on the code in question, with any issues introduced since the last full analysis highlighted for immediate attention.
Then, there are two ways to add a new project to your SonarQube instance. Either:
- You can analyze it first with the default parameters and then configure it (define permissions, set quality profiles, etc.).
- Or you can provision it. This will allow you to configure it prior to running the first analysis.
To run an analysis, the following methods you need to choose an analysis method. The following are available:
- Analyzing with SonarQube Runner (recommended clientanalyzer)
- Analyzing with SonarQube Ant Task
- Analyzing with Maven
- Analyzing with Gradle
- CI Engines
This chart shows the backward compatibility of the current version of each analysis engine.
|SonarQube Ant Task||2.1||2.2||2.2||2.2||2.2||2.2||2.2|
For more information