Containers for Coverage
Tags: packaging, container, coverallsio, docker
Published: 2022-10-18 17:05:57

---
title: Containers for Coverage
published: true
date: 2022-10-18 17:01:50 UTC
tags: Packaging,container,coverallsio,docker
canonical_url: https://perlhacks.com/2022/10/containers-for-coverage/
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/67xoah6lb61v6wsxqqdk.png
---

I’ve been building Docker containers again. And I think you’ll find this one a little more useful than [the Perlanet one](https://dev.to/davorg/building-a-perlanet-container-43cm) I wrote about a couple of weeks ago.

Several years ago I got into [Travis CI](https://www.travis-ci.com/) and set up lots of [my GitHub repos](https://github.com/davorg?tab=repositories) so they automatically ran the tests each time I committed to the repo. Later on, I also worked out how to tie those test runs into [Coveralls.io](https://coveralls.io/) so I got pretty graphs of how my test coverage was looking. I gave [a talk about what I had done](https://www.slideshare.net/davorg/github-travisci-and-perl).

But two things changed.

Firstly, Travis CI got too popular and, eventually, removed their free service. And, secondly, [GitHub Actions](https://github.com/features/actions) was introduced. Over the last few years, I’ve set up many of my repos to use GitHub Actions for CI. But, basically because I’m lazy, I didn’t remove the Travis CI configuration from those repos.

But last week I decided the time was right to start work on that. And when I went to remove the .travis.yml I realised that something was missing from my GitHub Actions CI workflows – they were running the unit tests, but they weren’t reporting on test coverage. So it was time to fix that.

I needed to reimplement the logic that connected Travis CI to Coveralls.io in a GitHub workflow. That actually turned out to be pretty simple. There’s a CPAN module called [Devel::Cover::Report::Coveralls](https://metacpan.org/pod/Devel::Cover::Report::Coveralls) which takes the output from Devel::Cover, converts it to the correct format and sends it to Coveralls.io. And, as a bonus, it has documentation showing how to implement that in a GitHub workflow.

So I hacked at my workflow definition file for one of my CPAN modules and within a few minutes I had it working.

Well, I say “a few minutes”, but it took over thirteen minutes to run. It turns out that Devel::Cover::Report::Coveralls is a pretty heavyweight module and needs to install a lot of other modules in order to do its work.

At this point, you can probably guess where this is going. And you’d be right.

I’ve created a Docker container that has Devel::Cover::Report::Coveralls already installed. And, obviously, it’s available for everyone to use from the Docker hub – [davorg/perl-coveralls](https://hub.docker.com/repository/docker/davorg/perl-coveralls).

A couple of small adjustments to my GitHub workflow and the coverage job is now running on my new container – and takes 29 seconds instead of 13 minutes. So that’s a win.

The relevant section of my [workflow file](https://github.com/davorg/calendar-simple/blob/master/.github/workflows/perltest.yml) is here:

```
coverage:
    runs-on: ubuntu-latest
    container: davorg/perl-coveralls:latest
    name: Test coverage
    steps:
      - uses: actions/checkout@v3
      - name: Install modules
        run: cpanm -n --installdeps .
      - name: Coverage
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: cover -test -report Coveralls
```

And it’s producing nice graphs on Coveralls.io like the one above.

Let me know if you find it useful.

The post [Containers for Coverage](https://perlhacks.com/2022/10/containers-for-coverage/) appeared first on [Perl Hacks](https://perlhacks.com).