Continous Integration with Travis CI and Github for Distzillians

This post started out at a comment on a blog post, but it was simply not possible for me to comment on the relevant post, so I have edited my comment into a blog post even though most of the contents are not mine :-/

So all the Kudos, credits, beers and stuff for the contents of this post should really go to: Alex Balhatchet, read his post:

Okay – I have migrated all of my CPAN distributions to Github and all new projects start up here. Over the years I have used Jenkins for continuous integration, so I was very happy when I found out that Github offered continues integration using Travis.

I had everything going with Module::Build, which have been my preferred build system and one I have been using for a long time, with Travis CI on Github, but recently I have started porting all my distributions from Module::Build to Dist::Zilla, which meant that I had to revisit my whole toolchain.

Finding Alex’s article was just what I was looking for.

The after reading Dave Cross blog post and presentation I got coverage with coveralls integrated (see my blog post on those spiffy badges)

In order to get coverage integrated with Alex’s example, I have made the following changes to his suggested setup.

install is extended with:

– cpanm –quiet –notest Devel::Cover::Report::Coveralls
– cpanm –quiet –notest Dist::Zilla::App::Command::cover

and this additional after_success section has to be added:

– dzil cover -outputdir cover_db -report coveralls

I did run into some issues with Alex version, so I have to explicitly install Test::Kwalitee since the version on the Travis CI platform is apparently too old, so also under install I do:

– cpanm –quiet –notest Test::Kwalitee

The Test::Kwalitee issue should go away Karen Etheridge patched her Dist::Zilla plugin

An in addition I also had to install the dependencies of the plugins explicitly under install:

– dzil listdeps –author | cpanm –quiet –notest –skip-satisfied

This was due to an issue with Pod::Coverage tests, where is missing.

You can have a look at one of my setups from my code Github:

language: perl
– “5.18”
– “5.16”
– “5.14”
– “5.12”
– “5.10”


# Prevent “Please tell me who you are” errors for certain DZIL configs

– git config –global “TravisCI”


# Deal with all of the DZIL dependencies, quickly and quietly

– cpanm –quiet –notest –skip-satisfied Dist::Zilla

# Hack to getting the latest Test::Kwalitee

– cpanm –quiet –notest Test::Kwalitee

# Getting coveralls report

– cpanm –quiet –notest Devel::Cover::Report::Coveralls

# Getting cover command for Dist::Zilla

– cpanm –quiet –notest Dist::Zilla::App::Command::cover

# Getting all the plugins used by Dist::Zilla in this particular setup

– dzil authordeps | grep -vP ‘[^\w:]’ | xargs -n 5 -P 10 cpanm –quiet –notest –skip-satisfied

# Getting all the dependencies requested by author

– dzil listdeps –author | cpanm –quiet –notest –skip-satisfied


# Getting all the dependencies requested by distribution

– dzil listdeps | grep -vP ‘[^\w:]’ | cpanm –quiet –notest –skip-satisfied


– dzil smoke –release –author


– dzil cover -outputdir cover_db -report coveralls

Thanks to Alex Balhatchet for the post – and thanks to Dave for his awesome post and Karen for most impressive responsiveness, when reporting an issue.

Continued good day,

jonasbn, Copenhagen

Continous Integration with Travis CI and Github for Distzillians

CPAN Release Task::Jenkins 0.05

I have just released Task::Jenkins 0.05 to CPAN (meta).

This is a feature release and it now included Devel::Cover::Report::Clover which is a report formatter for Devel::Cover, which can generate Clover reports consumable Devel::Cover reports in Jenkins using the Clover Plugin.

This does as such not replace the HTML Publisher Plugin integration I normally recommend but it does provide the Jenkins use with a graphical overview of the coverage metrics.

An example:

The configuration of the plugin is pretty basic:


We specify where we want the report to be and in our actually integration test step we add the following:

#create Devel::Cover report
./Build testcover

#create clover report from Devel::Cover using #Devel::Cover::Report::Clover
./cover -report clover -outputdir clover

In addition I generate the HTML reports and these are then accessible via clicking the graphical coverage report (please see my Wiki page on Continuous Integration for Perl using Jenkins).

#create html report from Devel::Cover::Report::Html
./cover -report html -outputdir clover && \
mv clover/coverage.html clover/index.html

This reports already exist since they are generated by Devel::Cover by default so perhaps a copy of these from cover_db can be done, but this was the first shot – or is strikes me I could just tell the clover report generation to output to
cover_db/ – this has to be tried out.

The rename of coverage.html to index.html is however unavoidable AFAIK to support the integration with the plugin.

This is really swell, BUT WAIT there is more…

This next part is not currently a part of Task::Jenkins, but I do mention it in the POD distributed with Task::Jenkins from this release and it might go in in the future. It was pointed out to be that a Jenkins plugin exists to visualize Perl::Critic reports, it is called Violations (thanks mil for the tips on plugins).

It is somewhat more tricky to set up. Lets start with the configuration:


You start by pointing to perlcritic.txt, this file should contain output from a Perl::Critic run.

The plugin simply parses output from Perl::Critic. So you have to add a step to generate this file, which should contain something a long the lines of this:

./perlcritic –brutal –verbose 5 –profile \
t/perlcriticrc lib t > perlcritic.txt

I run with the highest severity since I just want a report of everything. I point to the perlcritic resource file following the distribution (also under version control), but I overwrite severity using –brutal and output format using the verbosity flag.

It is quite important to output in format 4 or 5 since only these are supported by the plugin. I normally prefer format 8 since it makes it easy to copy-paste the policy name into a perlcriticrc file.

With format five you get also the filenames and you redirect it into the text file.
Then you will get the following graph for you build.


And when you click the graph you get the following detailed view:


You can see violations, violations by severity, trends and by clicking the filenames you get even more in-depth information.


My Wiki page on Continuous Integration for Perl using Jenkins will be updated soon with all of these findings and other tips and goodies.

Please let me know if you experience issues or have other tips I could benefit from.

Continued happy integration!

jonasbn, logicLAB

CPAN Release Task::Jenkins 0.05