Tectu
commented
2 years ago I really appreciate that you took the time to sort this out. This has been a real sore point. I kept pushing tackling this situation further and further because I was hoping that at one point we'd be actually able to fix some of the problems but much like you I spend quite some time on some of these issues (namely the MSYS2 shared builds) and came up with pretty much nothing.
The MSYS2 shared tests: I am still using the msys2 shared builds everyday and the resulting binaries definitely work (and seem to work well/stable). It's just the tests that make it go... I don't even know what - hang / crash / segfault / ...
The MSVC TLS builds: I think there's not much we can do about this situation anyway. It is what it is. Unless GitHub gives us more memory we can't do much other than disabling this particular configuration.
This is a bunch of misc fixes for the ci, with the aim of making it pass for mostly ok commits (with a few exceptions, see below).
In order to do this I have had to remove the shared build from msys, and the tls build from msvc. I did try to get the msvc build working but I think it may just be too much for the memory of the vm (resources required to compile possibly should be something we look at, but its not something I know much about in terms of optimisation).
The mingw build seems to be just borked completely in shared mode, I have no idea what the issue is there and any attempts to debug it are proving pointless (at least for me, the point of hanging even changes randomly it seems). My best guess is its something to do with the dynamic loading of the different parts of malloy but thats just a wild guess based on the fact it only happens in the shared build.
I believe removing these are ok because they always failed anyway no matter the content of the commit and thus didn't actually provide anything useful in terms of checks, #89 is still an issue though and we might want to open a tracking issue for the msvc stuff.
Other changes: msys/clang -> msys/mingw