Downgrade the CI to GHC 9.12.2.

[aschwerdfeger-galois]

ghcup has pulled GHC 9.12.3 due to a critical bug, breaking the CI in this repository. This pull request restores the use of GHC 9.12.2.

[RyanGlScott]

Oh sigh, now I remember why we upgraded to 9.12.3 in the first place... https://gitlab.haskell.org/ghc/ghc/-/issues/25771

[RyanGlScott]

In light of this, I can see some different possible paths forward:

• Remove the GHC 9.12 CI job until there is a working GHC 9.12.* release that also includes the fix for https://gitlab.haskell.org/ghc/ghc/-/issues/25771.
• Keep the GHC 9.12 CI job and use GHC 9.12.2, but allow it to fail for now.
• Keep the GHC 9.12 CI job and use GHC 9.12.3, figuring out how to cajole ghcup to install 9.12.3 despite it being marked as broken.

Thoughts? (cc @langston-barrett @kquick)

[langston-barrett]

Keep the GHC 9.12 CI job and use GHC 9.12.3, figuring out how to cajole ghcup to install 9.12.3 despite it being marked as broken.

I'm fine with any of the above, though this one sounds ideal to me. With the other options, there is some (slim) chance that we break GHC 9.12 support without realizing it.

[RyanGlScott]

Actually, I misspoke: it's not ghcup that is rejecting GHC 9.12.3, but rather the haskell-actions/setup action that CI is using. See haskell-actions/setup#133. Unfortunately, I don't see a way to opt into using 9.12.3 with this action even if we wanted to. We could rewrite the CI to use a workflow not based on haskell-actions/setup, but that seems like a pretty drastic measure.

As a result, I think we either have to remove the 9.12 job or mark it as expected to fail. I have a very slight preference towards the latter (at least we can look at the build logs if we notice something afoot), but I could be convinced otherwise.

[aschwerdfeger-galois]

By "mark it as expected to fail," do you mean actually setting continue-on-error for the 9.12 job, or just making an informal designation (and using the release PR as-is)?

[langston-barrett]

continue-on-error, I think

[RyanGlScott]

Yes, I agree, let's use continue-on-error.

[sauclovian-g]

Also, don't forget to add an issue to remind us to undo that when there's a working 9.12 available.

[aschwerdfeger-galois]

Apparently, trying to use continue-on-error in the regular way messes up something in the Haskell CI workflow spec. Is it actually possible to set continue-on-error and still use the workflow?

[RyanGlScott]

Reading the haskell-ci source, it appears that it doesn't allow taking continue-on-error as an option. (I think it ought to.)

In the meantime, another viable option would be to disable running cabal test on the GHC 9.12 CI job. Reading the source reveals that haskell-ci does allow disabling this (see here), so we ought to be able to do something like:

    strategy:
      matrix:
        os: ["ubuntu-24.04"]
        ghc: ["9.8.4", "9.10.1"]
        cabal: ["3.14.2.0"]
        test: [true]
        include:
          - ghc: "9.12.2"
            test: false
        fail-fast: false
    name: ${{ matrix.os }} - GHC ${{ matrix.ghc }} - Cabal ${{ matrix.cabal }}
    uses: GaloisInc/.github/.github/workflows/haskell-ci.yml@v1
    with:
      cabal: ${{ matrix.cabal }}
      cache-key-prefix: v2
      ghc: ${{ matrix.ghc }}
      os: ${{ matrix.os }}
      test: ${{ matrix.test }}

I actually like this idea, as it would ensure that llvm-pretty's source code at least continues to compile on GHC 9.12, even if we stop short of actually running the tests themselves.

[langston-barrett]

Oh, the GHC panic even happens during the build phase...

[langston-barrett]

I think our only remaining option is

Remove the GHC 9.12 CI job until there is a working GHC 9.12.* release that also includes the fix for https://gitlab.haskell.org/ghc/ghc/-/issues/25771.

[aschwerdfeger-galois]

The failure occurs when building the test suite (the build of the package itself works as expected, at least in my local environment), so we could still avoid cutting out the 9.12 build if there is some easy way to disable building the test suite in the Haskell CI workflow.

[RyanGlScott]

We could customize the configure-flags to replace --enable-tests with --disable-tests in the default set of flags.

[langston-barrett]

Ah, good catch! You could set build-targets: "lib:llvm-pretty"

[RyanGlScott]

Phew, that was surprisingly nasty. Thanks for persevering on this one!