Sider Documentation

Sider Documentation

  • Enterprise
  • News
  • Sider Top

›Getting Started

Getting Started

  • Home
  • Intro Videos
  • Setting up Sider
  • Dashboard Overview
  • Repository Settings
  • Custom Analysis Configuration
  • Recommended Ruleset
  • Working with Issues
  • Permissions
  • Skip Analyzing

Analysis Tools

    Ruby

    • RuboCop
    • Reek
    • Querly
    • Rails Best Practices
    • Brakeman
    • HAML-Lint
    • Slim-Lint (beta)

    Java

    • Checkstyle
    • PMD
    • JavaSee

    Kotlin

    • ktlint (beta)
    • detekt (beta)

    JavaScript and Flavors

    • ESLint
    • JSHint
    • TyScan
    • CoffeeLint
    • TSLint (deprecated)

    CSS

    • stylelint
    • SCSS-Lint (deprecated)

    PHP

    • PHP_CodeSniffer
    • PHPMD
    • Phinder

    Python

    • Flake8
    • Pylint (beta)

    Swift

    • SwiftLint

    Go

    • GolangCI-Lint

    C/C++

    • Cppcheck
    • cpplint
    • Clang-Tidy (beta)

    C#

    • FxCop (beta)

    Shell script

    • ShellCheck

    Dockerfile

    • hadolint

    Markdown

    • remark-lint

    Others

    • Goodcheck
    • Misspell
    • LanguageTool (beta)
    • PMD CPD (beta)

Custom Rules

  • Intro to Custom Rules
  • Goodcheck
  • Tips & Tricks

Advanced Settings

  • Inline Comments
  • Private Dependencies
  • Restricting access to Close button
  • Transferring a repository

Billing and Plans

  • Billing and Plans

Troubleshooting

  • Troubleshooting

Enterprise

  • Outline
  • System Overview
  • Installation
  • Configuration
  • Operation
  • Update
  • Load Balancer
  • MySQL
  • Redis
  • MinIO
  • Amazon S3
  • GitHub Enterprise Server
  • Clustering
  • Example Deployments

    • Single Node with Docker Compose

    Releases

    • Overview
    • January 2021
    • December 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • February 2020
    • January 2020
    • November 2019
    • Older releases

News

  • 2021
  • 2020
  • 2019
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:

NameTypeDescription
repostringGit repository location. The repository can be accessed via HTTP(S)/SSH protocols.
branchstringBranch name.
tagstringTag name.
refstringRef 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:

ValueDescription
true (default)Install dependencies via npm or Yarn.
falseDo not install any dependencies.
"production"Install only dependencies for production.
"development"Install only dependencies for development.
OthersFail 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.

← Repository SettingsRecommended Ruleset →
  • Configuration file
    • Analyzer-specific options
  • linter.<analyzer_id>.root_dir
  • linter.<analyzer_id>.gems
    • Understanding the analyzer version
    • Install gems from Gemfile.lock
    • Install gems from third-party RubyGems repository
    • Install gems from Git repository
  • linter.<analyzer_id>.npm_install
  • linter.<analyzer_id>.jvm_deps
  • linter.<analyzer_id>.apt
  • linter.<analyzer_id>.include-path
  • ignore
  • branches.exclude
Sider Documentation
Docs
Getting StartedAnalysis ToolsEnterprise
Sider
Sider TopTerms of ServicePrivacy
Social
BlogGitHubStar
Copyright © 2021 Sider, Inc.