Custom Analysis Configuration

Usually, you don't need to do any special configuration for Sider to start analyzing your code. However, Sider also offers advanced settings for special cases via the configuration file named sider.yml (learn more about YAML).

sideci.yml is still supported for the backward compatibility, but it will be unsupported in the future. Please rename it to sider.yml as possible.

Configuration file

Add a file named sider.yml in your project's root directory. Here is an example:

# This is a YAML file. See <https://yaml.org>.
linter:
  rubocop:
    config: "lint_yml/.myrubocop.yml"

  eslint:
    root_dir: "frontend/"
    npm_install: false
    config: "frontend/.eslintrc"

  stylelint:
    root_dir: "app/assets/stylesheets/"
    glob: "**/*.{css,scss}"

ignore:
  - "images/**"

The options you can specify in sider.yml are grouped into the following categories:

Analyzer-specific options (under linter)
Non analyzer-specific options
- ignore
- branches.exclude

Analyzer-specific options

You can use sider.yml to configure each analyzer's vendor-supplied settings. Sider also provides extra options for some analyzers that configure how Sider runs the analyzer (for example, some tools might need to run npm install before beginning analysis). See each analyzer's documentation for more details about available options.

The following sections describe the available options.

`linter.<analyzer_id>.root_dir`

type: string

This is a common option available to all analyzers. This option specifies a directory in your repository from which Sider should run the analyzer in. For example, if you would like to analyze only files in the frontend/ directory, you could configure sider.yml like this:

linter:
  eslint:
    root_dir: "frontend/"

In the configuration above, Sider will run ESLint at the frontend/ directory (perhaps will load files such as frontend/.eslintrc.js or frontend/package.json).

If you omit this option, Sider will use your repository root directory (sufficient in most cases).

`linter.<analyzer_id>.dependencies`

type: string[], map[]

This common option allows you to tell Sider to install dependencies required by analyzers. The option is useful if you do not want to add extra dependencies for analyzers into your project.

We support the following package managers:

Bundler (for Ruby)
npm (for JavaScript)
Gradle (for Java)
APT (for C/C++)
pip (for Python)

For Bundler

Sider uses Bundler to install Ruby dependencies (called gems). A Ruby analyzer version is decided in the following order:

by the dependencies option in your sider.yml file
in your Gemfile.lock file
our default version

If a gem version is omitted in the dependencies option, a version in your Gemfile.lock will be installed. But, if the gem is not present in Gemfile.lock, the latest version will be installed. For example, when Gemfile.lock includes rubocop-rails (2.9.0) and does not include rubocop-rspec:

linter:
  rubocop:
    dependencies:
      - "rubocop-rails" # install the version 2.9.0 (present in `Gemfile.lock`)
      - "rubocop-rspec" # install the latest version (absent in `Gemfile.lock`)

Install gems from third-party RubyGems repository

You can also use an alternate RubyGems repository via the source option:

linter:
  rubocop:
    dependencies:
      - name: "rubocop-mycompany"
        version: "0.63.0"
        source: "https://gems.mycompany.com"

Install gems from Git repository

You can also install gems from a Git repository via the git option. Please note that the git option cannot be specified with version or source.

linter:
  rubocop:
    dependencies:
      - name: "rubocop-mycompany-standard"
        git:
          repo: "https://github.com/mycompany/rubocop-mycompany-standard.git"
          branch: "main"
      - name: "rubocop-mycompany-extensions"
        git:
          repo: "git@github.com/mycomapny/rubocop-mycompany-extensions.git"
          tag: "v0.63.0"

The git option accepts the following options:

Name	Type	Description
`repo`	`string`	Git repository location accessible via HTTP(S) or SSH protocols
`branch`	`string`	Branch name
`tag`	`string`	Tag name
`ref`	`string`	Ref name

If you would like to install a gem located in a private Git repository, see Private Dependencies.

For npm

Sider uses npm to install JavaScript dependencies. There are the following ways:

Specify a dependency name without a version. This will install the latest version.
Specify a dependency name and version with the npm install format <name>@<version>.
Specify a dependency name and version with a map including name and version.

For example:

linter:
  eslint:
    dependencies:
      - "eslint-plugin-react"
      - "eslint-plugin-react@7.23.1"
      - { name: "eslint-plugin-react", version: "7.23.1" }

If you specify this option, linter.<analyzer_id>.npm_install will be ignored.

For Gradle

Sider uses Gradle to install Java dependencies. There are the following ways:

Specify a dependency name and version with the Gradle format <group>:<name>:<version>.
Specify a dependency name and version with a map including name and version.

linter:
  checkstyle:
    dependencies:
      - "io.spring.javaformat:spring-javaformat-checkstyle:0.0.27"
      - { name: "io.spring.javaformat:spring-javaformat-checkstyle", version: "1.37.1" }

For APT

Sider uses APT, which is a package manager for Debian-based Linux distributions, to install C/C++ dependencies. Development packages provided by the OS environment may be necessary, particularly for projects written in C/C++.

There are the following ways:

