The Configuration¶

Introduction¶

Various parts of Scrutinizer can be tweaked through configuration.

The configuration can be spread across different locations. Regardless of where the configuration is stored (on the website, or as a file in your git repository), it is always in the same Yaml format and has the same structure.

We recommend spreading the configuration across these locations and not to keep the configuration just in a single place.

Structure¶

The general structure of the configuration looks as follows:

build:
    # ...

filter:
    # ...

checks:
    # ...

coding_style:
    # ...

build_failure_conditions:
    # ...

tools:
    # ...

credentials:
    # ...

Build¶

The build contains everything related to running test, deployment and analysis commands.

Please check the individual chapters on the left side, or see the complete reference.

Filter¶

The filter section defines which files are analyzed, where dependencies are located and which files should be completely ignored.

Checks¶

The checks section configures Scrutinizer's own analysis tools (js-scrutinizer-run, php-scrutinizer-run, ruby-scrutinizer-run, etc.). It does not configure third-party analysis tools.

Coding-Style¶

The coding-style section configures Scrutinizer's coding-style fixes. It can be configured via the coding-style editor on the website.

Build Failure Conditions¶

The build failure conditions section allows you to define failure conditions where a build should be failed based on findings in the analysis.

Findings can be that code coverage has decreased below a certain point, or that new issues have been found, etc.

Tools¶

The tools section is mostly a legacy section that allowed to configure analysis tools. You can now run analysis tools directly in the build environment.

The only still supported key in this section is external code coverage.

Credentials¶

The credentials section allows to define HTTP basic credentials for remote hosts that we will automatically add to your build nodes.