Update tools in CI #946
Update tools in CI #946
Conversation
It appears tat at least alpine:3.16 is broken and produces linking errors.
|
kinda blocked by #962 |
|
@hasufell what's the motivation behind this PR? |
| @@ -327,12 +327,10 @@ executable ghcup | |||
| , brick ^>=2.1 | |||
| , transformers ^>=0.5 | |||
| , vty ^>=6.0 | |||
| , unix ^>=2.7 | |||
There was a problem hiding this comment.
how is this change related to updating tools in CI?
There was a problem hiding this comment.
It fixes windows CI as the commit says
There was a problem hiding this comment.
I don't split my work into 3 or 4 different PRs when I'm actively working on CI in general. It's just confusing.
So we'll have to make a decision here what to do with i386 alpine and move the PR forward
|
We should always build ghcup with the recommended version. Even before that GHC is recommended. |
The only real GHC bug might be the alpine segfault. Everything else are ecosystem issues. And for the alpine thing I have not submitted a bug report. I don't have a small reproducer. |
Agreed. Would it be viable to also build with other, known-to-work versions of GHC? Instead of picking a single GHC version? If there are known issues building stuff with GHC 9.4.8, but we also build with e.g. GHC 9.4.5 in CI and this succeeds, then I see nothing wrong with merging the PR, as it's clear from the CI runs that it's GHC version 9.4.8 that's problematic (and we have issues to track this). |
Well, right now we don't make much of a distinction between PR build and release build. I don't want more than one GHC build in the release pipeline. So that would require splitting the workflows. |
What's the reason for this? Slowness? |
The release pipeline is there to ship the ghcup binaries. We want as few points of failure as possible. |
No description provided.