Scrutinizer allows you to run custom analysis commands on each inspection. These commands are run in addition to other checks you have configured.
Custom checks run in our regular build environment and are just regular shell commands that
produce one of our supported output formats like
checkstyle. A custom command can either
be some script you have written or can be an open-source tool for which we do not have any
special integration yet.
In the build environment, your code is checked out at
~/build which is also the working
directory by default.
If you write your own scripts, you would typically iterate over all files in this directory and then invoke your scanning logic for each file. More sophisticated tools might need additional passes over the files, but it depends on what you plan to check.
build: tests: override: - command: check.sh # your custom check script. analysis: file: # The output filename format: 'general-checkstyle' # The supported format by Scrutinizer
If you have custom output file in your command, you need to specify the file path in the
file option. Otherwise
you can also leave out the
file option, in this case, the result is expected to be sent to STDOUT instead. If you
still want to show progress output in the latter case, make sure to send it to STDERR.
The output of the command is expected to be checkstyle
xml file with the following structure:
<?xml version="1.0" encoding="UTF-8"?> <checkstyle version="1.0.0"> <file name="/path/to/code/myfile.php"> <error line="2" message="msg1" source="Ruleset.RuleName"/> <error line="20" message="msg2" source="Generic.Constant"/> <error line="47" message="msg3" source="ScopeIndent"/> <error line="47" message="msg4" source="Format.MultipleAlignment"/> <error line="51" message="msg5" source="Comment.FunctionComment"/> </file> </checkstyle>
source attribute can be formatted as
Ruleset.RuleName or simply
If your custom command requires some set-up before it can perform its checks, you can either let it do this set-up
itself, or move these commands to the
dependencies section. The latter is generally preferable:
build: dependencies: before: - command: npm install /plugin tests: override: - command: check.sh