Documentation


Configuration options reference

SymfonyInsight defines dozens of configurable options. Most of them are related to analysis rules and they are explained in each rule documentation. The general purpose project configuration options are explained below.

Execution environment

php_version

Configure the PHP version SymfonyInsight should use to analyze your project. It can be defined to 7.2, 7.3, 7.4, 8.0, 8.1, 8.2 or 8.3. If not present, the latest PHP version will be used.

Example:

1
php_version: 8.3

os_version

Configure the Operating System SymfonyInsight should use to analyze your project. For the moment, SymfonyInsight only supports Debian Buster (buster). More OS could be added in the future.

Example:

1
os_version: buster

php_ini

Allows to set the value of any PHP configuration directive. This is useful to modify the behavior of the PHP engine used to execute your application while analyzing it. Although you can set any of the php.ini directives, this option is commonly used to load custom PHP extensions.

SymfonyInsight includes built-in support for the following PHP extensions: bcmath.so, bz2.so, curl.so, gd.so, gettext.so, gmp.so, iconv.so, intl.so, mbstring.so, mcrypt.so, mysql.so, openssl.so, pcntl.so, pdo_mysql.so, pdo_pgsql.so, readline.so, soap.so, xsl.so, zip.so, zlib.so.

If your project requires another PHP extension, read the related Enabling PHP extensions guide.

Example:

1
2
3
php_ini: |
    extension=openssl.so
    extension=mcrypt.so

pre_composer_script

Allows to execute any custom command just before executing the Composer command that installs your project's dependencies. This option is useful to setup your project before analyzing it.

Example:

1
2
3
pre_composer_script: |
    #!/bin/bash
    sudo apt-get update

post_composer_script

Allows to execute any custom command just after executing the Composer command that installs your project's dependencies.

Example:

1
2
3
4
post_composer_script: |
    #!/bin/bash
    ./bin/console cache:warmup --no-interaction
    ./bin/console app:build-documentation --no-interaction

Analysis context

rules

Enables/disables rules and defines configuration options for them.

You can find a detailed list of the available rules with their options in the Advanced configuration section of your projects, by clicking on View default configuration.

Example:

1
2
3
4
5
6
7
8
9
rules:
    # Disable a rule
    php.class_too_long:
        enabled: false

    # Configure a rule
    php.class_too_long:
        max_length: 2000
        threshold:  10

ignore_branches

Allows to prevent code quality analyses for some branches.

By default, whenever you push any commit to your code repository, a new analysis is triggered. This option allows to prevent those analyses when the pushed code belongs to any of the excluded branches.

This option is useful to ignore branches that don't contain code (such as the gh-pages branch used by GitHub Pages) and branches which are no longer maintained in the project.

Example:

1
2
ignore_branches:
    - gh-pages

working_directory

Allows to specify a subdirectory to analyze. The project is analyzed from its root by default.

Example:

1
working_directory: myapp

global_exclude_dirs

Configure the directories excluded from the analysis. By default, this setting excludes directories commonly used to store tests and third-party libraries.

Example:

1
2
3
4
5
6
7
8
9
10
11
global_exclude_dirs:
    - vendor
    - vendors
    - test
    - tests
    - Tests
    - spec
    - features
    - Fixtures
    - DataFixtures
    - var

exclude_patterns

This setting is a fine-grained version of the global_excluded_dirs option. It allows to exclude files based on glob expressions. For example, you may want to analyze the src/ directory except for the files called Kernel.php and ApiKernel.php.

Example:

1
2
exclude_patterns:
    - 'src/*Kernel.php'

GitHub Commit status

commit_failure_conditions

Configure the failure conditions for your commit status. If at least one of these conditions is verified, the commit status is displayed as failed.

Example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
commit_failure_conditions:
    # By severities count (default configuration, any change will override it)
    - "project.severity.critical > 0"
    - "project.severity.major > 0"

    # # By other severities count
    # - "project.severity.minor > 0"
    # - "project.severity.info >= 15"
    #
    # # By categories count
    # - "project.category.architecture > 0"
    # - "project.category.bugrisk > 0"
    # - "project.category.codestyle > 0"
    # - "project.category.deadcode > 0"
    # - "project.category.performance > 0"
    # - "project.category.readability > 0"
    # - "project.category.security > 0"
    #
    # # By project grade (none, bronze, silver, gold, platinum)
    # - "project.grade < gold"
    #
    # # By total violations count
    # - "project.violations > 150"
    #
    # By severities count, limited to the violations concerning files edited by the current PR
    # - "pr.severity.critical > 0"
    # - "pr.severity.major > 0"
    # - "pr.severity.minor > 0"
    # - "pr.severity.info >= 15"
    #
    # # By categories count, limited to the violations concerning files edited by the current PR
    # - "pr.category.architecture > 0"
    # - "pr.category.bugrisk > 0"
    # - "pr.category.codestyle > 0"
    # - "pr.category.deadcode > 0"
    # - "pr.category.performance > 0"
    # - "pr.category.readability > 0"
    # - "pr.category.security > 0"
    #
    # # By total violations count, limited to the violations concerning files edited by the current PR
    # - "pr.violations > 150"