Add automated release builds and CI validation for Linux and macOS

[Copilot]

Implements GitHub Actions workflows to build and package SpriteLab for Linux (amd64) and macOS (arm64) on release publication, plus CI validation on pull requests.

Changes

• .github/workflows/release-builds.yml: Two-job workflow for platform-specific builds

  • Sets up Java 21 with GraalVM distribution
  • Uses graalvm/setup-graalvm@v1 for build environment
  • Downloads platform-specific FFmpeg static binaries (johnvansickle.com for Linux, evermeet.cx for macOS ARM64)
  • Uses staging directory pattern for artifact organization
  • Packages JAR + FFmpeg + launcher into tar.gz archives with platform-specific naming
  • Uploads to GitHub release assets via softprops/action-gh-release@v2
  • Explicit GITHUB_TOKEN permissions (contents: write)

• .github/workflows/ci-build.yml: CI workflow for pull request validation

  • Runs on pull requests and pushes to main/master branches
  • Validates builds on both Linux (amd64) and macOS (arm64)
  • Verifies JAR and FFmpeg binaries are created successfully
  • Uploads build artifacts for testing (7-day retention)
  • Uses read-only permissions for security
  • Triggers on changes to src/, pom.xml, or workflow files

• run.sh: Launch script with error checking for Java availability and JAR/FFmpeg presence

Build artifacts structure

staging/
├── SpriteLab-{linux-amd64,macos-arm64}.jar
├── bin/
│   └── ffmpeg
├── run.sh
├── README.md
└── LICENSE

Users extract the archive and execute ./run.sh to launch the application with bundled FFmpeg. The workflows follow GraalVM build patterns for consistent artifact handling across platforms.

The CI workflow ensures builds are tested before release, allowing verification of functionality before merging changes.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Release Build Actions</issue_title>
<issue_description>Let's add github actions to generate builds for OSX (arm64/metal) and Linux (amd64) on a release trigger.

Development (Build)

Language: Java 21 (JavaFX)
Dependencies: FFmpeg (Local binaries required in /bin)</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Release Build Actions #1

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[lmangani]

@copilot we want to build release binaries, ready to use.

Take this Action Java binary builder example as reference and adapt it to our goals, java version, etc.

name: GraalVM native-image build

on:
  push:
    paths:
      - "src/**"
      - "pom.xml"
      - ".github/workflows/graalVM.yml"

jobs:
  buildOnLinux:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: ayltai/setup-graalvm@v1
        with:
          java-version: 11
          graalvm-version: 21.3.0
          native-image: true
      - name: Build with Maven
        run: mvn -B clean package -Pnative --file pom.xml
      - name: Copy artifacts
        run: mkdir -p staging && cp target/log4j2-scanner staging/log4j2-scanner-linux-amd64 && cp target/*.jar staging
      - name: Upload artifacts
        uses: actions/upload-artifact@v2
        with:
          name: package
          path: staging/
      - name: Clean staging
        run: rm -fr staging

  buildOnMacOS:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v2
      - uses: ayltai/setup-graalvm@v1
        with:
          java-version: 11
          graalvm-version: 21.3.0
          native-image: true
      - name: Build with Maven
        run: mvn -B clean package -Pnative --file pom.xml
      - name: Copy artifacts
        run: mkdir -p staging && cp target/log4j2-scanner staging/log4j2-scanner-mac-amd64
      - name: Upload artifacts
        uses: actions/upload-artifact@v2
        with:
          name: package
          path: staging
      - name: Clean staging
        run: rm -fr staging

  buildOnWindows:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v2
      - uses: ilammy/msvc-dev-cmd@v1.5.0
      - uses: microsoft/setup-msbuild@v1
      - uses: ayltai/setup-graalvm@v1
        with:
          java-version: 11
          graalvm-version: 21.3.0
          native-image: true
      - name: Build with Maven
        run: mvn -B clean package -Pnative --file pom.xml
        shell: powershell
      - name: Copy artifacts
        run: cp target/log4j2-scanner.exe log4j2-scanner-win-amd64.exe
      - name: Upload artifacts
        uses: actions/upload-artifact@v2
        with:
          if-no-files-found: warn
          name: package
          path: target/*.exe
          ```

[Copilot]

@copilot we want to build release binaries, ready to use.

Take this Action Java binary builder example as reference and adapt it to our goals, java version, etc.
...

Updated the workflow to follow the GraalVM pattern from your reference example. Changes in commit b4725ac:

• Switched from Temurin to GraalVM distribution with Java 21
• Adopted the staging directory pattern for artifact organization
• Renamed JARs with platform suffixes (SpriteLab-linux-amd64.jar, SpriteLab-macos-arm64.jar)
• Simplified packaging to match the reference structure
• Maintained FFmpeg bundling in staging/bin directory
• Kept explicit permissions and HTTPS downloads for security

The workflow now uses graalvm/setup-graalvm@v1 and follows the same artifact handling pattern as your reference.

[lmangani]

@copilot lets add some CI actions to make sure our builds actually work before release on PRs such as this one

[Copilot]

@copilot lets add some CI actions to make sure our builds actually work before release on PRs such as this one

Added CI workflow in commit 9d3684b. The new .github/workflows/ci-build.yml workflow:

• Runs on pull requests and pushes to main/master branches
• Validates builds on both Linux (amd64) and macOS (arm64)
• Verifies JAR and FFmpeg binaries are created successfully
• Uploads build artifacts for testing (7-day retention)
• Uses read-only permissions for security
• Triggers on changes to src/, pom.xml, or workflow files

This ensures builds are tested before release, and you can download the artifacts from PR checks to verify functionality.