Haskell Foundation DevOps Weekly Log, 2022-05-20

Hi! As the Haskell Foundation DevOps Engineer, I have two jobs:

  1. DevOps Engineer
  2. Haskell Foundation Member

To be a responsible member of the foundation, I’m going to post weekly updates on how I’m spending my time. This will also be a mechanism for community members to provide feedback on our priorities.

These updates may become a more formalized document at some point, but this one will be a free-form Discourse post. It will also be longer than those that follow, I suspect!


During my first week, I got onboarded, took care of some administrative stuff, met the team, and started looking into my first task: adding more performance metrics to GHC’s CI. For at least the next three months, I will continue working on CI, both to improve observability and to stabilize the CI infrastructure.

Since this week was mostly about learning for me, I’ll just summarize what I’ve discovered so far. It will give some context for my current and future tasks.

State of Affairs

Here’s a map of my new place in the world:


Currently, the active participants within the Haskell Foundation (besides the board of directors) are @david-christiansen and me. We have gotten to know each other a bit, and will be meeting weekly to stay synced.

In the day-to-day, I have been working with the GHC team at Well-Typed led by @mpickering. I will be taking over a fair bit of the work that he and @bgamari have effectively been responsible for.


GHC’s CI runs at Glasgow Haskell Compiler / GHC · GitLab. “CI” stands for “continuous integration”, and in practice it primarily (but not only) means the system that automates quality checks for a code repository. GHC’s CI has three main pipelines: one for validating merge requests, a nightly one for more extensive tests, and a final one that creates GHC packages for users (aka “releases”).

Rather than describe everything, I’ll just throw some links to things I’ve been reading lately:

Performance Testing

One aspect of quality is performance. In GHC’s CI, there is a fairly sophisticated setup for testing not just GHC’s own performance, but the performance of the Haskell that it compiles. (That’s where head.hackage comes in: it’s a set of Haskell packages that can be compiled and tested with the bleeding-edge version of GHC.) While sophisticated, there is plenty of value that could be added, and this is where I’m starting my work.

More reading:

CI Stability

Putting the ops in DevOps. :slight_smile: One can always find pain where software meets hardware, and improving reliability here is an important part of my job. We want GHC to support as many platforms as possible, and it’s been a big time sink to ensure Macs and Windows are supported well. I’m working my way into this gingerly, starting with an “easier” task so I can get familiarized with the software in play.

Besides supporting multiple platforms, CI is simply a software project of its own that requires bug fixes, deployments, monitoring, and so on. Like any service, one needs to ensure it is meetings its users’ needs.

My first step in ensuring this is to start collecting information about spurious CI failures. This topic has already come up a number of times, and it will be good to have some concrete data as a starting point to identifying high-impact problems.

I have a ticket about that one, too:


I hope you enjoyed this little tour! As I continue to work on CI stability and observability, the primary beneficiaries will be those who work directly on GHC. That will benefit everybody in the community, of course, but only indirectly. We at the Haskell Foundation are also interested in finding ways for me to directly benefit others in the community, however, so your feedback and suggestions are always welcome!

Until next time,



Thanks, this is very useful!


Wonderful developments in Haskell these days. Congrats and good luck @chreekat !


Exciting update! One idea here: would be good to bring matrix.haskell.org back to live.


Let’s goooooooooo~ :metal: