Dockerize

[isaac-gittins]

Overview

Creates a Docker Image which contains all the required perl libs, and executes ./bin/perlcritic by default.

Build Docker Image:

docker build -t image:label .

Use the image

The docker image will execute the ./bin/perlcritic script, and arguments to the docker run command will be passed to the perlcritic

Invoke

docker run image:label [perlcritic options]

How I use it

I follow the The Three Musketeers method and as part of my CI/CD Pipelines, I:

• use a make target to
• invoke docker-compose to run
• this Docker Image
• to check over my perl scripts,
• and fail the builds when perlcritic discovers issues.

[petdance]

Thanks for the work on this.

Can you tell me more about why we would want this in Perl::Critic? What are the benefits of running Perl::Critic out of a container?

[petdance]

I've fixed the typo in lib/Perl/Critic/Policy/ErrorHandling/RequireCheckingReturnValueOfEval.pm manually. Thanks.

[isaac-gittins]

I use this in my build pipelines. As part of our ci/cd piplines all supporting tools are wrapped in docker so that any ci/cd activity can be run locally or in the cloud without having to worry about doing installs on the build servers or dev pc's and be confident of the same outcomes.

We have an approach we call The 3 Musketeers - https://amaysim.engineering/the-3-musketeers-how-make-docker-and-compose-enable-us-to-release-many-times-a-day-e92ca816ef17 , which uses Make, Docker and Docker-Compose to perform all our build and deploy activities. As I wanted to use Perl-Critic to ensure some standards on our perl scripts, I needed to put it in docker, so I thought I would share my Dockerfile with you.

For me, i can call docker-compose run perl-cirtic --brutal ./scr/to/script.pl in my other project's repos and know that the testing will be the same on my local dev machine, as in my pipeline, and also any other devs can do the same without having to worry about if they even have perl, or the require perl libs, installed on their dev box. Whilst this may not be a big deal for a single tool, we do it to all cli tools we use and it makes our dev teams more efficient as they can spend more time working on their projects and spend less time setting up their local dev environments.

On a side note, all our build instances are in the cloud and are scaled on demand, so it is convenient for us to have all pipeline/build tooling in docker so that we don't have to keep maintaining an Uber build image that contains every possible tool across many languages and versions.

I have setup a public auto build on my docker file, from our forked repo, so that my version is available as a public docker image: https://hub.docker.com/r/amaysim/perl-critic/ . This docker image is only 14MBs and is 100 % self contained including the perl runtime and all pre-req Perl Modules. So anyone can use the image "amaysim/perl-critic". I thought it would take very little effort for you to re-use the docker file and then you could release your own Official version of the docker image. Once setup dockerhub will auto regenerate the docker image every time you commit/merge to master or a specific branch.

If you like, I can show examples of how I am using this docker image in my ci/cd pipeline.

Regards
Isaac

[petdance]

What you just wrote up sounds like a blog post waiting to happen.

I'm OK with putting the Dockerfile in the extras folder, so it's clear to anyone using Perl::Critic that it's not something that we'd officially support. Sound good?

[isaac-gittins]

Sounds great. hoping it will be helpful to others.
Cheers.

[oalders]

We've been moving to Docker for MetaCPAN. Maybe @ssoriche would want to check this PR?

[ssoriche]

Sorry, just realized I never commented on this request. It looks good to me, and could be really helpful.

[petdance]

I think it would be great to have this, especially if @isaac-gittins can provide examples about how he uses the Docker image in his pipeline.

[petdance]

Done. Thank you. See c9f4d5f