Docker
SonarQube Server can analyze Infrastructure-as-Code (IaC) languages such as CloudFormation, Kubernetes, and Terraform.
Last updated
Was this helpful?
SonarQube Server can analyze Infrastructure-as-Code (IaC) languages such as CloudFormation, Kubernetes, and Terraform.
The level of support for a language is defined as follows:
Fully supported: Analysis will complete. All the language features are understood and examined.
Supported: Most language features are understood and examined but the version includes unsupported features. Analysis might break or provide incomplete results.
Dockerfile versions 1.0 to 1.6 are supported.
Discover and update the Docker Analysis parameters by going to Administration > Configuration > General Settings > Languages > Docker
Missing Uniform Filename Convention:
Dockerfiles can have any name and do not need a file extension. For this reason, it is difficult for the scanner and the analyzer to recognize all Dockerfiles.
By default, all files named Dockerfile, Dockerfile.*, or *.dockerfile are scanned by the Docker analyzer.
To associate additional files to the Docker Language, you can provide a custom list of patterns via the sonar.docker.file.patterns property which is located in the language-specific properties.
Adding a pattern to sonar.docker.file.patterns should be considered carefully, as each file can be assigned to only one language.
For example, adding the pattern dockerfile.* will create a conflict with the Java analyzer if a file named dockerfile.java exists. This will result in a non-functional analysis.
By default, the scanner still analyzes files with the dockerfile.* pattern but does not assign them to the Docker language to prevent having one file with multiple languages.
Patterns that could result in a possible language conflict can be specified via the scanner property sonar.lang.patterns.docker property. Files that are affected by this are analyzed by the scanner but not assigned to the Docker language.
Adding the NOSONAR comment on the line will suppress all issues on that line:
NOSONAR can be placed anywhere in the comment.
The comment check is case-sensitive.
Rather than relying on this method, we suggest refining your analysis scope to avoid creating major gaps in your code review. Because the NOSONAR comment silences all current and future issues on a line without regard for their severity, it is an imprecise tool. Even if you only intend to hide a minor stylistic point, you could unintentionally obscure a serious security flaw.
Last updated
Was this helpful?
Was this helpful?