Generic build settings contains settings for the enable/disable switch for the build, how many builds to keep, when to discard the build and the repository configuration, and so on.

If you're using Git, then you will have the ability to configure almost anything,such as being able to merge branches, committing and pushing back integrated changes, and so on.

We will just need to specify the branch as */master and the deployment key as we what saved before, from our repository provider.

The build settings are the only thing that you need to care about when deciding what to run; here you specify the target names and any additional options.

In our case, this is build, and by clicking Advanced, we can fill in the Properties field with codeception.suites=unit. This will allow us to run a test build without having to wait for long.

This is the longest section of the configuration. All the steps that will be performed for publishing the reports in the dashboard of the build, such as linking the documentation that you need to the various pieces, choosing what the thresholds required to decide are, and deciding when to mark the job failed, and so on are defined here.

The default threshold values defined here are quite high, so there isn't much that you should be worried about.

The only changes that we will need to make are regarding the reports generated by Codeception, which will provide the JUnit XML reports, the Clover XML reports, and the coverage in the HTML format.

Toward the end of the configuration page, you will find a section titled Publish Clover PHP Coverage Report, here update the Clover XML report path to tests/codeception/_output/coverage.xml, and the Publish HTML Report to tests/codeception/_output/coverage/. If you click on Advanced panel, then you will be able to modify the thresholds, and you can use them to decide how much coverage you require from your tests.

Just after this step, you will see Publish xUnit test results report, here change PHPUnit-3.x Pattern to tests/codeception/_output/report.xml. As you have done before, in the next step, you can configure the thresholds for the failed tests. By default, there shouldn't be any failed tests. So, all the fields will be set to 0. Do not change this setting, unless you want to live in shame.

Let's test everything and check if it is working as expected. Save the configuration, and click on Build Now to execute the job.

Once finished, you can head back to the page of the build, and then you will see the following graphs:

The project dashboard at a glance

Most of the graphs that appear on the right-hand side of the column are a quick way of understanding what triggered a failed build.

The two graphs, which are generated by PDepend, displayed at the very top show the so-called Overview Pyramid and the Abstraction Instability Chart. Both of them show interesting stats about your project, which you can depend on for taking some decisions in terms of performance, scalability, and maintainability.

At this point, you should have all the tools required for stepping forward and implementing, improving and excelling at testing and at automating your projects.