Closed ravenexp closed 10 months ago
Hmm, I think test-msbuild.sh
requires wine-mono
to be installed in the CI test system...
Hmm, I think
test-msbuild.sh
requireswine-mono
to be installed in the CI test system...
Yes, I would think so. I've only briefly looked at msbuild before, and skipped as it was .NET based (and I'm very much not familiar with that whole ecosystem).
For the macos based CI build, it seems to have some suitable version of wine-mono available already (apparently included in whatever we install with homebrew), but on linux we'd probably need to request it separately.
Apart from that, I'd appreciate if test.sh
could check if mono seems to be available, and skip running test-msbuild.sh
if not. For the CI, we'd obviously want to actually run it, but for local installs, I'd like to be able to run the tests without bothering with msbuild and mono.
For the macos based CI build, it seems to have some suitable version of wine-mono available already (apparently included in whatever we install with homebrew), but on linux we'd probably need to request it separately.
Apart from that, I'd appreciate if
test.sh
could check if mono seems to be available, and skip runningtest-msbuild.sh
if not. For the CI, we'd obviously want to actually run it, but for local installs, I'd like to be able to run the tests without bothering with msbuild and mono.
It looks like I've accidentally disabled test-msbuild.sh
for macos as well... Does it not have /usr/share/wine/
?
For the macos based CI build, it seems to have some suitable version of wine-mono available already (apparently included in whatever we install with homebrew), but on linux we'd probably need to request it separately. Apart from that, I'd appreciate if
test.sh
could check if mono seems to be available, and skip runningtest-msbuild.sh
if not. For the CI, we'd obviously want to actually run it, but for local installs, I'd like to be able to run the tests without bothering with msbuild and mono.It looks like I've accidentally disabled
test-msbuild.sh
for macos as well... Does it not have/usr/share/wine/
?
On macOS, only the OS itself can touch /usr, package managers like homebrew usually install into /usr/local
(or in some cases /opt
).
I can not get MSBuild tests to work on either of the GitHub runners. They fail with different cryptic errors. Installing 32-bit WINE didn't help. I'm giving up for now.
Perhaps it can eventually be solved by updating WINE from an ancient v6.0 from 2021 shipped with Ubuntu 22.04 to something more modern.
I have wine-8.21
and wine-mono-8.1.0
installed locally and the tests work.
Ubuntu installs wine-6.0
with wine-mono-5.1.1
and fails the tests.
Perhaps it can eventually be solved by updating WINE from an ancient v6.0 from 2021 shipped with Ubuntu 22.04 to something more modern. I have
wine-8.21
andwine-mono-8.1.0
installed locally and the tests work. Ubuntu installswine-6.0
withwine-mono-5.1.1
and fails the tests.
Hmm, that could possibly be the issue, else it's something different in the environment which causes the mono execution to fail.
Is it possible to install a custom version of Wine from WineHQ in the CI runners, just for testing to sort out if this is the root cause?
Is it possible to install a custom version of Wine from WineHQ in the CI runners, just for testing to sort out if this is the root cause?
I tried installing stable Wine 8.0 from WineHQ and the MSBuild tests now indeed appear to work on Ubuntu. But then the runner bugged out. Can you perhaps kill and restart it?
EDIT: Nevermind, the runner has just finished successfully after spending 40 minutes doing something weird.
Is it possible to install a custom version of Wine from WineHQ in the CI runners, just for testing to sort out if this is the root cause?
I tried installing stable Wine 8.0 from WineHQ and the MSBuild tests now indeed appear to work on Ubuntu. But then the runner bugged out. Can you perhaps kill and restart it?
EDIT: Nevermind, the runner has just finished successfully after spending 40 minutes doing something weird.
Oh, lovely… Issues like that are always a risk when using wine in a CI-like setup. Is the issue reproducible? Does it happen when using the third party wine 8.0 without the whole mono/msbuild additions?
Oh, lovely… Issues like that are always a risk when using wine in a CI-like setup. Is the issue reproducible? Does it happen when using the third party wine 8.0 without the whole mono/msbuild additions?
Can you try restarting the test-msvc-wine-linux
check from the GitHub UI?
I'm now going to test it in a Debian 12 Docker image running in GitLab CI and report back.
Ok, the GitLab CI tests run finished in 4 minutes. No strange issues. But I do not install ARM MSVC toolchains into my image, so it was only running the first half of the tests.
I've run Linux tests two more times here on GitHub and there were no issues. MSBuild tests still don't work on macOS, so I didn't enable them in the final commit version. Apart from a seemingly random test-docker
failure, everything seems to be working now.
From my previous experience, GitHub runners sometimes just hang for no obvious reason, and simply restarting the job fixes that. I don't think it has anything to do with running Wine.
Oh, lovely… Issues like that are always a risk when using wine in a CI-like setup. Is the issue reproducible? Does it happen when using the third party wine 8.0 without the whole mono/msbuild additions?
After 7 more GitHub CI runs, I'm fairly confident that that problem is not reproducible. Stable WINE 9.0 was released this week, so the CI config required some adjustment and more runs. I've also tried several horrible hacks to get the tests to run on macOS, but it looks like Mono is just hopelessly broken on this system...
New commit https://github.com/mstorsjo/msvc-wine/pull/103/commits/5ee766db0468b7646e89178d7ce217abc0edcab5 addresses a fairly important issue I initially overlooked when submitting this PR. Today I've finally got kernel driver projects using the WDK to build, so now I'm fairly confident that MSBuild is configured correctly by its wrapper script.
New commit https://github.com/mstorsjo/msvc-wine/pull/103/commits/303d0bfd93a36c6cafbb284c6ddb58f8e0e77489 improves the UX of running MSBuild on Linux. I'm running it a lot now:)
Oh, lovely… Issues like that are always a risk when using wine in a CI-like setup. Is the issue reproducible? Does it happen when using the third party wine 8.0 without the whole mono/msbuild additions?
After 7 more GitHub CI runs, I'm fairly confident that that problem is not reproducible.
Thanks, that's good news.
Stable WINE 9.0 was released this week, so the CI config required some adjustment and more runs. I've also tried several horrible hacks to get the tests to run on macOS, but it looks like Mono is just hopelessly broken on this system...
Ok, that's totally no problem if we don't run these tests on macOS, as long as we test it successfully somewhere, and get a green CI run elsewhere.
New commit 5ee766d addresses a fairly important issue I initially overlooked when submitting this PR. Today I've finally got kernel driver projects using the WDK to build, so now I'm fairly confident that MSBuild is configured correctly by its wrapper script.
New commit 303d0bf improves the UX of running MSBuild on Linux. I'm running it a lot now:)
That's good to hear, good to know that it has a bit more trackrecord now!
Sorry I haven't had time to follow up on this in the last few days, I hope to have time to have a closer look again in a few days.
Thanks for the update - I think this mostly looks fine! @huangqinjin - are you ok with the last commit of the branch, it touches parts of wine-msvc.sh
that you've modified?
@mstorsjo The modification looks good to me.
msbuild.exe
wrapper script.Resolves #85