Safe Automation for Unreal Builds

Build automation for Unreal projects carries real risk. A misconfigured cook, an unreviewed packaging step, or a test run against the wrong target can waste hours of machine time or ship a broken artifact. The problem is not automation itself — it is automation that hides its operating rules from the people who need to trust it.

Most automation tools optimize for convenience. They run commands, chain steps, and report results. What they rarely make visible is the execution posture — whether a step is read-only, dry-run, or fully committed. When teams cannot see this distinction, they either avoid automation entirely or learn its limits through expensive failures.

Gamibase treats execution mode as part of the workflow, not a flag you remember to pass. Every command that can modify state has an explicit posture: read-only, dry-run, or execute. The default is always the safest option. Moving to a higher-impact mode requires deliberate intent.

# Dry-run a build — validates without executing
gamibase build --target MyGame --platform Win64 --dry-run

# Preflight checks before cooking
gamibase cook --target MyGame --preflight

# Full execution with explicit intent
gamibase build --target MyGame --platform Win64 --execute

Before a build, cook, or package step runs, preflight checks validate the preconditions. Is the target configuration consistent? Are the expected modules present? Does the build environment match what CI expects? These checks catch the class of errors that waste the most time — the ones where the build runs for twenty minutes before failing on something that was knowable up front.

When a preflight check fails, or when evidence is stale, or when an approval is missing — Gamibase stops. It does not proceed with a warning. It does not log the issue and continue. It fails closed. This is the single most important safety property in the automation model: when in doubt, do nothing and explain why.

Some automation steps are higher-impact than others. Packaging a build for submission is different from running a local compile check. Gamibase uses review gates to keep these transitions visible — the operator sees what is about to happen, reviews the evidence, and explicitly approves before the workflow advances.

The automation model does not change in CI. The same dry-run, preflight, and fail-closed behavior applies whether you are running commands in a terminal or in a GitHub Actions workflow. There is no CI-specific bypass mode. If a step requires review locally, it requires review in the pipeline.