Stickler CI will be shutting down in May 2023.

Stickler CI Documentation

Want to customize the various linters Stickler CI uses? This page contains reference documentation on how to customize each of the tools that Stickler offers.

If you're still looking for answers, please tweet us @sticklerci or email us at support@stickler-ci.com.

Stickler CI Configuration

Stickler CI is configured through a yaml file in your repository. This yaml file controls which linters are enabled and what their options are.

Put your .stickler.yml file in the root directory of your project. An example file is

---
linters:
    flake8:
    eslint:
        config: './eslint.config'
    csslint:

files:
    ignore:
        - 'src/generated/*'
        - 'webroot/bower_components/*'

In this example we've enabled flake8, eslint, and csslint. We are providing a config file for eslint, and have ignored all files in src/generated/* and webroot/bower_components directories.

General Options

You can configure certain aspects of how Stickler CI inspects your code:

  • The files section lets you define which files should be excluded from all checks. It should be a newline separated list of files that accept glob patterns like src/generated/*.py.
  • The branches section lets you define branches that Stickler CI will ignore. You can use this option to disable reviews when a pull request is against a particular set of branches.
  • The review section lets you change how Stickler CI handles review output.

An example of the above configuration options is:

---
files:
    # Ignore the files that match these glob patterns.
    # Be careful to quote strings as `*` has special
    # meaning in YAML files.
    ignore:
        - 'src/generated/*.py'
        - 'webroot/bower_components/*'

branches:
    # Ignore pull requests to the named branches
    ignore:
        - 'wip'
        - 'feedback'

review:
    # Don't use 'failure' build status when
    # a pull request contains style errors.
    fail_on_comments: false

Automatic Fixing

Stickler CI can automatically fix style errors in several languages. Fixes are added to each pull request as a commit from the stickler-ci user. To enable automatic fixing add the fixers block to your .stickler.yml configuration file:

---
linters:
  # Configured linters

fixers:
    enable: true

Once fixers are enabled for your project, you must select which linters should apply automatic fixes. The following linters support automatic fixing:

To enable automatic fixing for a linter add the fixer option:

---
linters:
    phpcs:
        standard: PSR2
        fixer: true
    eslint:
        config: eslint.json
        fixer: true

Custom Builds

On paid plans you can enable custom builds for Flake8 and ESLint. Custom builds allow your reviews to enable additional packages that are not installed by default.

Ansible 4.2.0

Apply Ansible Lint to ansible playbooks/YAML files.

Options

  • ignore The rule id/tags that you do not want applied.

Example

---
linters:
    ansible:
        ignore: 'ANSIBLE0004,ANSIBLE0005'

Bash, Zsh, Sh 0.8.0

Check bash, zsh and sh scripts with shellcheck for lint and common mistakes.

Options

  • shell Select which shell dialect to check against. Valid values are: bash, sh, ksh or zsh. Default: sh
  • exclude Comma separated IDs of checks to ignore. Example: SC2154,SC2069

Example

---
linters:
    shellcheck:
        shell: bash
        exclude: 'SC2154,SC2069'
    

Chef 16.3.0

Check chef scripts with Foodcritic.

Options

  • path If your cookbooks aren't stored in the root, use this to set the path that foodcritic runs against. Example: path = cookbooks

CSS

CSSLint 1.0.4

Check CSS files with csslint.

Both warnings and errors will be turned into code review comments. If you don't want code review comments for specific rules, you should ignore them via the ignore option.

Options

  • ignore A comma separated list of rule ids to ignore.

Example

---
linters:
    csslint:
        ignore: 'box-model,ids'

Stylelint 14.5.3

Check CSS, LESS, Sass, and SCSS files with stylelint.

Both warnings and errors will be turned into code review comments. If you don't want code review comments for specific rules, you should ignore them via your configuration file.

Options

  • config The path to your configuration file. If undefined, stylelint will use its configuration loader . If no configuration file is found stylelint-config-standard will be used.
  • fixer Set to true to enable automatic fixing when possible.

Example

---
linters:
    stylelint:
        config: 'stylelintrc.json'

Elixir

Credo 1.6.3

Check Elixir files with credo.

All enabled output from credo will be reported as code review comments. Use the configuration options or configuration file to refine the feedback you get.

Options

  • checks Only include checks that match the given strings.
  • config-name If your .credo.exs defines multiple non-default names, you can define the name Stickler CI should apply with this option.
  • ignore-checks Ignore checks that match the given strings. Multiple values can be provide by a comma separated string. e.g. readability,duplicated
  • all Show all issues.
  • all-priorities Show all issues including low priority ones.
  • strict Operate in strict mode showing all issues and priorities.

Example

---
linters:
    credo:
        ignore-checks: duplicated

Go

Check go-lang code with golint.

Options

  • min_confidence Set the confidence level of a problem before it is reported.
  • fixer Set to true to enable gofmt style corrections.
  • ignore A list of regular expression patterns. When a message or filename matches any pattern it will be excluded from review comments.

Example

---
linters:
    golint:
        min_confidence: 0.85
        fixer: true
        ignore:
            - 'exported function \w+ should have comment'

Java 9.0.1

Check java code with checkstyle.

Options

  • config Define the path to your checkstyle.xml file. This option is required.

When checkstyle is run a properties file will be generated defining the following keys: config_loc, samedir, project_loc, basedir. All of these properties will point at the root directory of your repository.

Example

---
linters:
    checkstyle:
        config: ./checkstyle.xml

Javascript

ESLint 6.8.0

Check Javascript, and JSX code with eslint. In addition to the core ESLint rules, we also provide rule presets for React and Ember.js

When Stickler CI runs ESLint it does not install any of your repository dependencies. Because of this, rules that operate on import checking or typechecking rules will likely not work.

Options

  • config Provide a path to the JSON config file for eslint.
  • fixer Set to true to enable automatic fixing.
  • install_plugins Set to true to install all packages matching eslint-[config|preset] from your repository's root level package.json. Using this option requires a paid plan.

Example

---
linters:
    eslint:
        config: './eslint.config'

Usage with React

To get started linting React applications, you can use the following ESLint configuration:

// in eslint.config
{
  "extends": ["eslint:recommended", "plugin:react/recommended"],
  "plugins": ["react"]
}

Usage with Ember.js

To start linting Ember.js projects, you can use the following ESLint configuration:

// in eslint.config
{
  "extends": [
    "eslint:recommended",
    "plugin:ember/recommended",
    "plugin:ember-best-practices/recommended"
  ],
  "plugins": ["ember", "ember-best-practices"]
}

Usage with Vue

To start linting Vue projects, you can use the following ESLint configuration:

// in eslint.config
{
  "extends": [
    "eslint:recommended",
    "plugin:vue/recommended",
  ],
  "plugins": ["vue"]
}

Stickler CI offers the following ESLint plugins/presets:

  • eslint:recommended
  • airbnb
  • prettier
  • @meteorjs/eslint-config-meteor
  • eslint-config-standard
  • parser:@typescript-eslint/parser
  • plugin:ember/base
  • plugin:ember/recommended
  • plugin:ember-best-practices/base
  • plugin:ember-best-practices/recommended
  • plugin:ember-best-practices/experimental
  • plugin:chai
  • plugin:html
  • plugin:jest
  • plugin:meteor/recommended
  • plugin:mocha
  • plugin:node
  • plugin:prettier
  • plugin:promise
  • plugin:react/all
  • plugin:react/recommended
  • plugin:react-native/all
  • plugin:tape/recommended
  • plugin:@typescript-eslint
  • plugin:@typescript-eslint/eslint-recommended
  • plugin:@typescript-eslint/recommended
  • plugin:@typescript-eslint
  • plugin:vue/base
  • plugin:vue/essential
  • plugin:vue/strongly-recommended
  • plugin:vue/recommended

If there is a preset you'd like to see support for drop us a line.

JSHint 2.13.4

Check Javascript code with jshint. If you don't supply a config file the jshint defaults will be used.

Options

  • config Provide a path to the json config file for jshint.

Example

---
linters:
    jshint:
        config: './jshint.config'

StandardJs 16.0.4

Use StandardJs to check Javascript. Standard offers easy to use style rules with no configuration to manage.

Example

---
linters:
    standardjs:

Kotlin 0.43.2

Check Kotlin code with ktlint.

Options

  • android Enable Android Kotlin Style Guide compatibility.
  • config Path to .editorconfig if your project uses it.
  • experimentalEnable experimental rules.
  • fixer Set to true to automatically correct fixable errors.

Example

---
linters:
    ktlint:
        android: true

Lua 0.23.0

Check Luascript with luacheck.

Options

  • config The configuration file you want to use with luacheck. See the luacheck documentation for more information.

Example

---
linters:
    luacheck:
        config: 'luacheckrc'

Markdown 14.0.2

Check markdown with remark-lint. Any .remarkrc files in your repository will be used.

We have the following remark-lint presets installed:

  • remark-preset-lint-recommended
  • remark-preset-lint-consistent
  • remark-preset-lint-markdown-style-guide

Options

  • fixer Set to true to automatically correct fixable errors.

Example

---
linters:
    remarklint:
        fixer: true

PHP

PHPCS 3.7.1

Check PHP, Javascript and or CSS code with phpcs.

Options

  • standard The coding standard to use. By default the PSR2 standard is used. You can use one of the supported standards:
    • CakePHP (alias for latest CakePHP standard)
    • CakePHP4
    • CakePHP3
    • Drupal
    • DrupalPractice
    • PEAR
    • PSR1
    • PSR2
    • PSR12
    • SlevomatCodingStandard
    • Squiz
    • WordPress
    • WordPress-Core
    • Zend
    Or use a custom ruleset defined in your project with a phpcs.xml file.
  • extensions The extensions to check. By default only .php files will be checked.
  • tab_width The number of spaces to convert tabs into, this is useful for projects using tabs for indentation.
  • ignore A comma separated list of glob patterns of that should be excluded from PHPCS analysis.
  • exclude A comma separated list of sniff names to ignore.
  • fixer Set to true to automatically correct fixable errors.

Example

---
linters:
  phpcs:
      standard: 'PSR2'
      exclude: 'Generic.Files.LineLength,PSR2.Files.EndFileNewline'
      ignore: 'tests/fixtures/generated/*'
      extensions: 'php,ctp'
      tab_width: 4
      fixer: true

PHPMD 2.13.0

PHPMD helps you detect potential bugs, suboptimal code, overcomplicated code as well as unused parameters, methods and properties

Options

  • ruleset Either a comma separated string of phpmd rulesets or the path to your phpmd configuration file. Defaults to cleancode,codesize,unusedcode
---
linters:
  phpmd:
      ruleset: cleancode,codesize

Puppet 2.5.2

Check puppet manifests with puppet-lint, against the puppetlabs style guide. .puppet-lintrc files will be respected, to allow each project to disable checks. A list of checks can be found by running puppet-lint --help locally.

Python

Black 22.8.0

Check code for conformance to the black code style. Any files that do not match will be listed in an issue comment.

Options

  • config Path to your pyproject.toml file. This file should contain a [tool.black] section.
  • py36 Enable usage of Python 3.6 only syntax.
  • fixer Set to true to automatically correct fixable errors.

Example

---
linters:
    black:
        config: ./pyproject.toml
        fixer: true

Flake8 5.0.4

Check Python code with flake8. By default python 2.7 is used to run flake8. You can select python3 using the python option.

Options

  • python Choose which python version to use. Accepts either 2 (python 2.7) or 3 (python 3.6).
  • config Path to your project's flake8 configuration file.
  • ignore Set which pep8 error codes you wish to ignore.
  • exclude Exclude files matching these comma separated patterns (default: .svn, CVS, .bzr, .hg, .git)
  • filename When parsing directories, only check filenames matching these comma separated patterns (default: *.py)
  • select Select errors and warnings (e.g. E,W6)
  • max-line-length Set maximum allowed line length (default: 79)
  • format Set the error format [default|pylint|]
  • max-complexity McCabe complexity threshold
  • isort Set to true to enable isort linting rules. Using isort will require you to have either an .editorconfig file, .isort.cfg file, or isort section in your setup.cfg or tox.ini files.
  • fixer Set to true to automatically correct fixable errors.
  • plugins A list of plugins to install when doing reviews. The following packages are available:
    • flake8-bugbear
    • flake8-django
    • flake8-docstrings
    • flake8-isort
    • flake8-pytest
    • flake8-tidy-imports
    Using the plugins option requires a paid plan

Example

---
linters:
    flake8:
        python: 3
        ignore: 'W28'
        max-line-length: 80
        max-complexity: 20
        fixer: true

pep8

Check python code with pep8. By default python 2.7 is used to run flake8. You can select python3 using the python option.

Options

  • python Choose which python version to use. Accepts either 2 (python 2.7) or 3 (python 3.6).
  • config Path to your project's pep8 configuration file.
  • ignore Set which pep8 error codes you wish to ignore.
  • exclude Exclude files or directories which match these comma separated patterns (default: .svn, CVS, .bzr, .hg, .git)
  • filename When parsing directories, only check filenames matching these comma separated patterns (default: *.py)
  • select Select errors and warnings to output. Other error types will be suppressed. (e.g. E,W6)
  • max-line-length Set maximum allowed line length (default: 79)
  • fixer Set to true to automatically correct fixable errors.

Example

---
linters:
    pep8:
        python: 3
        ignore: 'W28'
        max-line-length: 120
        fixer: true

py3k 1.9.5

Check python code with pylint's py3k mode. This linter will help you write python code that is forwards compatible with python 3.

Options

  • ignore A comma separated list of error codes to ignore.
  • ignore-patterns A comma separated list regular expressions of paths/files to ignore.

Example

---
linters:
    py3k:
      ignore: 'W1618,W1655'
      ignore-patterns: 'generated/.*'

Pytype 2022.09.27

Apply pytype on your code. Pytype checks and infers types for your Python code - without requiring type annotations.

Options

  • config Path to your ini file or setup.cfg file. This file should contain a [pytype] section.
  • fixer Set to true to merge generated pyi files with merge-pyi.

Example

---
linters:
    pytype:
        config: ./setup.cfg
        fixer: true

Ruby 1.22.1

Check ruby with rubocop.

Options

  • display_cop_names Set to true to pass display cop names in offense messages.
  • fixer Set to true to automatically correct fixable errors.

Any .rubocop.yml files in your repository will be respected, as described here.

Example

---
linters:
    rubocop:
        display_cop_names: true
        fixer: true

Sass 1.13.1

Check sass and scss files with sass-lint.

Options

  • ignore A comma separated list of files to ignore.
  • config Project relative path to the sass-lint config file you want applied.

Example

---
linters:
    sasslint:
        config: ./sasslint.conf
        ignore: vendor/*.scss

Swift 0.45.1

Check swift files with swiftlint.

Options

There are no configuration file options for this linter. Any .swiftlint.yml files will be respected as described in the swiftlint documentation.

Example

---
linters:
    swiftlint:

TypeScript 5.20.1

Check typescript code with tslint. You need to include a tslint.json configuration file in your project or use the config option to provide a path to a config file.

Options

  • config Define a custom location for your tslint.json configuration file.
  • project Provide the location to your tsconfig.json file. This option also enables rules that require the type checker.

Example

---
linters:
    tslint:
        project: ./tsconfig.json
        config: build/tslint.json

Stickler CI offers the following tslint plugins/presets:

  • tslint:recommended
  • tslint-config-airbnb
  • tslint-react

YAML 1.25.0

Check YAML (Yet Another Markup Language) files with yamllint. This is handy to examine confiugration files for many tools, and heira data in puppet.

Options

  • config Provide a path to the yaml config file for yamlhint.

Example

---
linters:
    yamllint:
        config: ./yamllint.conf

Didn't find what you were looking for?

Please tweet at us @sticklerci or email us at support@stickler-ci.com and we will help you out.