Disabling Darwin jobs on GitLab CI

[chreekat]

Hi folks,

I am likely going to disable Darwin jobs in GitLab's CI for the following reasons.

1. GHCup builds its own Darwin bindists
2. Everybody builds their own bindists (see Formalising our stance regarding binary distribution of cabal-install #9827)
3. Darwin is already tested in GitHub
4. GitLab Darwin jobs are failing because of some Clang issue I don't really want to look into, because....
5. GitLab Darwin runners are unholy. I'm going to try to exorcise the demons for GHC's sake. Eventually this should let me bring back Cabal's jobs, but in the meanwhile removing the jobs lets me move faster for GHC's sake.

Any strong reasons I should not do so?

[chreekat]

Not really a "user question" hehe

[Kleidukos]

@chreekat uhm, looking at #9827 (comment) you better make sure that Homebrew switches to ghcup's bindists before disabling the runner.
Otherwise they are going to have a very bad surprise.

[chreekat]

@Kleidukos thanks for bringing that to my attention!

[Mikolaj]

@chreekat: thank you for the heads-up.

Otherwise they are going to have a very bad surprise.

But they are building from source, right? I agree, for their sake, the Darwin-building of the source should be tested, but it's already tested on github (though the extra test on gitlab is valuable, in general, especially that it's release-focused).

[Mikolaj]

Oh, I see, they build from source, but bootstrap with bindist! So you are right, this is a blocker.

But otherwise, I think #9827 indicates our release CI is now going to be focused on testing the next release artifact-generation step continuously and in advance of the release (moreover, in a different environment that the PR CI). Opportunistically, we can just as well publish the generated artifacts at release time. Both use cases should be fine with (temporarily) reduced set of architectures. Generally, piggy-backing on GHC CI, which is relatively low-cost, seems like a great fit. That means, GHC CI takes precedence and only minimal extra cabal-specific tweaks sound cost-effective.

[Mikolaj]

BTW, i guess they could just as well bootstrap with their own Homebrew last-cabal-version binaries?

[Kleidukos]

We can probably ask @fishtreesugar on their opinion?

[chreekat]

GitLab Darwin jobs are failing because of some Clang issue I don't really want to look into, because....

I decided to look into it, because if we know somebody is using the bindists, I'd like to keep making them available.

It didn't take long for me to find https://discourse.haskell.org/t/solved-trouble-building-unix-package-on-macos-ld-unknown-option-no-fixup-chains/7772/15 . I'll just try using a different version of GHC.

[chreekat]

Closing since I won't disable them.

[Mikolaj]

Still, @fishtreesugar, do you think it could be relatively easy to insulate Homebrew from our provisional distribution channel by, e.g., using for bootstrapping the previous Homebrew binaries or a specialized distribution service, meaning, ghcup?