TMP COMMIT #6829
TMP COMMIT #6829
Conversation
|
Windows broken as I expected. Opened an issue actions/runner-images#919 |
|
@Mistuke will your chocolatey cabal-installation scripts detect if msys is isntalled in if it doesn't, how can I configure |
Yeah it will, it will search for it on the |
|
@Mistuke and few more questions:
The Windows setup will have multiple, but due how our tests are setup it's safer to have the GHC in path to be the one we are testing with |
I have never tried it with
All the GHC's will be on PATH. but you can pick the one you want by using the fully qualified ghc name, e.g. In principle I could write a utility to allow you to switch between them by re-arranging |
|
Yes, the problem is that if I'd use explicit In linux CI the image doesn't have |
The problem is the tools don't have any notions of when they're being installed side by side. So I can't do anything special here. So I guess a PATH utility could work. although if it accidentally picked up another ghc along with the one specified in
How does it not do that? In principle I could add a flag that when passed to chocolatey doesn't set |
|
But that said, I wouldn't be able to modify the existing installers.. They're readonly at this point. |
|
@Mistuke sorry for bothering but I have more questions:
|
|
@Mistuke and do I understand right that installing GHCs side-by-side with I.e. which one ends up in |
The hvr-ppa installs GHCs and cabal into directories which are not in the PATH by default. So user have to that manually. Linux users are used to that, it's not a problem. Cabal CI is different. The setup here is unfortunately complicated, so getting complete isolation is tricky. There are various issues (like interaction with global package environment files or packages in store) which are unfortunate but not major enough that I'd be motivated to tackle them (i.e. payoff is low). Now the GitHub actions setup changes stuff. I wish GitHub actions provided a minimal image. There is more work to correct the setup that we ever will save by saved startup time (which we won't anyway). |
|
.. or some way to customize the image, including just the software you need. |
Hmm it used to be there.. perhaps it's now explicit with the
It's only needed if you want access to packages I don't put on the community feed, such as the nightly cabal feed. It's just adding another source for packages.
yes, github actions has a fucked up way that it manages PATHs. the install seems to be failing can you pass |
Windows users already crucify me for using a commandline, I doubt they would grok having to modify PATH. Like I said I can do it as an option in future images, or you can simply "clean" the
What I don't get is why the image has to have every single version installed at once? Why can't you simply use something like AppVeyor's build matrix? Isn't that simpler? or does github actions not support something like that. |
The motivation seems to be that having tools preinstalled would save startup time. |
They are supported.
It's not arbitrary, they are appended to PATH. so first one always gets used first. which is why using the fully qualified name of the compiler works with |
The thing that takes largest amount of time is msys2, which you say will be preinstalled or could be. installing GHC and cabal on appveyor takes 1minute. it's just a download and extract. It'll save bandwidth sure, but highly doubt much in compile time.. You can speed this up by instead of caching the installs, cache the binaries using |
|
For I also I have no idea why nothing happens. I tried first uninstalling GHC and cabal, and then reinstalling them, and they work stuff worked. |
|
As you can see in #6831 commits, I run out of ideas. (Only uninstalling approach worked). Any new things to try are much appreciated. Until then I guess we have to not care about failing windows job. Luckily the Appveyor job acts as safety net (it does less, but it does something). |
Because it thinks it has nothing to do: did you remember to pass it a
I think you should cache the binaries, the install itself would be a second or 10, look at the time in the log, not sure it's worth the complication of caching the installs instead of the binaries. |
Yes, I had
Wil ltry that next.
I don't understand what you mean here. I tried to uninstall the preinstalled GHC and then install the version I wanted. It worked. The uninstallation took 10 minutes or so. Installation part was quick. |
Yes, because AppVeyor didn't do something ass stupid on their windows CI. I will get you a working script after the weekend. But I still recommend you cache the binaries instead of reinstall. |
My point it don't uninstall! Uninstall is slow because of how chocolatey tries to make it atomic and ensure it leaves nothing behind. It will always be slow. What I am suggesting is having and doing which should make a fresh install almost instant. and you can then use a build matrix like appveryor and cache Ok, instead install them with Otherwise We can clean the PATH after install. But can we talk after work... find me on irc might be easier. |
|
Does the above mean
That sounds plausible. I think I'll stop Cabal work in few hours for this week. |
Indeed, install everything with
Fair enough, have a good weekend! |
|
Obviously there is |
|
We can maybe do that with |
|
|
sigh |
|
@Mistuke for Cabal? The 8.6.5 is the oldest. I don't remember the reason we dropped GHC-8.4.4, probably it had some issues. Sadly my commit message is just
So I don't remember what exactly didn't work then. Doesn't matter now. Yet, GHC-8.6.5 is the only working one in GitHub Actions. 8.8 and 8.10 fail due https://gitlab.haskell.org/ghc/ghc/issues/17926, so currently we are squeezed. (Also looks like 8.8.4 won't happen, so maybe we won't be able to test |
|
I got CI green again in #6831, feel free to improve upon uninstall-reinstall hack. |
testing CI