Running & Configuring Tools¶

Scrutinizer's Tools and Open-Source Tools¶

Scrutinizer supports various analysis tools, processes their results and provides you with a summary like the newly found issues, evaluates failure conditions, filters false-positives, code rating, automated patches, and provides additional help for certain issues.

The tools are open-source and Scrutinizer also provides own static analysis tools for many languages. The specific support of Scrutinizer's analysis depends on your language, but is usually designed to supplement the available open-source tools for that language. All of Scrutinizer's analysis is named <LANGUAGE_HERE> Scrutinizer on the available tools page.

Running Analysis Tools¶

All analysis tools run in our regular build environment. This gives you full control over what version of a tool runs, and you can install plugins for that tool.

For more advanced analysis tools, you can also install the dependencies of your project, and auto-generate code that is required to run your project and make the analysis more precise.

For many analysis tools, we provide a wrapper script that you can use to run the tool. This is generally a very lightweight shell script that automatically takes care of certain command options like for example defining a tool's output format and redirecting the output so that it can be picked up by the platform after the tool has run.

Besides, you can also run any other tool that is not explicitly listed, but that produces a compatible output format like the common checkstyle format.

Configuring Analysis Tools¶

Once you have added an analysis command to the build, there are usually various ways to tweak what kind of checks the tool can perform.

Scrutinizer's Analysis Tools¶

Scrutinizer's analysis tools are configured in your regular Scrutinizer configuration under the checks section. Only Scrutinizer's checks are configured there, but not those of open-source analysis tools.

Scrutinizer's checks can also be configured via the checks editor which modifies the checks section of your configuration that is saved on the website. Coding-style related configuration is configured via the coding-style editor and saved under the coding_style section in your configuration.

You can later choose to copy this configuration to your .scrutinizer.yml, but we generally recommend to keep the analysis related configuration on the website as that makes it easier to share between projects.

Open-Source Analysis Tools¶

For open-source analysis tools, we generally provide two different configuration modes. In the first mode, Scrutinizer manages the tool configuration for you, and in the second mode you provide the tool specific configuration like an eslint.rc file for example.

First Mode: Configuration managed by Scrutinizer¶

In the first mode, you can configure checks on the website and we will generate a tool specific configuration file as required by the respective tool. This file is automatically injected into the build environment and picked up by the analysis tool wrapper script like eslint-run that you find on the individual analysis tool pages.

For this configuration file to be used, you need to set the use_website_config: true flag for the analysis tool in your build configuration. For example for ESLint, this would look like this:

build:
  nodes:
    analysis:
      tests:
        override:
          - command: eslint-run
            use_website_config: true

Second Mode: Configuration provided by you¶

In the second mode, you can provide the configuration for example as part of your repository, and then you just use the wrapper script to execute the tool and have it setup the correct output formats. The use_website_config flag from above is not needed anymore in this case.

For example for ESLint, this would look like this:

build:
  nodes:
    analysis:
      tests:
        override:
          - command: eslint-run

This assumes that you have some sort of configuration file like an eslint.rc already in your repository.