Specify a dependency name without a version. This will install the latest version.
Specify a dependency name and version with the format <name>=<version>.
Specify a dependency name and versiont with a map including name and version.

linter:
  clang_tidy:
    dependencies:
      - "libfastjson-dev"
      - "libfastjson-dev=0.99.8-2"
      - { name: "libfastjson-dev", version: "0.99.8-2" }

Note that specified dependencies must satisfy the following requirements:

A dependency must be compatible with our Docker image.
A dependency name must have the suffix -dev.

For pip

Sider uses pip to install Python dependencies. There are the following ways:

Specify a dependency name without a version. This will install the latest version.
Specify a dependency name and version with the requirement specifiers like ==1.4.1.
Specify a dependency name and version with the VCS format.
Specify a dependency name and version with a map including name and version.

For example:

linter:
  flake8:
    dependencies:
      - "flake8-bugbear"
      - "flake8-builtins==1.4.1"
      - "git+https://github.com/PyCQA/flake8-import-order.git@51e16f33065512afa1a85a20b2c2d3be768f78ea"
      - { name: "flake8-docstrings", version: "==1.6.0" }

`linter.<analyzer_id>.npm_install`

type: boolean, string

For npm-published analyzers such as ESLint or stylelint, you can use the npm_install option to configure the behavior of npm dependencies installation. This option accepts one of the following values:

Value	Description
`true` (default)	Install dependencies via npm
`false`	Do nothing
`"production"`	Install only production dependencies
~~`"development"`~~	Deprecated. This will be removed

For example:

linter:
  eslint:
    npm_install: "production"
  stylelint:
    npm_install: false

When the npm_install option is not false, Sider will try installing dependencies in package.json, package-lock.json, or yarn.lock via the npm install or npm ci command.

If the installation fails for some reason or this option is set to false, Sider will use our default pre-installed version.

`linter.<analyzer_id>.gems`

This is an alias of linter.<analyzer_id>.dependencies. Please use dependencies instead of gems because it will be deprecated.

`linter.<analyzer_id>.jvm_deps`

DEPRECATED: This option is deprecated. Use the linter.<analyzer_id>.dependencies option instead.

`linter.<analyzer_id>.apt`

DEPRECATED: This option is deprecated. Use the linter.<analyzer_id>.dependencies option instead.

`linter.<analyzer_id>.include-path`

type: string, string[]

Some C/C++ analyzers can handle include paths like C/C++ preprocessors can. With Sider, the include-path option allows you to add directories to include search paths.

For example:

linter:
  clang_tidy:
    include-path:
      - myinclude
      - foo/include
      - /usr/include/libfastjson

Sider treats this option as a compilation option -I and passes it as command-line arguments internally. For example, Sider executes Clang-Tidy like this:

$ clang-tidy test.cpp -- -Imyinclude -Ifoo/include -I/usr/include/libfastjson

If you omit this option, Sider searches for header files that are part of your project and applies the directories of found files to the include search path.

`ignore`

type: string[]

This option allows you to ignore specific files. It helps to improve the analysis execution time and the analysis stability. The format of each ignore item follows gitignore(5).

In order to use this option, add it as a top-level in sider.yml like this:

ignore:
  - "*.pdf"
  - "*.mp4"
  - "*.min.*"
  - "images/**"

`branches.exclude`

type: string[]

This option allows you to exclude branches from the analysis. If there are branches that are unnecessary for your team to analyze, use the branches option. When setting this option, Sider will not analyze the branch specified in this option.

In order to use this option, add it as a top-level in sider.yml like this:

branches:
  exclude:
    - main
    - development
    - another_branch

With the above setting, Sider will ignore main, development and another_branch branches when these branches (pull requests) are updated or opened. That is, even if these branches have any changes, Sider will not send commit status and not review them.

If Sider is enabled to make status checks required on GitHub, you cannot merge a branch because Sider will not send the commit status to GitHub. In this case, you need to disable the check status setting on your GitHub repository page.

If you want to know more details about this GitHub setting, read the GitHub documentation; About required status checks and Enabling required status check.

You can also use regular expressions as the exclude pattern:

branches:
  exclude:
    - /^release-.*$/
    - /^dependabot/

In the above example, all branches such as release-20190304 or dependabot/bundler/aws-partitions-1.202.0 are ignored.

Sider Documentation

Ruby

Java

Kotlin

JavaScript and Flavors

CSS

PHP

Python

Swift

Go

C/C++

C#

Shell script

Dockerfile

Markdown

Others

Example Deployments

Releases

Custom Analysis Configuration

Configuration file

Analyzer-specific options

`linter.<analyzer_id>.root_dir`

`linter.<analyzer_id>.dependencies`

For Bundler

Install gems from third-party RubyGems repository

Install gems from Git repository

For npm

For Gradle

For APT

For pip

`linter.<analyzer_id>.npm_install`

`linter.<analyzer_id>.gems`

`linter.<analyzer_id>.jvm_deps`

`linter.<analyzer_id>.apt`

`linter.<analyzer_id>.include-path`

`ignore`

`branches.exclude`