How to configure and use TeamCI checks
TeamCI tests shared code standards across all organization
repositories. Code standards and configuration files for various
linting tools are 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.
The source is available for all checks. You’re welcome to open issues and submit PRs.
Send an email to support@teamci.co.
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/eslintrc.json
in the configuration repo. You can provide an
ignore file at eslint/eslintignore
in the configuration repo.
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
is present.
.editorconfigignore
is taken into account.
gometalinter/config.json
in the
configuration repo. Defaults are used otherwise.
phpcs/ruleset.xml
in the
configuration repo. Defaults are used otherwise.
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.