Edit

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"
    ext: "js,jsx"

  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:

1. Analyzer-specific options (under linter)
   • linter.brakeman
   • linter.checkstyle
   • linter.clang_tidy
   • linter.code_sniffer
   • linter.coffeelint
   • linter.cppcheck
   • linter.cpplint
   • linter.detekt
   • linter.eslint
   • linter.flake8
   • linter.fxcop
   • linter.golangci_lint
   • linter.goodcheck
   • linter.hadolint
   • linter.haml_lint
   • linter.javasee
   • linter.jshint
   • linter.ktlint
   • linter.languagetool
   • linter.misspell
   • linter.phinder
   • linter.phpmd
   • linter.pmd_cpd
   • linter.pmd_java
   • linter.pylint
   • linter.querly
   • linter.rails_best_practices
   • linter.reek
   • linter.remark_lint
   • linter.rubocop
   • linter.scss_lint
   • linter.shellcheck
   • linter.stylelint
   • linter.swiftlint
   • linter.tslint
   • linter.tyscan
2. 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 (it will be sufficient in most cases).

linter.<analyzer_id>.gems

Type: string[], hash[]

Some analyzers written in Ruby can be customized with third-party gems. With Sider, you can use Bundler to install any gem. The following is an example of installing RuboCop plugins or configuration gems:

linter:
  rubocop:
    gems:
      - name: "meowcop"
        version: "1.17.0"

You can also set the version of the analyzer you want to use. However, the version must meet Sider's constraints. Please refer to each analyzer page.

linter:
  rubocop:
    gems:
      - name: "rubocop"
        version: "0.66.0"

Understanding the analyzer version

Sider decides the analyzer version in the following order:

1. gems option in sider.yml
2. Gemfile.lock
3. The default version

However, if the version written in Gemfile.lock does not satisfy our constraints, that version is skipped.

Install gems from Gemfile.lock

If you want to additionally install a specific gem written in Gemfile.lock, you can omit the version as follows:

linter:
  rubocop:
    gems:
      - "rubocop-rspec"

If the gem is not found in Gemfile.lock, the latest version is installed.

Install gems from third-party RubyGems repository

You can select an alternate RubyGems repository as a gem source via the source option:

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

Install gems from Git repository

You can also install a gem in a git repository. Please note that the git option cannot be specified with version or source.

linter:
  rubocop:
    gems:
      - 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"

git option has options below:

Name	Type	Description
repo	string	Git repository location. The repository can be accessed via HTTP(S)/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 guide and configure SSH key.

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 has the following values:

Value	Description
true (default)	Install dependencies via npm or Yarn.
false	Do not install any dependencies.
"production"	Install only dependencies for production.
"development"	Install only dependencies for development.
Others	Fail analysis.

For example:

linter:
  eslint:
    npm_install: "development"
  stylelint:
    npm_install: false

When the npm_install option is not false, Sider will try as follows:

1. Check if package.json exists. If not present, Sider uses the default version of the analyzers.
2. If package.json and yarn.lock exist, Sider runs the yarn install command.
3. If package.json and package-lock.json exist, Sider runs the npm ci command.
4. If package.json exists but none of yarn.lock and package-lock.json exist, Sider runs the npm install command.
5. Checks if the analyzer is installed in the node_modules directory.
6. If installed, Sider uses the installed version.
7. If not installed (for any reason), Sider uses the pre-installed default version.
   • In this case, Sider shows warnings.

When the option is false, Sider will skip these installation steps and analyze with the pre-installed default version. You might want to set the option to false if you don't configure analyzer and don't want to see warnings.

linter.<analyzer_id>.jvm_deps

Type: string[][]

For JVM tools such as Checkstyle or ktlint, this option allows you to load third-party rules or plugins. For example:

linter:
  checkstyle:
    jvm_deps:
      - [com.github.sevntu-checkstyle, sevntu-checks, 1.37.1]

Each element of a jvm_deps array must have 3 properties: [group, name, version]. These 3 properties follows the Maven repository style, and you can install dependencies registered in Maven repositories:

The currently supported repositories are:

• Maven Central Repository
• JCenter Maven Repository
• Google's Maven Repository

linter.<analyzer_id>.apt

Type: string, string[]

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

The apt option allows you to specify a list of development packages your project depends on. The packages must satisfy the conditions below:

• Packages must be compatible with our Docker image.
• Package names must be suffixed with "-dev".
• Each package name must be formatted as <name> or <name>=<version>.

Below is an example of how you install the latest version of libgdbm-dev and the specific version (0.99.8-2) of libfastjson-dev.

linter:
  clang_tidy:
    apt:
      - libgdbm-dev
      - libfastjson-dev=0.99.8-2

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.