GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-26T17:01:38Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24594Consider adding a CI configuration that builds stage2 with -O2 for AArch64.2024-03-26T17:01:38ZAndreas KlebingerConsider adding a CI configuration that builds stage2 with -O2 for AArch64.## Summary
I recently wrote a patch that got merged, despite it turning out to be broken with `-O2` on AArch64 (see #24586).
This was only caught when colleagues complained about being unable to build ghc head locally.
I think testing...## Summary
I recently wrote a patch that got merged, despite it turning out to be broken with `-O2` on AArch64 (see #24586).
This was only caught when colleagues complained about being unable to build ghc head locally.
I think testing this config would be beneficial. But I don't know if we have the resources to do so for every run.
Maybe there is already a label to use to enable such a config which I forgot about?Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24520Poor enforcement for importing implicit dependencies2024-03-19T19:10:53ZMatthew Cravenclyring@gmail.comPoor enforcement for importing implicit dependenciesThere are several known-key things that GHC may try to look up the interfaces for during compilation regardless of whether they have been imported. This problematic while bootstrapping, because if we compile a module that tries to refer ...There are several known-key things that GHC may try to look up the interfaces for during compilation regardless of whether they have been imported. This problematic while bootstrapping, because if we compile a module that tries to refer to `GHC.CString.unpackCString#` for string-literal desugaring before `GHC.CString` has been built, compilation will fail.
Two of these potential implicit imports are described in [`Note [Depend on GHC.Num.Integer]` and `Note [Depend on GHC.Tuple]` in `GHC.Internal.Base`](https://gitlab.haskell.org/ghc/ghc/-/blob/38a4b6ab7bbd5e650f43541d091a52ed2655aff6/libraries/ghc-internal/src/GHC/Internal/Base.hs#L351-380), along with our current strategy for managing this problem: Whenever a module X implicitly depends on some known-key thing defined in module Y, the transitive imports of X should include Y. But compliance with this requirement has been inconsistent in practice, leading to issues like #23942 and intermittent CI failures like [this one](https://gitlab.haskell.org/ghc/ghc/-/jobs/1795889) or [this one](https://gitlab.haskell.org/ghc/ghc/-/jobs/1796989).
I do not put blame on the patch authors and reviewers who have recently introduced modules breaking this requirement and thus causing intermittent build errors for everyone: this requirement is obscure and easy to forget. We need an enforcement mechanism, so that mistakes in implicit-dependency imports can be consistently detected _before_ they get merged.
## Solution ideas
1. We could try to explicitly record these implicit dependencies in GHC's down-sweep. This is arguably the _correct_ thing to do. To do this perfectly, we must first identify all potential sources of implicit dependencies before this becomes reliable, and that seems a bit tricky for now.
2. We could add a flag to GHC that causes it to log when-ever it actually tries to read an interface file, then check that the logs generated while building stage 2 are compatible with the dependencies graph used to order building.
3. I am doing some related work in !12179, and the way I smoke-tested my changes to implicit-dependency imports in that patch was by:
* Building a stage-2 compiler in `_build`,
* Reading the various `_build/stage1/**/.dependencies` files to see what hadrian thinks the dependencies are,
* For each output (`*.o` or `*.o-boot`) file X that does not transitively depend on `GHC.Internal.Base`:
* Delete the various `*.o*` and `*.hi*` files in `_build/stage1/`.
* Instruct hadrian to build only X. (If X has an un-tracked implicit dependency, this should fail.)
Why limit the search outputs that don't depend on `GHC.Internal.Base`? Because all _known_ sources of implicit dependencies either
* ...are in the transitive imports of `GHC.Internal`, or
* ...involve `DeriveLift` and can be fixed by re-structuring the `template-haskell` library (#22229), or
* ...involve JS foreign imports/exports with the WASM back-end. (Perhaps this is specific enough to handle with approach 1?)
* ...are not likely to ever be problematic, like using arrow-syntax without transitively importing the `Arrow` typeclass. (It is very hard to solve the `Arrow` constraints this produces when the class and all of its instances are out of scope.)
Since there are only a few dozen modules and boot-modules that do not depend on `GHC.Internal.Base`, I believe the cost of this validation approach should be affordable. And I think it would be relatively easy for one of the CI gurus to automate this approach. But it's definitely a bit of an ugly hack. Option 2 seems much better in the long run. (The smoke-test was still valuable; doing this caught a couple of issues I missed in !12179.)https://gitlab.haskell.org/ghc/ghc/-/issues/24407head.hackage: ghc-debugger's test:system-test hangs on test-downstream job2024-02-06T15:33:58ZBryan Rbryan@haskell.foundationhead.hackage: ghc-debugger's test:system-test hangs on test-downstream jobThe failure affects both x86-64 and arm64.
Example 1:
https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1769505
Full list:
https://gitlab.haskell.org/ghc/head.hackage/-/jobs?statuses=RUNNING
![image](/uploads/bc181b40cb8e8753603fb7...The failure affects both x86-64 and arm64.
Example 1:
https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1769505
Full list:
https://gitlab.haskell.org/ghc/head.hackage/-/jobs?statuses=RUNNING
![image](/uploads/bc181b40cb8e8753603fb7344a9732cb/image.png)
(and many more)
Since a test timeout is treated as a spurious failure, these get restarted. I think there's around 10 restarts, which results in pipelines taking 80 hours to fail entirely. The result is that many head.hackage pipelines are still running.
https://gitlab.haskell.org/ghc/head.hackage/-/pipelines?page=1&scope=all&status=running
![image](/uploads/cd6673132a4e42c70488ae23434c1242/image.png)
Luckily, the test is merely zombied and doesn't take any system resources. Therefore I'll keep them running for now, so people can investigate. Example process tree:
```
489457 ? S 0:00 \_ bash /nix/store/36qkrsgvqb0scf7hcdr45vz37nbi904x-run-ci
489516 ? Sl 0:00 \_ /nix/store/jx4pn482brdqi9fp41m6faawwcibq354-head-hackage-ci-0.1.0.0/bin/head-hackage-ci test-patches --extra-cabal-fragment=/builds/ghc/head.hackage/ci/run/deps.cabal.project --patches=../../patches --with-compiler=/builds/ghc/head.hackage/ghc/bin/ghc --extra-cabal-fragment=/builds/ghc/head.hackage/ci/config.cabal.project --expect-broken=charsetdetect --expect-broken=packman --extra-package=lens==5.2.2 --extra-package=optics==0.4.2.1 --extra-package=aeson==2.2.0.0 --extra-package=criterion==1.6.2.0 --extra-package=scotty==0.12.1 --extra-package=generic-lens==2.2.2.0 --extra-package=microstache==1.0.2.3 --extra-package=singletons-base==3.1.1 --extra-package=servant==0.20 --extra-package=hgmp==0.1.2.1 --extra-package=Agda==2.6.3 --extra-package=mmark==0.0.7.6 --extra-package=doctest==0.22.0 --extra-package=tasty==1.4.3 --extra-package=pandoc==3.1.5 --extra-package=servant-conduit==0.16 --extra-package=servant-machines==0.16 --extra-package=linear-generics==0.2.2 --extra-package=futhark==0.25.2 --extra-package=generic-random==1.5.0.1 --extra-package=lame==0.2.1 --extra-package=inspection-testing==0.5.0.2 --extra-package=ghcide==2.0.0.1 --extra-package=vector-space==0.16 --build-tool-package=alex --build-tool-package=happy --build-tool-package=c2hs --only=tasty --test-package=system-test=/builds/ghc/head.hackage/ci/../tests/ghc-debug/test/ --test-package=ghc-tests=/builds/ghc/head.hackage/ci/../tests/ghc-tests --test-package=all=/builds/ghc/head.hackage/ci/../tests/text --test-package=bytestring-tests=/builds/ghc/head.hackage/ci/../tests/bytestring --test-package=all=/builds/ghc/head.hackage/ci/../tests/containers/containers-tests --cabal-option=-j5 --ghc-option=-dlint
548483 ? Sl 0:00 \_ /nix/store/gwlb8xmagw5a8wam56ja1l0xjpzd139a-cabal-install-3.10.1.0/bin/cabal new-test system-test --enable-tests -j5 -w /builds/ghc/head.hackage/ghc/bin/ghc
548511 ? Sl 0:00 \_ /nix/store/gwlb8xmagw5a8wam56ja1l0xjpzd139a-cabal-install-3.10.1.0/bin/.cabal-wrapped act-as-setup --build-type=Simple -- test --verbose=1 --builddir=/builds/ghc/head.hackage/ci/run/test-system-test/dist-newstyle/build/aarch64-linux/ghc-9.9.20240202/ghc-debugger-0.5.0.0/t/system-test --log=$pkgid-$test-suite.log --machine-log=$pkgid.log --show-details=failures system-test
548522 ? Sl 0:00 \_ /builds/ghc/head.hackage/ci/run/test-system-test/dist-newstyle/build/aarch64-linux/ghc-9.9.20240202/ghc-debugger-0.5.0.0/t/system-test/build/system-test/system-test
548717 ? Z 0:00 \_ [clock] <defunct>
```9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24397Log which tests (under which ways) actually ran (or not) during a job2024-01-30T16:14:11ZZubinLog which tests (under which ways) actually ran (or not) during a jobIssues like #24369 show that it is not always clear which tests run for which jobs. We should have an artifact that makes it easy to see which tests actually ran in which jobs, along with which ways they ran under.Issues like #24369 show that it is not always clear which tests run for which jobs. We should have an artifact that makes it easy to see which tests actually ran in which jobs, along with which ways they ran under.https://gitlab.haskell.org/ghc/ghc/-/issues/24380Build alpine bindists on more recent alpine release (3.18)2024-02-14T17:06:58ZMatthew PickeringBuild alpine bindists on more recent alpine release (3.18)We are lagging behind a bit with maintaing support for alpine. We are currently stuck on 3.12 release. The latest is 3.19.
I am attempting a CI job to update to 3.18 here: https://gitlab.haskell.org/ghc/ghc/-/jobs/1761681We are lagging behind a bit with maintaing support for alpine. We are currently stuck on 3.12 release. The latest is 3.19.
I am attempting a CI job to update to 3.18 here: https://gitlab.haskell.org/ghc/ghc/-/jobs/1761681Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24310ghcup-metadata jobs can be prevented from running by head.hackage failures2024-01-09T17:08:27ZZubinghcup-metadata jobs can be prevented from running by head.hackage failuresThe ghcup metadata pipeline requires all prior jobs to pass. The hackage job can easily fail due to API changes or similar - so we should allow it to fail.The ghcup metadata pipeline requires all prior jobs to pass. The hackage job can easily fail due to API changes or similar - so we should allow it to fail.ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24209Alpine-based CI jobs fail with out-of-date Hackage index2023-11-28T15:24:20ZBen GamariAlpine-based CI jobs fail with out-of-date Hackage indexNightly Alpine jobs are failing with:
```
Running hadrian/build-cabal --flavour=release+fully_static -j8 --broken-test= --bignum=gmp --docs=none test:all_deps binary-dist -V...
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3...Nightly Alpine jobs are failing with:
```
Running hadrian/build-cabal --flavour=release+fully_static -j8 --broken-test= --bignum=gmp --docs=none test:all_deps binary-dist -V...
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.6.2.0 supports
'ghc' version < 9.4): /opt/ghc/9.4.3/bin/ghc is version 9.4.3
Warning: Requested index-state 2023-10-05T11:38:51Z is newer than
'hackage.haskell.org'! Falling back to older state (2022-06-09T19:15:55Z).
Resolving dependencies...
cabal: Could not resolve dependencies:
...
```
For instance, see Job [#1717907](https://gitlab.haskell.org/ghc/ghc/-/jobs/1717907), Job [#1717906](https://gitlab.haskell.org/ghc/ghc/-/jobs/1717906), and Job [#1717910](https://gitlab.haskell.org/ghc/ghc/-/jobs/1717910).
This is strange since we earlier had run:
```
Running /usr/local/bin/cabal update -w /opt/ghc/9.4.3/bin/ghc hackage.haskell.org,2023-10-05T11:38:51Z...
Config file path source is default config file.
Config file /builds/ghc/ghc/cabal/config not found.
Writing default configuration to /builds/ghc/ghc/cabal/config
Downloading the latest package list from hackage.haskell.org
Updated package list of hackage.haskell.org to the index-state 2023-10-05T11:38:51Z
```
My initial suspicion was that we are using a different `cabal-install` between these two invocations. However, looking at `ci.sh` it appears that we use `$CABAL` consistently. Very odd.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24177Allocation variations in MultiLayerModulesTH_Make2023-12-21T21:18:02ZRodrigo MesquitaAllocation variations in MultiLayerModulesTH_MakeRecent upgrades in the darwin runners resulted in the `MultiLayerModulesTH_Make` metrics varying in a way that breaks CI.
@mpickering is investigating the divergencies, but, in the meantime, we are going to disable the test on darwin to...Recent upgrades in the darwin runners resulted in the `MultiLayerModulesTH_Make` metrics varying in a way that breaks CI.
@mpickering is investigating the divergencies, but, in the meantime, we are going to disable the test on darwin to unblock CI.Matthew PickeringZubinMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24108Add support for more LLVM targets2023-10-24T15:06:13ZglaubitzAdd support for more LLVM targets## Motivation
LLVM supports far more targets than the native code generator (NGC) available in GHC [1].
If GHC could be extended to provide LLVM backend support for LLVM targets such as M68k, MIPS, PowerPC and SPARC, it would for a fas...## Motivation
LLVM supports far more targets than the native code generator (NGC) available in GHC [1].
If GHC could be extended to provide LLVM backend support for LLVM targets such as M68k, MIPS, PowerPC and SPARC, it would for a faster compiler on these targets since LLVM-IR is more efficient than intermediate C code.
If LLVM support was available for 32-bit PowerPC, for example, it could easily be used to work around #23969.
## Proposal
Enable LLVM target support for M68k, MIPS, PowerPC and SPARC.
> [1] https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targethttps://gitlab.haskell.org/ghc/ghc/-/issues/24093user_guide.pdf not present in doc tarball2024-03-17T23:54:24ZBen Gamariuser_guide.pdf not present in doc tarballIn 9.8.1 the PDF version of the user-guide did not make it into the doc-tarball which gets uploaded to `downloads.haskell.org`.In 9.8.1 the PDF version of the user-guide did not make it into the doc-tarball which gets uploaded to `downloads.haskell.org`.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24085wasm jobs does not set CROSS_EMULATOR in `gen_ci.hs`2023-10-30T13:45:58ZMatthew Pickeringwasm jobs does not set CROSS_EMULATOR in `gen_ci.hs`It is quite confusing that the wasm jobs set `CROSS_EMULATOR` somewhere outside of `gen_ci.hs`.
In fact, it's confusing that any build configuration is not specified in either hadrian or the CI generation script. It should all be there...It is quite confusing that the wasm jobs set `CROSS_EMULATOR` somewhere outside of `gen_ci.hs`.
In fact, it's confusing that any build configuration is not specified in either hadrian or the CI generation script. It should all be there so it is uniform with the other build jobs.
Therefore the proposal is that anything which affects the running of the CI script should be set in `gen_ci.hs` rather than a separate script.https://gitlab.haskell.org/ghc/ghc/-/issues/24060Pin the version of git used in Darwin CI2023-10-19T12:29:40ZBryan Rbryan@haskell.foundationPin the version of git used in Darwin CIFollowup to #24055.
On Darwin, `git` comes from the system and isn't pinned. Some versions of git seemed to have a bug that was the root cause of #24055. The bug was present in 2.40.1, but absent in 2.42.0.
Darwin CI should use a pinne...Followup to #24055.
On Darwin, `git` comes from the system and isn't pinned. Some versions of git seemed to have a bug that was the root cause of #24055. The bug was present in 2.40.1, but absent in 2.42.0.
Darwin CI should use a pinned, working version of git to prevent future surprises.https://gitlab.haskell.org/ghc/ghc/-/issues/23757CI: Spurious allocation failures on Windows2023-08-14T09:41:30ZBryan Rbryan@haskell.foundationCI: Spurious allocation failures on Windows@sheaf has observed spurious failures on Windows:
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1614138#L8156
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1614237#L5050
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1614491#L8168
* https://gi...@sheaf has observed spurious failures on Windows:
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1614138#L8156
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1614237#L5050
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1614491#L8168
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1614627#L8172
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1604123
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1604199
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1603516
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1603657
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1604430
* https://gitlab.haskell.org/ghc/ghc/-/jobs/1604026
Originally reported as comments to #23655.Moritz AngermannBryan Rbryan@haskell.foundationMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/23641emsdk >? 3.1.40 breaks javascript build2023-08-08T15:23:04ZMatthew Pickeringemsdk >? 3.1.40 breaks javascript buildIn #23585 we discovered that new versions of emsdk break some of the javascript tests.
For example we see in this job: https://gitlab.haskell.org/ghc/ghc/-/jobs/1598987
```
Unexpected failures:
/builds/ghc/ghc/tmp/ghctest-46palsnb/t...In #23585 we discovered that new versions of emsdk break some of the javascript tests.
For example we see in this job: https://gitlab.haskell.org/ghc/ghc/-/jobs/1598987
```
Unexpected failures:
/builds/ghc/ghc/tmp/ghctest-46palsnb/test spaces/testsuite/tests/callarity/unittest/CallArity1.run CallArity1 [bad exit code (1)] (normal)
/builds/ghc/ghc/tmp/ghctest-46palsnb/test spaces/testsuite/tests/corelint/LintEtaExpand.run LintEtaExpand [bad exit code (1)] (normal)
/builds/ghc/ghc/tmp/ghctest-46palsnb/test spaces/testsuite/tests/ghc-api/T10942.run T10942 [bad exit code (1)] (normal)
/builds/ghc/ghc/tmp/ghctest-46palsnb/test spaces/testsuite/tests/ghc-api/T18522-dbg-ppr.run T18522-dbg-ppr [bad exit code (1)] (normal)
/builds/ghc/ghc/tmp/ghctest-46palsnb/test spaces/testsuite/tests/ghc-api/T9595.run T9595 [bad exit code (1)] (normal)
```
Which are caused by failures of this kind:
```
T18522-dbg-ppr: ghc no longer supports single-file style package databases (/builds/ghc/ghc/_build/stage1/lib/package.conf.d) use 'ghc-pkg init' to create the database with the correct format.
```
Perhaps this is a regression in emsdk but for now in the images we are pinning the version to 3.1.40 which works.https://gitlab.haskell.org/ghc/ghc/-/issues/23615Remove x86_64 deb9 bindists2023-08-24T19:20:19ZMatthew PickeringRemove x86_64 deb9 bindistsUbuntu 18 and Linux Mint 19 are now EOL so debian 9 bindists are on their last legs (deb9 is also now EOL).
If something happens to the deb9 build we should just retire these bindists rather than attempt to fix it again.
cc @maerwaldUbuntu 18 and Linux Mint 19 are now EOL so debian 9 bindists are on their last legs (deb9 is also now EOL).
If something happens to the deb9 build we should just retire these bindists rather than attempt to fix it again.
cc @maerwaldhttps://gitlab.haskell.org/ghc/ghc/-/issues/23544Allow restarting builds on forks2023-06-27T14:40:31ZKrzysztof GogolewskiAllow restarting builds on forksRight now, only users with administrative privileges can restart a build on a fork. Because CI is flaky and new contributors create their own forks, this means reviewers often can't land a change without assistance.
Ideally, restarting ...Right now, only users with administrative privileges can restart a build on a fork. Because CI is flaky and new contributors create their own forks, this means reviewers often can't land a change without assistance.
Ideally, restarting CI on a fork should be available at least on the Developer level. I don't know how hard is to change that in Gitlab.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23495Residency profiling doesn't distinguish x86 and aarch642023-06-14T12:52:31ZBryan Rbryan@haskell.foundationResidency profiling doesn't distinguish x86 and aarch64During the nightly run, GHC heap residency info is recorded and [displayed on Grafana](https://grafana.gitlab.haskell.org/d/RHebDhq7z/head-hackage-residency-profiling?orgId=2).
For some time, x86 and aarch64 jobs have both been recorded...During the nightly run, GHC heap residency info is recorded and [displayed on Grafana](https://grafana.gitlab.haskell.org/d/RHebDhq7z/head-hackage-residency-profiling?orgId=2).
For some time, x86 and aarch64 jobs have both been recorded but not differentiated. They should be.Bryan Rbryan@haskell.foundationBryan Rbryan@haskell.foundationhttps://gitlab.haskell.org/ghc/ghc/-/issues/23327"Out of memory" errors in Windows CI2023-05-03T10:20:48Zsheafsam.derbyshire@gmail.com"Out of memory" errors in Windows CIRecently I've been seeing several Windows CI jobs fail with "out of memory" errors:
```
LLVM ERROR: out of memory
Allocation failed
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtra...Recently I've been seeing several Windows CI jobs fail with "out of memory" errors:
```
LLVM ERROR: out of memory
Allocation failed
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
```
See e.g. [this job](https://gitlab.haskell.org/ghc/ghc/-/jobs/1462772#L4891).https://gitlab.haskell.org/ghc/ghc/-/issues/23269CI job "abi-test-nightly" is broken2023-05-08T16:21:39ZBryan Rbryan@haskell.foundationCI job "abi-test-nightly" is brokenThis job tries to untar a file `ghc-x86_64-linux-fedora33-release-hackage_docs.tar.xz`, but it doesn't exist.
The job depends on two previous jobs, "nightly-x86_64-linux-fedora33-release-hackage" and "nightly-x86_64-linux-fedora33-relea...This job tries to untar a file `ghc-x86_64-linux-fedora33-release-hackage_docs.tar.xz`, but it doesn't exist.
The job depends on two previous jobs, "nightly-x86_64-linux-fedora33-release-hackage" and "nightly-x86_64-linux-fedora33-release", but apparently neither of them have that file in their artifacts.
This job has never succeeded. :)Bryan Rbryan@haskell.foundationBryan Rbryan@haskell.foundationhttps://gitlab.haskell.org/ghc/ghc/-/issues/23262GitLab never shows pipeline status on some MRs2023-04-18T16:47:35ZBryan Rbryan@haskell.foundationGitLab never shows pipeline status on some MRsGitLab sometimes fails to ever show pipeline status.
![image](/uploads/d5c7917fe17663877439cccf33dc9c47/image.png)
→ from https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10290
This looks like a GitLab bug that we may want to take u...GitLab sometimes fails to ever show pipeline status.
![image](/uploads/d5c7917fe17663877439cccf33dc9c47/image.png)
→ from https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10290
This looks like a GitLab bug that we may want to take upstream when somebody gets the chance.
## Workaround
Trigger a pipeline manually by going to the MR's "Pipelines" tab and clicking "Run pipeline".
![image](/uploads/3a2cced2be4d86d5507c1fe936df9066/image.png)