Automated build checks

[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:

• Eternal Lands client on Ubuntu
• Eternal Lands client on Windows via msys
• Map Editor on Ubuntu

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.

[pjbroad]

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]

Here are unfinished steps for an Android build btw, partially based on your repo instructions. It gave me a nondescript error message and further debugging would be necessary. Thats why I decided to omit this for the initial PR.

  build-android:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2

      - name: Set up JDK 8
        uses: actions/setup-java@v2
        with:
          java-version: '8'
          distribution: 'adopt'
      
      - name: Install Dependencies
        run: |
          sudo apt-get update
          sudo apt-get install -y git wget unzip ant

      - name: Set up Android Tools and Build Tree
        env:
          ANDROID_HOME: ${{ github.workspace }}/android-tools
        run: |
          mkdir $ANDROID_HOME
          wget https://dl.google.com/android/repository/tools_r25.2.5-linux.zip -P $ANDROID_HOME
          unzip $ANDROID_HOME/tools_r25.2.5-linux.zip -d $ANDROID_HOME
          $ANDROID_HOME/tools/bin/sdkmanager "platform-tools" "build-tools;30.0.3" "ndk-bundle" "platforms;android-19" "platforms;android-30"
          mkdir ${{ github.workspace }}/el
          git clone https://github.com/pjbroad/el-build-methods.git ${{ github.workspace }}/el/el-build-methods
          git clone https://github.com/raduprv/Eternal-Lands.git ${{ github.workspace }}/el/el-build-methods/android/jni/src

      - name: Build Android Package
        env:
          ANDROID_HOME: ${{ github.workspace }}/android-tools
        run: |
          cd ${{ github.workspace }}/el/el-build-methods/android/ &&
          ./setup-libs.bash &&
          ./build-apk.bash

For MacOS I tried to build via cmake + brew but I ran into issues with supplying cal3d (either built from source or via the framework). According to the instructions the intended way to build EL for MacOS right now is via xcode. But since I am not a mac dev I don't know how to automate that via command line.

I published that repo using the GPL 3 licence so it should perhaps be mentioned here

Any particular reason why the build instructions and scripts are not public domain in general?

[pjbroad]

Do you know which step failed? sdkmanager prompts for you to accept the licence, could that be it?

Any particular reason why the build instructions and scripts are not public domain in general?

As always, to encourage contributing back any changes.

[Exzap]

Do you know which step failed? sdkmanager prompts for you to accept the licence, could that be it?

I did another test run on my fork if you want to check it out in detail. It seems to fail during ./setup-libs.bash

[pjbroad]

I had a look through the huge log, its failing as it can't find the dev tools, and that is because the licence is not accepted for sdkmanager. You can auto accept the licience using:

echo y | $ANDROID_HOME/tools/bin/sdkmanager "platform-tools"

I'd also replace the final ./build-apk.bash with just the compile stage to avoid all the prompts and building a full apk:

APP_ALLOW_MISSING_DEPS=true $ANDROID_HOME/ndk-bundle/ndk-build -j $(nproc)

[Exzap]

Yes that seems to fix it, thanks! I will open a PR for the Android build after some more testing