ci: Separate Linux Builds for AppImages

[psadi]

This commit introduces the following changes:

• Utilized the pkgforge Arch Linux image for x86_64 and aarch64 builds
• Manually resolved build dependencies & employ pkgforge debloated packages (llvm, libxml, and ffmpeg) to minimize overall build size
• Updated uruntime build parameters for improved performance
• Added UPINFO for automatic AppImage updates

Closes #129

[jwr1]

Thank you for taking the time to do this!

Correct me if I'm wrong, but the way you've done it, it sort of seems like the Linux job would still work fine if it were still combined back into the original matrix, the big difference being that the container field is set in the job.

Also, how does UPINFO work?

[psadi]

The Linux job cannot be merged in this case because we use a container with an Arch Linux image and all workflow steps for the job will run within that environment. Merging it would interfere with the workflow steps for Android and Windows.

Currently, we are using the default GitHub runners, which function well. However, once we introduce containers and aim to maintain an end-to-end workflow within the same job, the image we provide must be compatible with all intended platforms (OS + Architecture).

[jwr1]

Couldn't we have the container field set only while the matrix OS is Linux?

So basically, instead of using "ubuntu-24.04" as the Linux OS, we'd be using Arch.

[psadi]

Couldn't we have the container field set only while the matrix OS is Linux?

The container option is a higher-level input (similar to environment and strategy) and to my knowledge, there isn't a built-in way to handle this conditionally. We can only select the image based on the matrix, which is why we separate Linux builds into their own job as the container field is not necessary for Android or Windows.

So basically, instead of using "ubuntu-24.04" as the Linux OS, we'd be using Arch.

Yes that's correct, and we do this to make use of pkgforge's de-bloatted packages to reduce the AppImage size significantly (from 140M to ~106M)

[jwr1]

I just created a test workflow, and the following line seems to work as expected:

container: ${{ matrix.target_os == 'linux' && 'ghcr.io/pkgforge-dev/archlinux:latest' || null }}

When the job was one of the two linux targets (x86 or arm), it used the Arch container, otherwise, it did not.

[psadi]

I just created a test workflow, and the following line seems to work as expected:

container: ${{ matrix.target_os == 'linux' && 'ghcr.io/pkgforge-dev/archlinux:latest' || null }}

When the job was one of the two linux targets (x86 or arm), it used the Arch container, otherwise, it did not.

Could you test by including windows and android runners as well and share the outcome (specifically looking if the steps ran within the defined runner)

[jwr1]

I just created a test workflow, and the following line seems to work as expected:

container: ${{ matrix.target_os == 'linux' && 'ghcr.io/pkgforge-dev/archlinux:latest' || null }}

When the job was one of the two linux targets (x86 or arm), it used the Arch container, otherwise, it did not.

Could you test by including windows and android runners as well and share the outcome (specifically looking if the steps ran within the defined runner)

I actually did that as well. Here's the full workflow I tested with, and all of the jobs succeded:

name: Build release

permissions:
  contents: write

on:
  workflow_dispatch:

jobs:
  build:
    name: Create ${{ matrix.target }} build
    runs-on: ${{ matrix.runner }}
    strategy:
      fail-fast: false
      matrix:
        include:
          - target: android
            target_os: android
            runner: ubuntu-latest
          - target: linux-x86_64
            target_os: linux
            target_arch: x86_64
            runner: ubuntu-24.04
          - target: linux-aarch64
            target_os: linux
            target_arch: aarch64
            runner: ubuntu-24.04-arm
          - target: windows-x86_64
            target_os: windows
            target_arch: x86_64
            runner: windows-latest
    container: ${{ matrix.target_os == 'linux' && 'ghcr.io/pkgforge-dev/archlinux:latest' || null }}
    steps:
      - name: "Hello ${{ matrix.target }}!" 
        run: echo "Hello ${{ matrix.target }}!"

After the first test, I added a pacman --version step in there, and the two linux jobs displayed the version, and the other two failed, as expected.

[psadi]

I've implemented the changes to the single job as you suggested. I've tested it and the logic is functioning correctly. This should make it easier for you to maintain in the future. Please take a look and share your thoughts.

P.S. Please squash the commits before merging! xD

[psadi]

Also, how does UPINFO work?

UPINFO is a metadata that can be included in an AppImage. It contains essential information about the application, such as its version, the GH repo info for updates & other relevant details. The zsyncmake tool here generates an additional .AppImage.zsync file that references the UPINFO file along with the AppImage format.

The main benefits here are,

1. Automatic Updates: Package managers that distribute AppImages, such as AM, AppImageUpdate etc, rely on this info to automate the update process.
2. Cross-Distribution Compatibility: As you might already know that one of the main advantages of AppImage is its design to work across various Linux distributions. The .AppImage.zsync file helps maintain this compatibility by allowing applications to manage their updates independently of the underlying system.

[jwr1]

Thanks for the update! I just have two quick questions.

[jwr1]

Thanks for the help, it looks great!

[jwr1]

I just ran a test release build, and the AppImages ended up having about a 40MB size reduction 🎉