Make head.hackage less stateful

Teo Camarasu
2026-01-21T15:12:24Z

As it stands, when we run a pipeline, we are dependent on the state of the current GHC release branches.

I think this gets in the way of contributing to head.hackage and makes the git history less useful.

It's often the case that new breakages from release branches and master break MRs in flight.

1. A user makes an MR, its pipeline passes
2. They re run the pipeline, it fails because an upstream merge has introduced a new breakage.
3. Now they are potentially blocked indefinitely from merging their branch.

At the same time, it's difficult to run a historical pipeline. It's hard for me to know exactly what bindist CI would have picked.

To help with these I'm thinking we could pin the compiler version in a config file, which is checked into the repo.

Then whenever a nightly pipeline runs on `master` or a MR is merged into a release branch:
- we run a head.hackage upstream pipeline
- we would update the pin in our config file to point to the new pipeline
- we note down all unexpected failures into a config file -- these would then be ignored in MRs, and so MRs won't be blocked by new breakages
- we already have a facility for marking packages as known failures, when there is an upstream GHC ticket.

So the idea would be that at any point in time, our repository would have specific pins of the versions of GHC we test along with both expected and unexpected failures with those versions.