pjbroad
commented
5 months ago Hi. Nice work and something I've considered a few times. I even have a local .yml file for the Linux build that never got around to committing. I had not worked out how to do the Windows build though, and that looks simpler to do with Actions than I'd expected. I have build scripts for all the builds I do, some published on the build methods repo, like the the Windows build that you look to have reused here. We could base the Android build on that too perhaps, though it is in need of updating to more modern Android tooling perhaps. @bendoughty added the maxOS build info to that repo. I have scripts for the Linux static build and the App Image build which I have on my to-do to commit. I published that repo using the GPL 3 licence so it should perhaps be mentioned here :) The snap build is automated through Launchpad, similarity the Ubuntu packages into a PPA. I run my own repo for Debian packages as Debian would not accept the EL licence, I think @feeltheburn does a SUSE package. The Flatpak build is via the Flatpak Github repo. Building the client executable is just one step though. A full release requires the data too, and packaging into something that can be downloaded and executed. For the builds I do, that's mostly though scripts but there are still some manual steps to preparing the data archives. The Windows client is always packaged with the additional DLLs required, even when the data is not included.
Anyhow, I'll merge this and set it up as a start. Thanks :)
Exzap
Hi again, from what I understand, and please correct me if I am wrong, the process of testing whether builds still compile or not is all done manually right now for the Eternal Lands client and the map editor.
Therefore I propose to add automated build testing via github workflows to help catch compile errors and other build problems automatically. If you are not familiar with the concept of CI, a very simplified explanation is that workflows allow you to run arbitrary scripts automatically as a response to commits, pushes or other git events. A common use case is verifying if the codebase still builds on all targeted platforms after each commit and before a PR is merged. Github workflows are also nicely integrated into the web UI.
As a visual example, for a pull request the workflow results are displayed like this (screenshot taken from another project):
Virtually all bigger projects on github use CI workflows already since it's a really nice convenience feature and free of cost for public repositories. For an additional demonstration you can take a look at OpenTTD's commit list (click on the little green check marks) or any of their pull requests.
Since you can run arbitrary scripts it makes workflows very flexible. In my other projects we use this to generate downloadable binaries for each commit or PR, so developers and users can quickly test a new change and raise an issue if something breaks. We also have a "release" workflow which is manually triggered and compiles all the builds, packages them and automatically creates a draft github release.
With this PR I added an initial workflow that simply verifies if the following configurations still build successfully:
Other configurations are still missing (android, macos, appimage, windows map editor, etc.) because I didn't want to invest too much time yet in case this gets rejected. If approved, I can look into adding more build targets. Also, I am available to help maintain this in the future but generally once its setup it doesn't really break or need much attention.
As a side note, I considered asking via issue first if you even want this, but it's easier to just demonstrate it than to explain the theory behind it. Looking forward to your thoughts and I hope you can see the value in automated build testing. If you have any questions let me know.