Screenshot showing diff

Building a Perlanet Container

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.


Posted

in

by

Comments

4 responses to “Building a Perlanet Container”

  1. derek Avatar

    Cool site. The site https://theplanetarium.org/ 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 “http://planetbalham.org.uk/atom.xml”. This makes the automatic feed discovery not working. Can you please fix the alternate link in the head section?

    1. Dave Cross Avatar

      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. derek3qinus Avatar

    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.

    1. Dave Cross Avatar

      No, that was also me being a bit of an idiot. Fixed now.

Leave a Reply

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