Avoid making the user build something if you have the artifacts ready, pretty please?

[gabriele2000]

You have the actions that makes the linux build too, instead you're making users compile something, something that makes CMake complain if someone doesn't have the requirements that you didn't even specify.

After ONE HOUR of pulling each one of my hairs, in the most painful way possible, I go "for the lolz" in "Actions" and find the artifacts FOR LINUX that WORKS TOO.

How about including them when you release something, or at least telling potential users that "artifacts exists too, although we suggest to compile everything from scratch?" "BTW here's a docker image to build it, so it'll work and the build will be reproducible".

Sincerely, someone who spent more than one hour unsuccesfully compiling stuff because of untold requirements, JUST TO FIND THE LAUNCHER BUILT THOUGH "ACTIONS".

Just for the sake of helping everyone else, I'll set up a docker image and create some kind of automated stuff to build BeamMP-Launcher, no one, NO ONE, should have this pain. NO ONE.

[WiserTixx]

Which requirements did we not specify? I'd like to improve the guide if possible.

The issue with the actions currently is that the artifact it makes only works properly on ubuntu and related distros.

[gabriele2000]

The issue with the actions currently is that the artifact it makes only works properly on ubuntu and related distros

I created a script that creates a Dockerfile, executes it (it'll download and compile everything needed) and pulls the compiled launcher from it into the current working directory. I'll release it with a PR, that should fix the problem... although I'm using apt in the script, for now, I'll find a way to improve it before creating the PR, so that it'll be universal.

Which requirements did we not specify? I'd like to improve the guide if possible

Using a shell different than bash causes a lot of headaches... btw the docker container should fix everything, the build should work regardlessly.

only works properly on ubuntu and related distros

Uh, wait... please, explain, it's almost 3AM here and I'm not connecting.

[WiserTixx]

Using a shell different than bash causes a lot of headaches

Which shell did you use?

Uh, wait... please, explain, it's almost 3AM here and I'm not connecting.

It compiles the launcher dynamically so small differences in shared library versions (like glibc) between distros causes incompatibilities.

[gabriele2000]

Using a shell different than bash causes a lot of headaches

Which shell did you use?

Was helping a friend that used fish as shell

[WiserTixx]

Was helping a friend that used fish as shell

I've just tried compiling the launcher using fish on an ubuntu system, and besides env variables not transferring over from my previous shell (I had to add /bin to $PATH so it could find git and such) I experienced no issues. That's also only something that would happen to users that just installed it, and it would break a lot more than just BeamMP. It also tell you that git exists but is not in $PATH right away, for me at least.

What errors did you run into when using a different shell?

[gabriele2000]

and besides env variables not transferring over from my previous shell (I had to add /bin to $PATH so it could find git and such) I experienced no issues

That's something that, for an experienced user, would not be a problem, but for someone not familiar with all this, it would be a problem. The guide doesn't account for this, which is fine, but there's no system to build the launcher in a distro-agnostic way, and that's not ideal.

[gabriele2000]

https://github.com/gabriele2000/scripts-collection/blob/main/beammp-autoinstall.sh

This is my solution, it creates a dockerfile which will be executed, compiled and the file will be automatically transferred in the same working directory. I can't create a PR because I don't know where to put the script

[WiserTixx]

https://github.com/gabriele2000/scripts-collection/blob/main/beammp-autoinstall.sh

Does this work on all linux distros?

[gabriele2000]

Does this work on all linux distros?

For now it works in debian-based distros, gentoo and arch (I could test with those three) since the only true requirement on the host system is podman-docker for debian-based, podman for gentoo and docker for arch. Once it's installed it creates a dockerfile, so everything will be run inside the container, it compiles everything correctly regardless on the host system so yes, it runs on all distros technically (once podman/docker is installed)

There will be improvements that will fix this gap, of course.

[lionkor]

Unsolicited opinion as an occasional BeamMP player on Linux; This would probably be best suited as a PR to the current github actions to add actions to build for other relevant distros, plus release workflows that upload those artifacts. The reason I'm commenting is because I was around for the current github actions flow, and I remember it being purely a "hope and pray that it builds" CI step -- not a release build with everything.

The fact that the executables produced are not signed on platforms where code signing is practically mandatory should tell you about the intended purpose of the github actions workflows on this repo.

TL;DR: The open source spirit would be to PR your script as part of a github actions overhaul on this repo @gabriele2000, that would benefit everyone a lot I reckon.

[gabriele2000]

"hope and pray that it builds" CI step -- not a release build with everything.

It's very interesting, since the artifacts saved me from the pain that was compiling it... since that night when I had the idea to start this little "project" in the least-invasive way possible.

The fact that the executables produced are not signed on platforms where code signing is practically mandatory should tell you about the intended purpose of the github actions workflows on this repo.

Mine aren't signed too, since my idea was "the user downloads this and executes it, the compiled file will get transferred from the container to the working directory and the user will not see the whole stuff running"

TL;DR: The open source spirit would be to PR your script as part of a github actions overhaul on this repo @gabriele2000, that would benefit everyone a lot I reckon.

I'd very much like to do this, I'll take a look as soon as possible... note that I've never set up a github action but I'll figure this out surely.

PS: I suggest you to test my script if you'd like, since the dockerfile is set to use an Ubuntu 22.04 image, the compilation would be reproducible, in fact, the only dependency is podman/docker (I prefer podman)

EDIT: I was thinking: users shouldn't search through CI actions... let's just compile it and release it in "releases", since the dependencies are requires at compile-time. It's restricting that Linux users will not be able to find a package in Releases but in Actions.