How to Set Up Automated Build Testing for Your Game

You merge a feature branch, push to main, and discover two days later that the build is broken on Windows. Nobody noticed because the team develops on Mac. Automated build testing catches these problems within minutes of every commit, and for game projects — where builds are slow, platforms are diverse, and regressions are easy to introduce — it’s one of the highest-value investments a team can make.

Why Game Build Testing Is Different

Game projects present unique challenges for CI/CD that web and mobile developers rarely encounter. Build times are measured in tens of minutes, not seconds. The output binary needs a GPU to run properly. Asset processing (texture compression, shader compilation, lightmap baking) can dominate build time. And you’re often targeting multiple platforms from a single codebase.

Cloud CI runners like GitHub’s hosted runners or GitLab’s shared runners struggle with game builds. They typically have limited disk space (14 GB on GitHub), no GPU, and the engine itself isn’t installed — meaning you’d need to download and install Unity or Unreal on every run. This is why self-hosted runners are the standard approach for game teams.

The investment is a dedicated machine (or a VM on your existing hardware) with the engine installed, enough disk space for your project, and a CI runner agent. The payoff is builds that complete in minutes instead of hours, with the full engine toolchain available for validation.

Setting Up the Pipeline

Start with the simplest possible pipeline: build the project and verify the output exists. Here’s a GitHub Actions workflow for a Unity project using a self-hosted runner:

# .github/workflows/build-test.yml
name: Build Test
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-windows:
    runs-on: self-hosted
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4
        with:
          lfs: true

      - name: Build Windows Player
        run: |
          "C:\Program Files\Unity\Hub\Editor\2022.3.20f1\Editor\Unity.exe" \
            -batchmode -nographics -quit \
            -projectPath "${{ github.workspace }}" \
            -buildTarget Win64 \
            -buildWindows64Player "Build/MyGame.exe" \
            -logFile build.log
        shell: bash

      - name: Validate build output
        run: |
          if [ ! -f "Build/MyGame.exe" ]; then
            echo "ERROR: Build output not found"
            cat build.log | tail -50
            exit 1
          fi
          echo "Build output verified: $(ls -la Build/MyGame.exe)"

      - name: Check for errors in build log
        run: |
          if grep -i "error CS" build.log; then
            echo "Compilation errors found in build log"
            exit 1
          fi
          echo "No compilation errors found"

      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        if: success()
        with:
          name: windows-build
          path: Build/
          retention-days: 7

For Godot projects, the equivalent is simpler since Godot’s CLI is more lightweight:

      - name: Export Windows build
        run: |
          godot --headless --export-release "Windows Desktop" \
            Build/MyGame.exe

      - name: Export Linux build
        run: |
          godot --headless --export-release "Linux/X11" \
            Build/MyGame.x86_64

For Unreal projects, use RunUAT (Unreal Automation Tool):

      - name: Build and cook
        run: |
          Engine/Build/BatchFiles/RunUAT.sh BuildCookRun \
            -project="$GITHUB_WORKSPACE/MyGame.uproject" \
            -platform=Win64 -clientconfig=Development \
            -build -cook -stage -pak -archive \
            -archivedirectory="$GITHUB_WORKSPACE/Build"

Adding Smoke Tests

A build that compiles isn’t necessarily a build that works. Smoke tests verify that the game actually launches, loads its critical scenes, and doesn’t crash during the first few seconds of execution. These are intentionally shallow — they’re not testing gameplay, just ensuring nothing is catastrophically broken.

The approach varies by engine, but the pattern is the same: launch the game in a test mode, load key scenes, wait a few seconds, check for crashes or error logs, and exit.

Unity smoke test script:

// Assets/Tests/SmokeTest.cs
using UnityEngine;
using UnityEngine.SceneManagement;
using System.Collections;

public class SmokeTest : MonoBehaviour
{
    string[] criticalScenes = { "MainMenu", "Level1", "Level2" };

    IEnumerator Start()
    {
        foreach (var sceneName in criticalScenes)
        {
            Debug.Log($"[SMOKE] Loading scene: {sceneName}");
            var op = SceneManager.LoadSceneAsync(sceneName);
            yield return op;

            // Wait 3 seconds for initialization
            yield return new WaitForSeconds(3f);

            if (SceneManager.GetActiveScene().name != sceneName)
            {
                Debug.LogError($"[SMOKE] FAIL: Scene {sceneName} did not load");
                Application.Quit(1);
                yield break;
            }
            Debug.Log($"[SMOKE] PASS: Scene {sceneName} loaded successfully");
        }

        Debug.Log("[SMOKE] All smoke tests passed");
        Application.Quit(0);
    }
}

Godot smoke test script:

# tests/smoke_test.gd
extends Node

var scenes_to_test = [
    "res://scenes/main_menu.tscn",
    "res://scenes/level_01.tscn",
    "res://scenes/level_02.tscn"
]

func _ready():
    for scene_path in scenes_to_test:
        print("[SMOKE] Loading: ", scene_path)
        var err = get_tree().change_scene_to_file(scene_path)
        if err != OK:
            printerr("[SMOKE] FAIL: Could not load ", scene_path)
            get_tree().quit(1)
            return
        await get_tree().create_timer(3.0).timeout
        print("[SMOKE] PASS: ", scene_path)

    print("[SMOKE] All smoke tests passed")
    get_tree().quit(0)

In your CI pipeline, run the smoke test with a timeout and check the exit code:

      - name: Run smoke tests
        timeout-minutes: 5
        run: |
          ./Build/MyGame.exe --smoke-test || {
            echo "Smoke test failed"
            exit 1
          }

Multi-Platform Validation

If you ship on multiple platforms, you need to validate builds for each one. This doesn’t mean you need a Mac, a PC, and a Linux box — most engines can cross-compile. But you do need to verify the output for each platform.

A practical multi-platform strategy for small teams:

• Every commit: Build and smoke test the primary development platform (fast, under 10 minutes).
• Nightly: Build all target platforms, run extended smoke tests, check asset validation.
• Pre-release: Full build, smoke test, asset audit, file size check, and deploy to a staging environment for manual testing.

This tiered approach gives fast feedback on every commit without burning an hour of build time for every typo fix. Use Git branch protection rules to require the fast pipeline to pass before merging.

Notifications and Build Visibility

A build pipeline nobody checks is a build pipeline nobody uses. Send build results to where your team already communicates:

      - name: Notify Discord
        if: always()
        run: |
          STATUS="${{ job.status }}"
          COLOR=$([[ "$STATUS" == "success" ]] && echo "3066993" || echo "15158332")
          curl -X POST "${{ secrets.DISCORD_WEBHOOK }}" \
            -H "Content-Type: application/json" \
            -d "{
              \"embeds\": [{
                \"title\": \"Build $STATUS\",
                \"description\": \"${{ github.event.head_commit.message }}\",
                \"color\": $COLOR,
                \"fields\": [
                  {\"name\": \"Branch\", \"value\": \"${{ github.ref_name }}\", \"inline\": true},
                  {\"name\": \"Commit\", \"value\": \"${{ github.sha }}\", \"inline\": true}
                ]
              }]
            }"

Post a red alert for failures and a quiet green checkmark for successes. Consider adding build badges to your repository README so the team can see build status at a glance. Over time, a culture of “never leave the build broken” develops naturally when build status is visible to everyone.

If you’re using Bugnet for your project, you can also feed build failure data into your bug tracking workflow — automatically creating bug reports for build failures that include the commit hash, build log, and the specific error that triggered the failure. This creates a paper trail that connects code changes to build problems.

The best time to set up automated builds is before you need them. The second best time is right after a broken build costs you a day.