#166: Implement Haskell CI

[meipp]

Implements #166.

[L0neGamer]

Should the ghc ci that lives with the MHS stuff be removed as part of this?

[meipp]

Should the ghc ci that lives with the MHS stuff be removed as part of this?

No. That was a request implemented in #161. I think we should still let the ci compile against MHS (even if we have to do that manually, seeing that haskell-ci doesn't support MHS).

see: #166 (comment) for the discussion

[L0neGamer]

I meant more that the manually made CI still tests a bunch of ghc versions, although I now note that the generated CI looks like it only tests on Ubuntu

[meipp]

You're correct that we can drop a few ghc versions from ci.yml. haskell-ci only tests for linux and I wouldn't want to drop testing for other OSes, but for all I care we must only test one ghc version there. Say 9.6.7 (recommended) or 9.14.1 (latest).

[sjshuck]

Thanks for the work on this @meipp.

Asking sincerely to all convo participants: What benefits does this have over what we had before, besides the closing of a GitHub issue?

[hasufell]

Everyone has different preferences.

I personally dislike haskell-ci and any generated CI code for that matter. If you want to dynamically test the latest x GHC versions, I wrote a blog about how to do that with just the ghcup-setup action: https://hasufell.github.io/posts/2026-01-22-dynamic-ghcup-action.html

[meipp]

I'm honestly on board with dropping/denying haskell-ci. I found the generated file hardly readable, and seeing that it is not mature enough to cover all of our use cases maybe we shouldn't adopt it.

If we still want to support all major versions, that is easily done manually too. Maybe do that, and then test windows and macos against one ghc version for the peace of mind.

Interested in your opinion @andreasabel.

[L0neGamer]

I think there are a number of reasons to dislike haskell-ci.

I have the following issues with your approach which is otherwise very slick:
I find shell scripting can lead to pretty unreadable code which makes it harder to maintain
In a core library with a large compatibility window the last N versions isn't really what we're looking for; we are genuinely looking to match our tested-with window (although more is nice), which haskell-ci conveniently provides

The former could be managed by commenting up the shell script a lot more in our variant, and the latter can be achieved by asking for an "early version" to search from.

I invite further comments on this though.

Edit: re: advantages: somewhat outsourcing what's managing our ci reduces what needs to be understood about our setup. With haskell-ci, one defers understanding of what the ci does to those maintainers.

[hasufell]

For tested-with there is https://github.com/Kleidukos/get-tested

[andreasabel]

This version does not have 9.12.4, latest is 9.12.2. So 9.12 is not covered now.

Unfortunately, if you want 9.12.4, you have to build Haskell CI from PR haskell-CI/haskell-ci#814

[andreasabel]

What Haskell-CI has but most hand-knitted CIs do not:

1. build the project from the sdist tarball rather than from the repo root. This ensures that all files needed for the build are actually tracked in the .cabal file.
2. dumping the install plan (using cabal-plan) so it is apparent which versions of the dependencies have been used for the build
3. fixing by default the GHC-shipped libraries to their GHC-shipped versions. This checks for GHC-version compatibility more seriously; one is alerted when a newer version of such core library is needed.

It is ok to hate Haskell-CI as long as one provides a CI script that has the features I just listed. I never bothered to hand-engineer this so I use Haskell-CI by default, often as complement to some Stack-centered CI, or some hand-knitted Cabal-centered CI on MacOS/Windows.

[hasufell]

What Haskell-CI has but most hand-knitted CIs do not:

1. build the project from the sdist tarball rather than from the repo root. This ensures that all files needed for the build are actually tracked in the .cabal file.
2. dumping the install plan (using cabal-plan) so it is apparent which versions of the dependencies have been used for the build
3. fixing by default the GHC-shipped libraries to their GHC-shipped versions. This checks for GHC-version compatibility more seriously; one is alerted when a newer version of such core library is needed.

1. and 2. are like 4 lines of shell code

3 is more interesting. Can you elaborate how this is done?

[andreasabel]

3 is more interesting. Can you elaborate how this is done?

This is done, afaik, by writing out a cabal.project that hasconstraint: PKG installed for all ghc-shipped packages. One could also pass a -c 'PKG installed' option for each PKG on each invocation of cabal, I suppose.

This line: https://github.com/haskell/mtl/pull/181/changes#diff-73f8a010e9b95aa9fe944c316576b12c2ec961272d428e38721112ecb1c1a98bR215

[sjshuck]

I don't know if it addresses 3—I think it does—but regardless, it would be nice to test with Stack as well as Cabal, since that's a very important target.

[hasufell]

I created an alternative that pretty much does everything that was said here: #182

[sjshuck]

#182 is merged and obsoletes this one. Thanks again @meipp for the effort and for sparking the discussion.