Smoked Modules, Montréal-style

October 3rd, 2012

Smoked Modules, Montréal-style

If you recall, in our last episode I hacked together a quick solution to smoke all of Dancer’s plugins and know how they fare, with regard to Dancer 1 versus Dancer 2.

After that blog entry, I thought it would be fun to revisit the problem and try to implement a more general solution. The experiment, I decided, would have the following goals: at its base it would have to be generic enough to be able to smoke any module, and provide the flexibility required to be easily extensible. To exercise that said extensibility, I would have to implement two plugins: one that retrieves the module-to-test from a Pinto repository, and the other that saves the testing results in a database. So, basically, have all the goodies of the hack, but rephrased in a way that will allow me to use it for other, future nefarious ends.

I’ll not keep you in suspence: the experiment fared quite well (or so I like to think) and is now available on GitHub. It’s full of stubbed functionality and still need much work, but it’s doing something. Here, let me show you.

Here, Smoke That

At the core, we want the raw smoking functionality: we want to shove a tarball in, and we want the tap report out. So that’s what we’re going to have our main module, Smoke::Module, do (and you have no idea how hard it was for me not to call that module Smoked::Meat).

As usual, the trick is to find the modules that do the hard parts, and glue them together. The tarball is extracted via the good services of Archive::Tar, in a directory kindly provided by MooseX::Role::Tempdir. We run the distribution Build.PL/Makefile.PL with the assistance of IPC::Run3, the running of the test and creation of the TAP archive is delegated to prove, and the slurping back of said archive is done by TAP::Harness::Archive, which gives us a TAP::Parser::Aggregator with all the goods. And thanks to the lazy builders sprinkled everywhere, using the module turns out to be very short and sweet:

    $ perl -Ilib -MSmoke::Module 
        -E'say Smoke::Module->new( tarball => shift )->test_status' 
    t/00-compile.t ...... ok   
    t/basic.t ........... ok     
    t/honor-no-cache.t .. ok   
    t/hooks.t ........... ok   
    t/key-gen.t ......... ok   
    t/namespaces.t ...... ok   
    All tests successful.
    Files=6, Tests=42,  4 wallclock secs ( 0.04 usr  0.01 sys +  1.84 cusr  0.17 csys =  2.06 CPU)
    Result: PASS

    TAP Archive created at /tmp/sae8spnE_K/tap.tar.gz

Uh. Okay, I still have to figure out why prove won’t shut up, but beside that, ain’t that sweet?

For Good Smoking, You Have To Have Good Tar(balls)

Now that we have the core, let’s turn our attention to our plugins. For the first one, we want to turn things around a little bit. Instead of providing a tarball directly, we’ll provide a module name (and possibly a version), and let the system figure out how to borrow it from Pinto.

The sneaky bit in that role is how we change the nature of the tarball attribute. Usually, roles aren’t supposed to mess with the base class’s attributes that way, but thanks to MooseX::Role::AttributeOverride we do have a way to against the fundamental laws of Nature. Worked for Viktor Von Frankenstein, don’t see why it wouldn’t for us…

And Pipe The Results To The Database

… ye gods, I can’t believe I just made that pun. I’m so ashamed, I wish I could crawl under the carpet or disappear in a puff of sm— aaaanyway…

So, yeah, last bit: intercept the results, and store them in a database. And for that kind of job, I’m very quickly growing quite fond of my little DBIx::NoSQL::Store::Manager module:

Most of the code in that module is there to oil the gears of MooseX::Storage; to tell it which attributes which aren’t worth serializing, and how to serialize the different attribute objects.

Get The Pieces Together

We could probably still find a way to run the base class with all the roles as a one-liner, but that would be just be show-off, so instead, let’s do things properly, the long-hand way:

    $ cat
    #!/usr/bin/env perl

    use 5.10.0;

    package Smoked;

    use Moose;

    extends 'Smoke::Module';
    with 'Smoke::Module::Pinto';
    with 'Smoke::Module::Store';

    say __PACKAGE__->new( 
        package_name  => $_,
        debug         => 1,
        log_to_stdout => 1,
    )->run_tests for @ARGV;

    $ ./smoker Dancer::Plugin::Cache::CHI
    [6295] extracting tarball to /tmp/hREOWmENuC
    [6295] Build.PL detected
    [6295] Created MYMETA.yml and MYMETA.json

    [6295] Creating new 'Build' script for 'Dancer-Plugin-Cache-CHI' version '1.3.1'

    [6295] Building Dancer-Plugin-Cache-CHI


    $ sqlite3 test.sqlite .dump
    INSERT INTO "__Store__" VALUES('Smoked','Dancer::Plugin::Cache::CHI : v1.3.1 : Thu Oct  4 21:32:32 2012','{
    "tap_report" : {
        "todo_passed" : 0,
        "exit" : 0,
        "descriptions_for_todo_passed" : [],
        "failed" : 0,
        "descriptions_for_parse_errors" : [],
        "descriptions_for_total" : [
        "descriptions_for_todo" : [],
        "descriptions_for_planned" : [
        "todo" : 0,
        "parse_order" : [
        "planned" : 42,
        "descriptions_for_skipped" : [],
        "parse_errors" : 0,
        "descriptions_for_exit" : [],
        "descriptions_for_passed" : [
        "parser_for" : {
            "t/00-compile.t" : null,
            "t/basic.t" : null,
            "t/honor-no-cache.t" : null,
            "t/hooks.t" : null,
            "t/key-gen.t" : null,
            "t/namespaces.t" : null
        "passed" : 42,
        "total" : 42,
        "skipped" : 0,
        "wait" : 0,
        "descriptions_for_failed" : [],
        "descriptions_for_wait" : []
    "package_name" : "Dancer::Plugin::Cache::CHI",
    "package_version" : null
    "tarball" : "/home/yanick/pinto/authors/id/Y/YA/YANICK/Dancer-Plugin-Cache-CHI-1.3.1.tar.gz",
    "perl_exec" : "/usr/local/soft/perlbrew/perls/perl-5.14.2/bin/perl",

Now, picture few more plugins, a Dancer front-end, and wouldn’t you agree this could become interesting real fast?