Daily quality control checks with Coder

Error message

The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.

I'm known, famously or infamously, for my code quality reviews and, whilst I don't get enough time to perform the same anal-retentive behavior at Trellon, I've streamlined checks of the most egregious errors with daily e-mailed reports using Coder and Drush. Drush allows you to operate your Drupal site from the command line, while Coder is a friendly "do it right, bub" for code quality.

Getting things installed and configured

Currently, most of the sites Trellon develops are still using Drupal 5 (due, as usual, to the slow porting of contributed modules to Drupal 6) so our code review automation is also based on that version. We use a single, fresh Drupal 5 install dedicated to reviews because I didn't want to muck up each of our client sites with too many developer-only gizmos (Devel was enough).

  • Install Drush 5.x-2.3 per the installation documentation.
  • Coder proclaims support for Drush on its project page, but the capability isn't actually available in any of the official releases. As such, you'll need to install Coder 5.x-2.x-dev.
  • Configure the Coder defaults at admin/settings/coder. For our purposes, we default to "Converting 4.7.x modules to 5.x" along with the Coding, Commenting, SQL Standard, and Security Checks, with a level of reporting set to "minor (most)". The "What to review" section has "include files (.inc and .php files)" enabled.

Coder can only review modules that Drupal knows about (more succinctly, that exist in the system table), so we next need to tell this install about the custom code we're writing for clients. Since our coder review install lives on the same development server as all our sandboxes for the client, I simply symlink those modules into the code review site's sites/default/modules directory. Since this is just a pointer to the actual client code, none of our existing development workflow has to change:

$ pwd
/home/morbus/scratch/coder_reviews/sites/default/modules
$ ln -s /var/www/html/CLIENT/sites/all/modules/CLIENT_custom_app CLIENT_custom_app

To perform code reviews, the modules need to at least be in this install's system table, although they do not need to be enabled. Achieving this is a simple matter of hitting admin/build/modules to refresh the module list. At this point, you should be able to browse to coder and pick and choose which client modules you want to review.

You'll also be able to get these reviews from the command line:

$ pwd
/home/morbus/scratch/coder_reviews/sites/default/modules
$ ./drush/drush.php coder CLIENT_custom_app
sites/default/modules/CLIENT_custom/CLIENT_custom_app.module:
+39: missing space after comma
+371: There should be no trailing spaces
+400: There should be no trailing spaces
+509: The control statement should be on a separate line from the control conditional
...

Automating the process and mailing the results

The above was still a bit too manual (and non-compulsory) for my tastes so, using Drush and a shell script, I automate the reviewing of custom modules with client-specific e-mails generated every morning. Here's the script I'm running daily:

#!/bin/sh -e
TO="address@example.com"
DRUSH="/home/morbus/scratch/coder_reviews/sites/default/modules/drush/drush.php"
cd /home/morbus/scratch/coder_reviews/

function start_mail {
MAIL=`mktemp`
cat > $MAIL << EOF
Generated by http://www.example.com/path/to/our/coder/review/site
For more verbose explanations, choose your module from that list.

EOF
echo $MAIL
}

MAIL=`start_mail`
$DRUSH coder CLIENT_custom_app CLIENT_custom_import >> $MAIL
if grep "+" $MAIL > /dev/null; then mail $TO -s "[CLIENT] coder.module has found code to be fixed" < $MAIL; fi
rm -f $MAIL

You'll note that Coder's Drush integration allows you to review more than one module at once. In our case, we review all of a specific client's custom modules in one call, then bundle it up into a CLIENT-specific e-mail. Our full script includes the last four lines replicated and modified for each particular client and code we're quality assuring.

Still, there are plenty of things that Coder doesn't catch that would probably be too obsessive and anal to ship by default. Regardless, my next step will be to create my own hook_reviews() implementation, suitably named "Drupal Tough Love", further improving the overall quality of the modules that Trellon ships, internally or otherwise.