Official Documentation

Supported Tools

The magic behind the scenes

  • Rubocop for Ruby
  • Eslint for JavaScript with Ember, React, and Vue.js plugins
  • Credo for Elixir
  • Shellcheck for Bash
  • Gometalinter for Go
  • PHPCS for PHP
  • Stylelint for CSS and SASS
  • Kubeval for Kubernetes manifest validation
  • cfnlint for CloudFormation template linting
  • Custom provided Docker Image

Introduction

TeamCI tests shared code standards across all organization repositories. Code standards and configuration files for various linting tools live in the teamci repo. TeamCI uses this repo for every check. If the teamci repo doesn't exist, then defaults are used instead. You can get started by forking TeamCI's configuration repo to YOUR_ORG/teamci. The configuration repo is also a great source for examples.

Source Code

The source is available for all checks. You're welcome to open issues and submit PRs.

Getting Help

Send an email to support@teamci.co.

RuboCop Configuration

This checks runs rubocop on Ruby files. There are two configuration options available: the rubocop configuration file and the RUBOCOP_OPTS environment variable.

TeamCI uses rubocop/config.yml if present the configuration repo. Here's an example.

TeamCI sets RUBOCOP_OPTS to the content of rubocop/RUBOCOP_OPTS if present in the configuration repo.

Eslint Configuration

For Javascript, JSX, and Node.js

This check runs eslint. This check requires a valid eslint/eslintrc.json in the configuration repo. You can provide an ignore file at eslint/eslintignore in the configuration repo. The following plugins are available:

Here's an example eslint/eslintrc.json with the ember plugin:

{
  "plugins": [ "ember" ],
  "extends": [
    "plugin:ember/recommended"
  ]
}

Gometalinter

Run a variety of linting against Go Code

This check runs gometalinter. You can provide a custom configuration file at gometalinter/config.json in the configuration repo. Defaults are used otherwise.

Shellcheck

For sh, bash, dash, and ksh

This check runs shellcheck on shell programs. Shellcheck requires an explicit list of files, so TeamCI tries to be smart enough about matching files for shellcheck. TeamCI will shellcheck executable files found with git ls-files with the following shebangs:

  • #!/usr/bin/env bash
  • #!/usr/bin/env sh
  • #!/usr/bin/env dash
  • #!/usr/bin/env ksh
  • #!/bin/bash
  • #!/bin/sh
  • #!/bin/dash
  • #!/bin/ksh

You can customize the file list by writing a custom ls files script. TeamCI will use the output from shellcheck/ls-files in the configuration repo if present. Here's an example.

Shellcheck reads configuration from the SHELLCHECK_OPTS environment variable. TeamCI sets to the content of shellcheck/SHELLCHECK_OPTS in the configuration repo if present.

Editorconfig

Enforce Tabs vs Spaces

This checks test that files are covered by editorconfig rules. This check only runs if .editorconfig is present. .editorconfigignore is taken into account.

PHP Code Sniffer

Find code smells in PHP code

This check runs phpcs. You can provide a custom configuration file at phpcs/ruleset.xml in the configuration repo. Defaults are used otherwise.

Credo

Static Analysis and Hints for Elixir

This check runs credo. You can provide a custom configuration file at credo/config.exs in the configuration repo. Defaults are used otherwise.

Stylelint

Lint CSS, SASS, SCSS, and LESS

This check runs stylelint. You can provide a custom configuration file at stylelint/config.json in the configuration repo. Defaults are used otherwise.

Note that creating a custom configuration file and extending the standard must use an absolute path. Here's an example:

{
  "extends": "/usr/local/lib/node_modules/stylelint-config-standard",
  "rules": { ... }
}

Custom

Write your own tests with Docker

Teams can write their own checks using the custom check. The custom check run as Docker containers, so teams can use whatever tools or languages they like.

Create custom/Dockerfile in the shared configuration repo. TeamCI builds the Docker image and runs a container with the code under test mounted /data. Exit code 0 is success, 7 is skip, and anything else is failure.

Here's an example.

kubeval

Kubernetes manifest validation

This check runs kubeval against YAML and JSON manifests. The default behavior checks .json, .yml, and .yaml that set apiVersion, kind, metadata, and kind keys. The lookup can be customized by providing an executable script in the configuration repo at kubeval/ls-files. The script should print all testable files to standard out. The script may use is-manifest.rb to filter out non-manifest files. Here's an example:

#!/usr/bin/env bash

set -euo pipefail

find . -type f -iname '*.yml' -print \
    | grep -vF 'fixtures' \
    | xargs is-template.rb

cfnlint

CloudFormation template linting

This check runs cfnlint against YAML and JSON manifests. The default behavior checks .json, .yml, and .yaml that have an AWSTemplateFormatVersion key. The lookup can be customized by providing an executable script in the configuration repo at cfnlint/ls-files. The script should print all testable files to standard out. The script may use is-template.pyto filter out non-stack files. Here's an example:

#!/usr/bin/env bash

set -euo pipefail

find . -type f -iname '*.yml' -print \
    | grep -vF 'fixtures' \
    | xargs is-template.py

Whitelist

Explicitly opt-in to checks

You may ignore checks because they're irrelevant or causing broken builds. The whitelist controls what checks to run against your code repos. Note that if you use the whitelist, you'll have to whitelist new future checks. Non-whitelisted checks are marked as skipped.

Whitelisting is easy. Create a whitelist file in your configuration repo. Here's an example:

$ cd teamci # your teamci config repo
$ echo "rubocop" > whitelist
$ echo "shellcheck" >> whitelist

This example whitelists rubocop and shellcheck. The check names match the names displayed in GitHub.

Built with Landen