Native Linux build (AppImage, x86_64) -- GitHub Actions#4990
Open
DoubyCz wants to merge 1 commit into
Open
Conversation
Adds a mechanism to produce a portable KeeperFX AppImage for x86_64 Linux via GitHub Actions. The build runs in a Debian 12 container (glibc 2.36 + ffmpeg 5.1) for broad distro compatibility, builds a pinned modern SDL2 from source (Debian 12 ships 2.26 with broken Wayland fullscreen), compiles the native engine via linux.mk, bundles all libraries with linuxdeploy and the freely-redistributable KeeperFX data, and packages it with appimagetool. Robustness: - SDL2 pinned to a fixed release tag (reproducible; not the rolling branch). - Bundled free-data version defaults to this tree's version.mk, so data always matches the engine; a tree ahead of any release fails early with a clear hint to set KFX_DATA_VERSION. - Downloaded data is verified against the sha256 digest from the GitHub release API (mismatch fails the build). The AppImage never contains the original Dungeon Keeper files (copyright EA/Bullfrog); the user supplies those at runtime via the AppRun launcher, which also deploys the bundled free data into the game folder on first launch. Triggering (documented in the workflow header): 'workflow_dispatch' uploads a build artifact; pushing an 'appimage-*' tag also publishes a GitHub Release. The release step needs 'Read and write permissions' under the repo's Actions settings.
DoubyCz
changed the title
DoubyCz
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a GitHub Actions workflow that builds and publishes a portable KeeperFX AppImage for x86_64 Linux - a single file that Linux players can download and run directly, with no dependencies to install.
#4962 got the native Linux build compiling cleanly on modern toolchains. This PR takes that working build and packages it into a downloadable, ready-to-run AppImage.
You can test AppImages in forked repo:
Proposed changes:
How the AppImage works:
A couple of things I was careful about:
Enabling the workflow:
Merging this is inert on its own: the workflow only triggers on a manual run or an appimage-* tag, never on a normal push or pull request, so nothing runs and nothing changes until you choose to. There are two ways to produce an AppImage, both starting the Debian 12 build described above:
The Release step needs "Read and write permissions" under Settings -> Actions -> General; the artifact-only path doesn't. This is spelled out in the workflow header too.
I've tested the whole thing end to end against current master: it produces a working KeeperFX-1.4.0 AppImage that starts up with the bundled SDL and only stops (as expected) once it starts looking for the original game data.
One known issue, deliberately left out of this PR:
On some multi-monitor setups the startup splash/legal screens can come up undersized in a corner instead of filling the screen. I'm aware of it and have a small engine-side fix ready, but I'd rather send that as its own separate PR so this one stays purely about the AppImage packaging - I didn't want to mix an engine behavior change into the build tooling.
Open to any feedback.