schmittjoh
So far, scrutinizer has already provided you with condensed output in the form of comments, and auto-generated patches. As of now, it also gives you access to the raw metric data that is gathered for your project. You can use these metrics to spot some of the most problematic areas and prioritize refactoring efforts, and also a couple of cool features that are in the pipeline (see below).
As a start, we support metrics generated by open-source tools like php code coverage (top project risks, least tested methods), php lines of code (general size metrics), and pdepend (complexity, and coupling information). A typical build configuration for these tools looks like:
before_commands:
- composer install --dev --prefer-source
tools:
php_code_coverage: true
php_pdepend:
excluded_dirs: [vendor]
php_loc:
excluded_dirs: [vendor]
Also, you can gather metrics for your own code. For example, scrutinizer benchmarks the serialization performance of jms/serializer on each code change. The benchmark script is located in the serializer repository and is then invoked as a custom command. On the website, this is shown as a nice column chart. The configuration looks like this:
before_commands:
- composer install --dev --prefer-source
tools:
custom_commands:
-
command: php tests/benchmark.php json 10 tests/benchmark.json
scope: project
output_file: tests/benchmark.json
iterations: 5
This also lays the foundation for some future features which will come shortly. One of these is statistical graphs which add a time dimension to all the gathered metrics and allow you to track development over time. The other feature is badges which will allow you to pose with your code coverage percentage for example :)
Stay tuned for these, and do not forget to enable the tools mentioned above so you can take full advantage of the upcoming features!
schmittjoh
This was one of the frequently requested features, and we are happy to announce that it is now also possible to have your Bitbucket repositories inspected by Scrutinizer-CI.
Bitbucket repositories receive almost the same level of integration as GitHub repositories except for pull requests which cannot be inspected. This is due to a limitation of the Bitbucket API at this point.
So, do not hesitate to add your Bitbucket repositories to benefit from continuous inspections today.
schmittjoh
Each time an inspection is run, Scrutinizer-CI executes all the tools that you have configured in your build config. If you have configured multiple tools (which is the case for most projects), the system may decide to execute certain tools in parallel to speed up the process.
So far, you had to wait for all results to come in before they were displayed on the website. As of now, as soon as there are results available, you will see a small bar on the progress page which allows you to view these results instantly:
This provides you with feedback even faster. Enjoy!
schmittjoh
We have added support for another great tool which makes PHP support even better.
The latest addition is the Copy/Paste Detector written by Sebastian Bergmann. It helps you identify code that is duplicated in several places in your code base.
You can enable it on your projects by adding a single line:
tools:
# ...
php_cpd: true
For a complete configuration, see the documentation for PHP Copy/Paste Detector.
Enjoy :)
schmittjoh
In addition to the existing tools, you can now also generate code coverage information for your code using PHPUnit and the xdebug extension.
Here is an example of how this can look like:
As with the other tools, scrutinizer filters code coverage data to only display what is relevant to your code changes. For Pushes and Pull Requests, that means only code coverage information for new code is displayed. For manual reviews, the entire code coverage for your project is generated.
Since generating code coverage can severely slow down your tests especially for bigger projects, only generating it for a a small subset will make that information available a lot faster.
You can enable generating code coverage with the following configuration:
# Since we need to run part of your test suite, most libraries will first
# need to install vendors, for example via composer.
before_commands:
- composer install --dev
tools:
php_code_coverage: true
For a more advanced configuration, you can also view the dedicated documentation about code coverage for PHP.