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 User Accounts

When enabling private repositories Stickler CI will add the stickler-ci user as a collaborator on your repository. This process will consume a collaborator seat in your organization's plan.

To save on collaborator seats, your organization may already have an 'automated user account' or a 'robot account' for other integrations. By giving Stickler CI access to your existing robot account, Stickler CI will use that account when creating pull request comments. When using a custom user account, you will need to manage Stickler CI's access like any other team member. To enable a custom user account use the Add User Account button to the right of your organization's name.

Custom User Accounts are only available on our Legacy OAuth integration. GitHub applications do not need to add collaborators to your repositories.

Ansible 3.4.23

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 8.11

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 13.1.1

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'

Elixir

Credo 0.10.2

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 8.11

Check java code with checkstyle 8.11.

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 5.7.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

Options

  • config Provide a path to the JSON config file for eslint.
  • fixer Set to true to enable automatic fixing.

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
  • plugin:mocha
  • plugin:chai
  • plugin:html
  • plugin:tape/recommended
  • plugin:react/all
  • plugin:react/recommended
  • plugin:ember/base
  • plugin:ember/recommended
  • plugin:ember-best-practices/base
  • plugin:ember-best-practices/recommended
  • plugin:ember-best-practices/experimental
  • plugin:prettier
  • 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.9.6

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 12.0.1

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

Example

---
linters:
    standardjs:

Lua 0.21.2

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'

PHP 3.3.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, PEAR, PSR1, PSR2, SlevomatCodingStandard, Squiz, WordPress, WordPress-Core or Zend.
  • 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

Puppet 2.3.6

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 18.9b0

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 3.4.1

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
  • fixer Set to true to automatically correct fixable errors.

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.3

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

Options

The py3k linter has no options.

Example

---
linters:
    py3k:

Ruby 0.58.2

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.12.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

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.11.0

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.

Example

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

Stickler CI offers the following tslint plugins/presets:

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

YAML 1.12.1

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.