Go
Code Analysis
.deepsource.toml
This section covers .deepsource.toml
configuration specific to the go
analyzer. Please make sure to read the general configuration guide first.
name
- Type: String
- Presence: mandatory
- Description: Shortcode of the analyzer.
- Example:
enabled
- Type: Boolean
- Presence: optional
- Description: Toggle whether this analyzer should be run.
- Example:
meta
- Type: Table
- Presence: mandatory
- Description: Any supported metadata to pass to the analyzer.
- Example:
import_paths
- Type: Array
- Presence: optional
- Description: The Go analyzer by default automatically populates import_paths by searching for any available package managers. To override this behavior, all the import paths in the repository should be mentioned in this array.
- Default Value: None
- Example:
import_root
- Type: String
- Presence: mandatory
- Description: Repository source code will be placed in $GOPATH/src/{import_root}. If you haven’t yet migrated to Go Modules, you should configure import_root properly so that dependencies can be fetched for analysis.
- Default Value: None
- Example:
skip_doc_coverage
- Type: Array
- Presence: optional
- Description: Specify which artifacts to skip when calculating documentation coverage.
- Available Value:
file
file
- Do not include file docs while calculating documentation coverage.
- Default Value: None
- Example:
dependencies_vendored
- Type: Boolean
- Presence: optional
- Description: If set to true the analyzer doesn’t install dependencies since they are already available in the vendor directory of the repository.
- Available Values:
true
,false
- Default Value:
false
- Example:
build_tags
- Type: Array
- Presence: optional
- Description: Specify the build tags with which the analyzer can determine whether a file should be included in the package. This prevents compilation-related issues due to the inclusion/exclusion of files based on tags (or constraints).
- Default Value: None
- Example:
cgo_enabled
- Type: Boolean
- Presence: optional
- Description: Whether the analyzed packages will call C code using CGo. If the C code relies on external C libraries, they might not be present for analysis runs resulting in analysis failure. If your project does not use CGo, set the flag to false.
- Available Values: true, false
- Default Value: true
- Example:
import_path
- Type: String
- Presence: mandatory if import_paths is empty
- Description: The import path of the repository should be mentioned in this string.
- Default Value: None
- Example:
import_path
is now deprecated. It will still be used if the import_paths
array is empty, for backward compatibility. It is recommended to configure import_root
and let the analyzer automatically figure out the import_paths
instead of using this field.
cyclomatic_complexity_threshold
- Type: String
- Presence: optional
- Description: Specify the acceptable risk category for your project as the threshold. All functions with complexity beyond this threshold will raise an issue. For example, setting the threshold to
low
will flag all functions that have a cyclomatic complexity of more than5
, while setting the threshold tocritical
will not flag any function. - Available Values:
low
,medium
,high
,very-high
andcritical
Risk category | Cyclomatic complexity range | Recommended action |
---|---|---|
low | 1-5 | No action is needed. |
medium | 6-15 | Review and monitor. |
high | 16-25 | Review and refactor. Recommended to add detailed comments if the function absolutely needs to be kept as it is. |
very-high | 26-50 | Refactor to reduce the complexity. |
critical | >50 | Must refactor this. This can make the code untestable and very difficult to understand. |
- Default Value:
medium
- Example:
Sample config
Dependency Installation
To conduct a thorough analysis of your code, DeepSource installs the dependencies required and examines them alongside your code. Our Go Analyzer identifies the package manager you’ve utilized, ensuring effortless integration. The package managers we currently support are:
File name | Package Manager |
---|---|
go.mod | go modules |
Gopkg.lock | dep |
GLOCKFILE | glock |
Godeps/Godeps.json | godep |
dependencies.tsv | godeps |
glide.lock | glide |
vendor.conf | trash |
trash.yaml | trash |
vendor/manifest | gvt |
vendor/vendor.json | govendor |
No dependency file | No deps installed |
If the meta property dependencies_vendored
is set to true
, dependency installation is skipped.
Code Coverage
go test
The analyzer supports coverage profile (report) for all three modes — set
, atomic
, and count
generated by the go test
.
This is how you can generate a coverage profile and report it to the analyzer:
Note: Tests for different Go packages
If you are running tests and generating coverage reports for different packages separately, you need to combine all generated coverage reports into a single file and submit that to the test-coverage
analyzer.
This is how you can combine the coverage artifacts before reporting them:
Code Formatter (Transformer)
gofmt
Transform all incoming Go code with gofmt, the official Go code formatter.
This section covers .deepsource.toml
configuration specific to the gofmt
transformer. Please make sure to read the general configuration guide first.
name
- Type: String
- Presence: mandatory
- Description: Shortcode of this transformer.
- Example:
enabled
- Type: Boolean
- Presence: optional
- Description: Toggle whether this transformer should be run.
- Example:
gofumpt
Transform all incoming Go code with gofumpt, an opinionated formatter based on gofmt that enforces a stricter format and adds additional rules to make Go code more consistent.
This section covers .deepsource.toml
configuration specific to the gofumpt
transformer. Please make sure to read the general configuration guide first.
name
- Type: String
- Presence: mandatory
- Description: Shortcode of this transformer.
- Example:
enabled
- Type: Boolean
- Presence: optional
- Description: Toggle whether this transformer should be run.
- Example:
Vulnerability Scanning
Supported target files:
go.mod
go.sum