Setting Up CI Integration

One of the most common points of frustration for Unreal teams is the gap between local builds and CI. A build passes on a developer machine and fails in the pipeline — or worse, the reverse. Gamibase closes this gap by running the same product model in both environments. The trust rules, evidence gates, and diagnostic behavior are identical whether you are in a terminal or in a GitHub Actions workflow.

When the diagnostic tool behaves differently in CI than it does locally, teams stop trusting the pipeline output. They spend time debugging the tool instead of the actual build issue. Gamibase avoids this by design — the CLI that runs on your machine is the same binary that runs in CI, with the same runtime, the same trust model, and the same output format.

• Same diagnostic classifications locally and in CI
• Same evidence gates and review-first posture
• Structured output that parses the same way in both environments
• No separate CI-specific configuration language to learn

Gamibase installs as a single binary. In CI, you add it to your pipeline setup step the same way you would install any CLI tool.

# GitHub Actions example
steps:
  - name: Install Gamibase
    run: |
      curl -fsSL https://get.gamibase.ai | sh
      gamibase --version

  - name: Build Unreal project
    run: |
      # Your existing build step
      RunUAT.bat BuildCookRun ... 2>&1 | tee build.log

  - name: Diagnose build failures
    if: failure()
    run: |
      gamibase doctor --log build.log --format json

In a terminal, Build Doctor output is designed for a human operator scanning findings. In CI, you often want structured output that can be parsed by downstream tools, posted as PR comments, or stored for trend analysis.

Gamibase supports both modes with the same underlying diagnosis. The --format flag controls the output shape without changing what gets diagnosed or how findings are ranked.

# Human-readable output (default)
gamibase doctor --log build.log

# JSON for machine consumption
gamibase doctor --log build.log --format json

# Pipe to your reporting tool
gamibase doctor --log build.log --format json | your-reporter

The same trust boundaries apply in CI. Diagnosis is read-only. Execution-level actions (build, cook, package) require explicit flags and follow the same review-first, fail-closed posture. There is no CI-specific mode that loosens the safety model for convenience.

Build Doctor is the most common CI entry point, but Gamibase offers more for teams that want deeper pipeline validation.

• Project structure validation — catch module dependency issues before they hit the build
• Config consistency checks — flag platform or target mismatches early
• Build parity analysis — compare local and CI build environments to surface drift
• Structured test result packaging — normalize test output for downstream consumption

Start by adding Build Doctor to your pipeline on the failure path. This gives you immediate value — structured diagnosis of every CI build failure — without changing your build process. Once you see the output, you can decide whether to expand into validation, parity checks, or deeper automation.