Docker, Perl and GitHub

Why using Docker images?

There are many reasons to use Docker Images, from setting up a development environment to pushing your code to production. The primary/first reason which pushes me to start using some Docker Images is "Continuous Integration".

When maintaining a Perl package used by multiple users/companies (or not), you absolutely want to know how your code behaves on different versions of Perl. Even if you could have multiple versions of Perl installed on your development environment, most of the time, the development is only performed using a single version of Perl.

Continuous Integration system like Travis CI or GitHub Workflows allows you to run your test suite on every push, pull request... without the need of testing manually on all Perl Versions.

When testing your code on a container (or Virtual Machine) you do not want to install or compile a fresh version of Perl each time... This is a slow operation, that ideally, should be done once.

This is where Docker Images come to the rescue. They are "snapshots" of a pre-set linux environment.

Docker Official Perl Images

The Perl community started providing official Perl Docker images since 2014!

The Official Perl Docker images are available from

You can use Perl compiled with or without thread support and some specific Debian flavor. In case of doubt, it's recommended to use the images named

  • latest or 5.30

  • 5.28

  • 5.26

  • ...

These images come with App::cpanminus pre installed.

Continuous Integration

I used Travis CI for several years and really love it.
But over the last months I started playing with GitHub workflows.
Skaji provided some templates to start using Perl and GitHub actions.

When I start using the official Docker Images, this was obviously great for my projects... but when it comes to testing, this quickly raised multiple issues:

  • I need to reinstall the whole set of dependencies required for testing my distribution

  • this is a slow operation

  • I've to manually install App::cpm (faster than cpanminus)

  • this can fail at any time depending on the upstream state...

  • most of the time I have to install modules like Test-Simple for using Test2... and the slowness of installing all the dependencies for Test2 was pulling me away from using it...

  • what about if my project is using Dist::Zilla ? You probably should not consider using Dist::Zilla for smoking your project directly, all the most it's only available on Perl >= 5.14. But this could be very convenient.. to just run `dzil test`

Trying to solve a few of these problems, Oalders came with the great idea of building pre-defined Perl Docker Images with the most commonly used Test modules.

These images are built from the official Docker Images on which a few extra CPAN modules are installed.

Only the tags 5.30, 5.28, 5.26, 5.24, ..., 5.8 are available.

The most common Test::*, Test2::*, Devel::*... packages are already installed and up to date with CPAN. The images are refreshed daily, and if one CPAN module failed to install, the image would not be published which should not impact your projects.

Images for Perl 5.14 and later are also coming with Dist::Zilla and a bunch of common Plugins.

You can use the Perl Tester Docker Images by using the images from

These images are daily updated.

Note: you can also use custom docker images with Travis CI

Leave a comment

About atoomic

user-pic I blog about Perl.