Global Configuration

Threshold on cyclomatic complexity

Inspecode automatically computes code complexity (aka. Cyclomatic complexity) in your repository and raises issues if methods/functions whose complexity exceeds a threshold are detected. The default threshold is 15, but you can declare your own threshold as long as the value is equal to or greater than the minimum value 10.

The threshold can be declared in the following format:

inspecode:
  thresholds:
    complexity: <number>

Threshold on the number of issues detected in a job

Inspecode checks whether the number of issues detected in a job exceeds the thresholds, provided that the thresholds are declared.

Note: If the check fails (i.e. the number of issues exceeds a threshold), the job is marked as Failed.

The thresholds can be declared in either number notation or mapping notation.

(Number notation)

In number notation, only the threshold on the number of total issues detected in a job is declared.

inspecode:
  thresholds:
    num-issues: <number>
(Mapping notation)

In mapping notation, the thresholds on the number of issues for each severity level can be declared in addition to the threshold on the total number of issues.

inspecode:
  thresholds:
    num-issues:
      total: <number>
      <level>: <number>
      ...

where each <level> can be one of critical | error | warning | info (case-insensitive).

Note: Each severity level includes not only itself but also others higher than itself. This means, for example, that a threshold specified to warning level is applied to the sum of warning, error and critical issues.

[EXPERIMENTAL] Environment variables

Note: This is an experimental feature and is subject to change in future.

Inspecode allows you to configure some environment variables to let tools work properly with your repository.

The environment variables can be declared in the following format:

inspecode:
  experimental:
    env:
      <key>: <string>
      ...
Supported variables

Only the supported variables listed below can be configured. If unsupported variables are declared, Inspecode raises an error at setup and stops running the job.

  • GOPATH

    Inspecode has the default GOPATH and places your repository under the GOPATH by default. If and only if this behavior does not suit your project, you can give Inspecode your own GOPATH.

    Note that Inspecode considers any user-defined paths to be relative to the root of your repository even if the paths look absolute like /path/to/gopath. So you have to specify such relative paths to Inspecode even though the pure GOPATH requires absolute paths. Inspecode then resolves their absolute paths and sets them to GOPATH when running tools.

    For example, if you want to set GOPATH to the root of your repository, GOPATH can be declared as follows:

    inspecode:
      experimental:
        env:
          GOPATH: .

    It is also allowed to set multiple paths to GOPATH. For example, if you want to set both go/_gopath1 and go/_gopath2 subdirectories in your repository as GOPATH, then you can declare GOPATH as follows:

    inspecode:
      experimental:
        env:
          GOPATH: go/_gopath1:go/_gopath2
  • GLIDE_INSTALL_STRIP_VENDOR

    Glide is a tool for managing the vendor directory within a Go package. If the tool is used in your project, Inspecode also uses it to resolve dependencies before running some tools such as errcheck, go test, etc.

    Inspecode runs glide install by default, or glide install --strip-vendor to remove nested vendor and Godeps/_workspace directories if GLIDE_INSTALL_STRIP_VENDOR is set to 1.

    inspecode:
      experimental:
        env:
          GLIDE_INSTALL_STRIP_VENDOR: 1

[EXPERIMENTAL] Runtime versions

Note: This is an experimental feature and is subject to change in future.

Inspecode allows you to specify runtime versions used for running tools.

The runtime versions can be specified in the following format:

inspecode:
  experimental:
    runtime:
      <runtime>: <string>
      ...

Inspecode offers aliases of runtime versions, so that the specified version can be an exact version, such as 3.5.1, and also an alias, such as 3 meaning the latest version of 3.x.

See Runtime Versions for more details.

[EXPERIMENTAL] File filters

Note: This is an experimental feature and is subject to change in future.

Inspecode allows you to specify one or more patterns to include/exclude files and directories that match the patterns. The global patterns are always applied when running any tools and have precedence over tool-specific input and ignore patterns. If both the global and tool-specific patterns are specified, the tool specific ones are applied only to files selected by the global ones and cannot select files excluded by the global ones.

The file filters can be declared in the following format:

inspecode:
  experimental:
    input: <string|list>
    ignore: <string|list>

If no patterns are specified, all files and directories in your repository are treated as input by default.

The notation for patterns is the same as .dockerignore file, so each pattern can be written in the form similar to the file globs of Unix shells with additional support of a special wildcard string ** and exceptions starting with !.

Both input and ignore support string notation and list notation.

(String notation)

String notation is useful when specifying only one pattern.

inspecode:
  experimental:
    input: <pattern>
    ignore: <pattern>
(List notation)

List notation allows you to specify multiple patterns.

inspecode:
  experimental:
    input:
      - <pattern1>
      - <pattern2>
      ...
    ignore:
      - <pattern1>
      - <pattern2>
      ...

[EXPERIMENTAL] Prefix/Suffix for auto-fix git commit messages

Note: This is an experimental feature and is subject to change in future.

Inspecode allows you to set prefix/suffix for the messages of auto-fix commits. The maximum length of prefix/suffix is 1000 characters.

Note: See Field: auto-fix for details about auto-fix.

The prefix/suffix for auto-fix commit messages can be declared in the following format:

inspecode:
  experimental:
    auto-fix:
      comment-prefix: <string>
      comment-suffix: <string>

Example

inspecode:
  experimental:
    auto-fix:
      comment-prefix: "[ci skip] "
      comment-suffix: ". [skip ci]"

The commit message would be [ci skip] Fix <tool> errors. [skip ci] with the above configuration.

[EXPERIMENTAL] Dependency cache

Note: This is an experimental feature and is subject to change in future.

Inspecode supports the caching of dependencies. The caching option can be specified in the following format:

inspecode:
  experimental:
    cache: <boolean>

The dependencies are cached if cache is set to true. The cache is automatically deleted in 30 days. As of now, the caching feature supports the following tools:

If you don't want to cache all the dependencies, you can specify the tools to be cached. The option can be specified in the following format:

inspecode:
  experimental:
    cache:
      <tool>: <boolean>
      ...

Example

inspecode:
  experimental:
    cache:
      glide: true
      npm: true

[EXPERIMENTAL] Incremental analysis

Note: This is an experimental feature and is subject to change in future.

The incremental analysis is a feature offering you much quicker results in much more cost-effective way than the normal analysis.

When running a new job with enabling the feature, Inspecode automatically searches the job history for a base job that can be used for comparison, detects file changes between jobs, processes only the changed files, inherits the result from the base job for unchanged files, and eventually shows the same report as the normal analysis does.

Note: The base job is the newest job which has been successfully completed and also has processed one of the first parent commits nearest from the one where the new job will process. Therefore the base job can be older than the last one especially when the last one is still ongoing.

The feature is disabled by default, but you can enable/disable it for all tools in the following format:

inspecode:
  experimental:
    incremental: <boolean>

You can also configure the feature for each tool and the tool-specific configuration has precedence over this global one. See Tool Configuration for detail.

Restrictions

Unfortunately, the incremental analysis is not supported for all tools and Inspecode always does the normal analysis for some tools. See help page of each tool to find out which tools Inspecode supports the feature for.

Furthermore, even when running the tools for which the incremental analysis is supported, Inspecode does the normal analysis regardless of the configuration in some cases as listed below:

  • When running the tools with enabling the auto-fix feature
  • When external dependencies are required for running the tools
  • When your configuration files for the tools are changed between jobs
  • When more than 500 files are changed between jobs
  • When your rocro.yml is changed between jobs
  • When Inspecode itself is updated between jobs

results matching ""

    No results matching ""