Skip to content
dbLinter

check

This command runs a static code analysis using a configuration that is defined in the Web GUI. This feature is only available with an Essential or Professional Subscription.

Syntax

Section titled “Syntax”
dblinter [<options>] check [<args>]

Options

Section titled “Options”

See Options. Mandatory options are tenantName, userName, accessToken and configName.

Argument Syntax

Section titled “Argument Syntax”
--<argument>=<value>

Arguments

Section titled “Arguments”

It is not possible to set arguments using environment variables. Beside that, in dbLinter, both arguments and options are treated in the same way. Therefore, they can be used in any order. For example, they can be used before or after the command name. The only exception is <paths...>, which must always be placed at the end. We use options when the semantics are identical for each applicable command. Arguments are used when the semantics change for a command.

  • outputFormats
    A comma-separated list of the output formats to be produced. All formats are considered by default. The following formats are supported:

    • vscode: dbLinter Check Report as Markdown for VS Code. This report will open automatically when the analysis is run via the VS Code extension.
    • sonarqube: SonarQube Generic formatted issue report to import issues in any SonarQube edition without any plugin.
    • sarif: Static Analysis Results Interchange Format (SARIF) to visualise issues in various tools. See also Viewers.
    • checkstyle: Checkstyle XML report.
    • github: Workflow commands for GitHub Actions. These commands (annotations) are interpreted when printed to stdout.
    • gitlab: GitLab quality report.

  • outputName
    This is the relative path from the working directory to the base name of the output files. Missing target directories will be created. For example, if you use the name check for an outputName, a file called check.vscode.md will be created in the working directory. The default is dblinter.

  • parallel
    The number of files analysed in parallel. The default is 1. To achieve better performance with higher values, you need enough free system resources. Also consider increasing the maximum heap space using the JAVA_OPTS environment variable. For example, export JAVA_OPTS=-Xmx=32G to set the maximum heap size to 32GB. The default maximum heap size for a system with 64 GB of RAM is 16 GB (one quarter), which is sensible for desktop systems. In CI/CD environments, however, higher values can improve performance, especially when processing large files.

  • newCodeOnly
    If set to true, issues are reported only on new and changed lines. The default is false. New and changed code is determined using Git and the configured reference branch. Requires git to be installed and available in the OS path.

  • Reference Branch
    Reference branch used to determine new and changed lines when newCodeOnly is enabled. The default is origin/main. The reference branch can be specified using any Git reference that identifies a commit, including branch names, tag names, and commit hashes. Think of it as the target branch in a Git merge or pull request. The new and changed lines are determined by comparing the current local branch with the reference branch. The reference branch contains the existing code, while the local branch contains the proposed changes.

  • <paths...>
    The files and directories to analyse. By default, all files in the workspace are included/excluded according to the glob patterns defined in the configuration. Any files and directories that are passed are treated as an additional filter. In other words, files and directories outside of the workspace cannot be analysed.

Example

Section titled “Example”
Terminal window
dbLinter-Demo % dbLinter check \
    --tenantName=Demo \
    --userName=philipp.salvisberg+42@gmail.com \
    --accessToken=*** \
    --configName=Default \
    --outputFormats=vscode,github \
    --outputName=check \
    --parallel=2 \
    --newCodeOnly=true \
    --referenceBranch=706c4307e640253ddba551a54be26f6ff2ef85ed \
    ./*.sql examples/Core-G-1*.sql

The console output for the dbLinter-Demo project on GitHub looks like this:

Using connection to jdbc:oracle:thin:@localhost:1521/freepdb1 with user DBL_READ
Processed examples/Core-G-1010.sql (1/25) in 0.172 sec. Found 4 issues.
Processed examples/Core-G-1030.sql (2/25) in 0.250 sec. Found 2 issues.
Processed examples/Core-G-1020.sql (3/25) in 0.426 sec. Found 8 issues.
Processed examples/Core-G-1050.sql (4/25) in 0.069 sec. Found 3 issues.
Processed examples/Core-G-1060.sql (5/25) in 0.056 sec. Found 2 issues.
Processed examples/Core-G-1070.sql (6/25) in 0.049 sec. Found 2 issues.
Processed examples/Core-G-1040.sql (7/25) in 0.189 sec. Found 8 issues.
Processed examples/Core-G-1080.sql (8/25) in 0.067 sec. Found 1 issue.
Processed examples/Core-G-1110.sql (9/25) in 0.066 sec. Found 3 issues.
Processed examples/Core-G-1120.sql (10/25) in 0.048 sec.
Processed examples/Core-G-1130.sql (11/25) in 0.047 sec.
Processed examples/Core-G-1140.sql (12/25) in 0.045 sec.
Processed examples/Core-G-1150.sql (13/25) in 0.045 sec.
Processed examples/Core-G-1210.sql (14/25) in 0.062 sec.
Processed examples/Core-G-1220.sql (15/25) in 0.091 sec.
Processed examples/Core-G-1240.sql (16/25) in 0.098 sec. Found 2 issues.
Processed examples/Core-G-1230.sql (17/25) in 0.136 sec. Found 2 issues.
Processed examples/Core-G-1260.sql (18/25) in 0.051 sec. Found 1 issue.
Processed examples/Core-G-1250.sql (19/25) in 0.055 sec. Found 2 issues.
Processed examples/Core-G-1270.sql (20/25) in 0.053 sec. Found 1 issue.
Processed examples/Core-G-1280.sql (21/25) in 0.052 sec. Found 1 issue.
Processed examples/Core-G-1310.sql (22/25) in 0.048 sec. Found 1 issue.
Processed examples/Core-G-1910.sql (23/25) in 0.055 sec. Found 1 issue.
Processed examples/Core-G-1920.sql (24/25) in 0.046 sec. Found 1 issue.
Processed install.sql (25/25) in 0.225 sec. Found 2 issues.
Check Summary
- Duration:                   1.347 sec.
- Files:                      25
- Characters:                 17,073
- Lines:                      590
- Lines of code:              279
- Statements:                 47
- PL/SQL units:               4
- Functions:                  5
- Comment line density:       7.4%
- Cyclomatic complexity (CC): 8
- Max CC per unit:            3
- Avg CC per unit:            2
- Errors:                     15
- Warnings:                   32
- Infos:                      0