Building a Perlanet Container

Screenshot showing diff
Screenshot showing diff

I’m a dinosaur who still believes that web feeds are a pretty neat idea. I wrote and maintain perlanet (a Perl program for aggregating web feeds into a new feed – and building a web site based on that new feed) and I use it to build a few sites on topics I’m interested in.

Last year, I worked out a way to use GitHub Actions to rebuild these sites automatically every few hours – thereby enabling me to host the sites on GitHub Pages (I still think it’s a useful technique, but I sometimes worry slightly about the large number of commits those repos have – someone at GitHub must surely notice one day!)

Yesterday, I was doing some light maintenance on one of those sites when I realised that each rebuild of these sites was taking a significant time (by which I mean four or five minutes) and started wondering if there was a way to speed them up and use less of GitHub’s resources. The problem is that Perlanet is a pretty hefty module and each rebuild was installing that module (and, therefore, dozens of other modules) on a pristine Ubuntu container.

When you say it like that, the solution is obvious.

You don’t need to run your GitHub Actions on the standard containers that GitHub supplies. You can run them on any container that’s available from any public container hosting service. So the solution was to build a Perlanet container and run the jobs using that instead. So that’s how I spent an hour or so yesterday.

Here’s the Dockerfile I ended up with:

It’s (obviously) available on GitHub in case anyone wants to improve on my rather ropey knowledge of Docker.

I explicitly install Test::Exception because HTML::Tidy (one of Perlanet’s pre-requisites) needs it and I can’t work out why the standard installation procedure isn’t installing it. And while, LWP::Protocol::https is, strictly speaking, not required by Perlanet, you wouldn’t get very far on the modern web if you only accessed web feeds that are available over HTTP.

A little bit of Docker Hub set-up and the container is available for everyone to use (and rebuilt automatically whenever I commit to the repo).

It was then just a case of changing my GitHub Actions to use my container. Here’s an example of one of the commits that did that.

I realise I’m pretty late to the party here, but I think this is a useful pattern. If you have a Perl library (or, indeed, any other software) that exists to provide a service to users then it’s a great idea to provide a containerised version of that software.

And I’m happy to report that my site rebuilds have gone from 4-5 minutes to about 45 seconds.

Also published on Medium.

By Dave Cross

Dave Cross runs Magnum Solutions Ltd., a London Perl consultancy. In 1998 he started London Perl Mongers, the first Perl Mongers group outside of Northern America. He is the author of Data Munging with Perl and a co-author of Perl Template Toolkit.


  1. Cool site. The site contains several planet home pages, and each has its own RSS feed. However, the alternate link at the html head are all pointing to one feed “”. This makes the automatic feed discovery not working. Can you please fix the alternate link in the head section?

    1. Wow, yes. I guess that’s because those planets were all built at different times and the initial configs were all copied from older ones. But I think I’ve fixed them all now (once they’ve all rebuilt themselves).

      Thanks for pointing it out.

  2. Thanks.There is still one problem: the link rel=alternate is “http://…” but the RSS link in the homepage is “https://…” I am guessing you want to use the https version, but a tool can’t deduce that.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.