search

UltraStar-Deluxe / USDX

The free and open source karaoke singing game UltraStar Deluxe, inspired by Sony SingStar™
https://usdx.eu
GNU General Public License v2.0
808 stars 160 forks source link

Build Linux, MacOS and Windows platform in Github Actions CI #840

Closed DeinAlptraum closed 2 months ago

DeinAlptraum commented 2 months ago

This is a first attempt at a Github Actions CI. It currently successfully builds for Windows (32 btit), MacOS (Intel) and Linux (64bit).

There's still a few problems and open questions though:

TL;DR this is very much a WIP except that I have no idea how to proceed with the problems I mentioned. I guess in the current state this cannot replace the existing CI, but I thought I'd still leave this here in case someone wants to pick this up or knows how to fix these problems. Not sure if GH Actions are enabled on this repo, so here's a link to how a build looks like currently on my fork.

barbeque-squared commented 2 months ago

Wow, this is some good progress!

I do not know what causes this error (no, "run as admin" doesn't fix this) and googling it did not really help either. Since I have no experience with NSIS, maybe someone here knows?

I have the same issue on my own Windows machine. Regardless of how I build it, I cannot run the installer it creates. I can only run the old CI-generated installers.

Not sure if GH Actions are enabled on this repo, so here's a link to how a build looks like currently on my fork.

It would be good if the generated filenames included some abbreviated version information I think. Doesn't need to be the exact filename the old CI generated (I always had to remove some part of it). I'm not sure what is and isn't easy to implement, but a very naive approach would be to look at the VERSION file: if it ends in dev, put dev-<datetime/hash/revisionnumber/whatever> somewhere, else just put the version number in it.

Trying to do the Linux build via the Docker image (like the AppVeyor CI does) just leads to a build failure with no error message somewhere in tasks.sh, see here.

There is some earlier error output on line 1826, though I can't tell if those are expected or not. It installs these in previous steps yet they aren't available here. I don't have the time right now to look into why this is happening, but it's probably related to why the make command at the end errors out?

s09bQ5 commented 2 months ago

There is some earlier error output on line 1826, though I can't tell if those are expected or not.

That's expected. The version check tries cmake3 afterwards.

I think the problem is that the terminal type passed by Github in the TERM variable does not define the sgr0 capability. That would explain why it fails between "==> Building all dependencies" and "==> Cleaning prefix".

DeinAlptraum commented 2 months ago

Update, see the most recent build here

I think the problem is that the terminal type passed by Github in the TERM variable does not define the sgr0 capability. That would explain why it fails between "==> Building all dependencies" and "==> Cleaning prefix".

Thanks and well spotted! I've removed all tput commands for now and at least we get a step further now. The build now fails because dists/flatpak/patches/projectM-2.2.1.patch doesn't exist. I'm not sure what's supposed to happen here tbh, I don't see any such file existing in the repository and also don't see this being generated somewhere. Do you know where this comes from?

Also note that the Docker image takes a long time to build, at ~12mins about 4 times as long as the other platforms

I have the same issue on my own Windows machine. Regardless of how I build it, I cannot run the installer it creates. I can only run the old CI-generated installers.

Through guessing and sheer luck I found out that this is an issue with versions >= 3.05 of NSIS. AppVeyor still uses 3.04 which coincidentally seems to be the latest fully working version at least for our case. Manually downgrading the runner to NSIS 3.04 thus fixed the installer. With this, only the Linux AppImage creation remains to be fixed

It would be good if the generated filenames included some abbreviated version information I think. [...] a very naive approach would be to look at the VERSION file: if it ends in dev, put dev-<datetime/hash/revisionnumber/whatever> somewhere, else just put the version number in it.

I've appended the version (as well as +dev-<short commit hash> if it ends on +dev) to all artifact names, as well as the file if it contains only one (GHA insists on zipping even single-file artifacts), see the linked build for examples. I hope this is what you imagined

bohning commented 2 months ago

Judging from binutils is keg-only, which means it was not symlinked into /usr/local, because it shadows the host toolchain. and the fact that I do not have binutils installed and can build USDX just fine, you can probably remove binutils from the Mac dependencies without any issues and save a few seconds.

s09bQ5 commented 2 months ago

The build now fails because dists/flatpak/patches/projectM-2.2.1.patch doesn't exist. I'm not sure what's supposed to happen here tbh, I don't see any such file existing in the repository and also don't see this being generated somewhere. Do you know where this comes from?

Fix is in #841

s09bQ5 commented 2 months ago

I've removed all tput commands for now and at least we get a step further now.

No need to do that if #842 gets merged

DeinAlptraum commented 2 months ago

Thanks to @s09bQ5's two changes, the build now goes through on Linux. I also tested that the AppImage works Additionally, I added caching to the Linux build in the same way as AppVeyor did, so as long as dl.sh and tasks.sh remain unchanged, the build time should be down to about 5mins on Linux.

An example of a build with cache hit can be seen here, and the build for the version I just pushed (without cache hit) can be seen here