Analyze a PHP library on GitHub¶

Create the project¶

1 Click on the Add project link located at the top of the right sidebar of your SymfonyInsight dashboard and on the GitHub tab.

2 Optionally, the first time you try to analyze GitHub projects, you'll be redirected to the GitHub website, where you can authorize SensioLabs to access to your repositories by clicking the Authorize application button.

3 After the previous optional redirection, SymfonyInsight will show you the list of your projects hosted at GitHub, both public and private. When a project is private, SymfonyInsight will display a lock icon next to its name.

Select a project to analyze and choose the PHP library project type to enable the rules for PHP libraries.

By default the "Auto-analyze on new commits" checkbox is checked, meaning that each commit on the repository will be automatically analyzed. We highly recommend you to keep this enabled to get analysis reports on each change in your project.

Finally, click on the Analyze button and SymfonyInsight will start the analysis immediately.

4 After the code analysis starts, you'll receive an email from GitHub explaining you that SymfonyInsight has added a SSH key to your repository.

This is necessary for SymfonyInsight to access the source code of your project. If you want to revoke access for SymfonyInsight, go to the Applications section of your GitHub profile.

Configure GitHub commit statuses on Pull Requests¶

Your project is now created and analyzed on each commit. The next logical step is to configure commit statuses on Pull Request to ensure the code quality is not decreasing directly from GitHub.

1 Click on the Edit project link located at the top of the right sidebar of the project page.

2 In the Automatic analysis settings section, check the Analyze Pull Requests checkbox (you need to check the Auto analyze checkbox before if it wasn't checked). Click on Update Project to save the settings.

Starting from now, each Pull Request created on the project repository will be analyzed and a commit status will be pushed to GitHub.

Commit success or failure status is chosen using the commit_failure_conditions configuration setting. By default, these conditions are the following:

1
2
3

commit_failure_conditions:
    - "project.severity.critical > 0"
    - "project.severity.major > 0"

This means that the commit status will be "Failure" (red) if the project has critical or major violations and "Success" (green) otherwise. This is of course configurable.

Configure the commit status failure conditions¶

You can define your own rules to check if a commit status should be "Success" or "Failure".

Here are all the variables available for your configuration:

 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
42
43

# Configure the failure conditions for your commit status
# If at least one of these conditions is verified, the commit status is displayed as failed
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"