Game Ci Cd Pipeline

Game CI/CD Pipeline

Use this skill when the job is choosing the next game-pipeline artifact, not dumping a generic DevOps essay.

game-ci-cd-pipeline should answer two linked questions per run: 1. Which signal tier / promotion lane is this?

• branch-gate — fast merge/commit validation
• nightly-package-candidate — slower scheduled or manually triggered QA/review candidate builds
• release-certification-candidate — protected, signed, approval-heavy release or cert candidates

2. Which packet is the smallest honest next artifact inside that tier?

• pipeline setup
• stage split
• cache policy
• preflight readiness
• artifact/release hygiene
• CI-signal hardening
• or route-to-log-triage

Read these before choosing the packet:

• references/intake-packets-and-route-outs.md
• references/pipeline-patterns.md
• references/signal-tiers-and-promotion-lanes.md

When to use this skill

• A Unity or Unreal team needs to set up CI/CD from scratch without overengineering it.
• A pipeline is repeatedly flaky, slow, or opaque, and the real problem is workflow structure rather than one isolated log.
• Build, cook/package, cache, artifact, or release-hand-off steps keep breaking trust in the pipeline.
• A team still ships demo/review/release builds manually and needs the first reproducible pipeline packet.
• A publisher helper, contractor, or technical lead needs a compact game-pipeline audit brief.

When not to use this skill

• The main job is identifying the first actionable failure inside one specific Unity/Unreal build log → game-build-log-triage.
• The main job is milestone coordination across design, QA, build pressure, and launch timing → bmad-gds.
• The main job is runtime profiling or frame-time bottleneck diagnosis → game-performance-profiler.
• The main job is Steam page / wishlist / launch-store operations → steam-store-launch-ops.
• The main job is generic non-game CI/CD for ordinary web/backend repos → use the repo's broader DevOps skills instead.

Instructions

Step 1: Classify the signal tier first, then choose one primary packet type

Normalize the request into exactly one signal tier and one primary packet.

game_pipeline_packet:
  signal_tier: branch-gate | nightly-package-candidate | release-certification-candidate | unknown
  packet_type: pipeline-setup | stage-split | cache-policy | preflight-readiness | artifact-release | ci-signal-hardening | route-to-log-triage
  engine: Unity | Unreal | mixed | unknown
  ci_surface: GitHub Actions | Unity Build Automation | Jenkins | TeamCity | other | unknown
  target_platforms: Windows | macOS | Linux | Android | iOS | console | mixed | unknown
  release_context: prototype | internal QA | demo | playtest | certification | launch | live patch | unknown
  evidence_level: strong | partial | thin

Signal-tier meanings:

• branch-gate — fast merge/commit validation where expensive packaging should stay exceptional
• nightly-package-candidate — scheduled or manually triggered QA/review/demo candidate builds that are heavier than ordinary branch CI
• release-certification-candidate — protected, approval-heavy, signed, store-bound, or cert-bound candidate work

Packet meanings:

• pipeline-setup — first reproducible pipeline plan for a team still doing too much by hand
• stage-split — separate restore/build/test/cook/package/publish so the first failing stage is visible
• cache-policy — stop superstition around Library, Intermediate, Saved, DDC, or package caches
• preflight-readiness — surface SDK/signing/toolchain/platform prerequisites before expensive packaging
• artifact-release — fix artifact naming, retention, candidate-vs-release clarity, and QA handoff
• ci-signal-hardening — improve feedback speed and trust without rewriting everything
• route-to-log-triage — the request is mostly one red build/log and should move to game-build-log-triage

Step 2: Gather the minimum credible evidence

Pull only the smallest packet needed to justify the decision:

• engine and version if known
• current CI surface or workflow file
• current trigger shape: PR/push, schedule/manual, protected release lane, or unknown
• target platforms and release context
• repeated failure pattern: compile, package, toolchain, cache, artifact confusion, speed, or trust
• what still happens manually after CI finishes
• current artifact naming / retention or approval rules if candidate promotion is part of the pain
• one recent failing job/log if the team keeps pointing at a single red build

If evidence is thin, keep confidence low and prefer route-to-log-triage or a narrow packet over a fake full redesign.

Step 3: Choose the signal tier explicitly

Decide which lane owns the pain before suggesting the packet:

• `branch-gate` when the complaint is slow PR/merge validation, heavy packaging on every branch, or weak fast feedback
• `nightly-package-candidate` when QA/review/demo builds need heavier packaging, broader target coverage, or scheduled/manual promotion outside normal branch CI
• `release-certification-candidate` when the work is approval-heavy, signed, store/cert-bound, or should have stricter artifact retention than ordinary CI
• `unknown` only when the available evidence cannot distinguish the lane yet

If the user mixes multiple lanes, pick the lane that is currently bottlenecking trust and name the others as follow-up route-outs.

Step 4: Classify the primary blocker

Choose one primary blocker and at most one secondary blocker.

Primary blockers

• reproducibility-drift
• stage-boundary-blur
• dependency-cache-policy
• artifact-release-hygiene
• platform-toolchain-readiness
• feedback-speed-confidence
• single-log-not-pipeline
• unknown-needs-more-evidence

Typical mappings:

• "Works on one machine but not in CI" → reproducibility-drift
• "Our workflow is one giant job and we cannot tell what failed" → stage-boundary-blur
• "We keep deleting caches until it passes" → dependency-cache-policy
• "QA never knows which build is correct" → artifact-release-hygiene
• "Android/iOS/console packaging fails late" → platform-toolchain-readiness
• "Builds are slow and nobody trusts the signal" → feedback-speed-confidence
• "Here is one failing packaging log" → single-log-not-pipeline

Step 5: Run the boundary check

Before writing advice, verify the lane: 1. Is this a structural pipeline question or just a failing log? 2. Does the chosen signal tier match the actual trigger/approval/artifact problem? 3. Is the best next artifact one of the packet types above? 4. Are you staying inside game-engine pipeline work instead of drifting into generic web-app DevOps? 5. Are engine-specific details helping the diagnosis rather than bloating the front door?

If the answer is mostly "this is one failing log", route to game-build-log-triage and leave a short handoff packet. If the answer is mostly "this is really release-gate policy", route the policy decision to testing-strategies and keep this skill on game-engine implementation shape.

Step 6: Build the packet brief

Return this exact structure:

# Game CI/CD Brief

## Packet choice
- Signal tier: branch-gate | nightly-package-candidate | release-certification-candidate | unknown
- Packet type: ...
- Engine: ...
- CI surface: ...
- Release context: ...
- Confidence: high | medium | low

## Evidence used
- Workflow / system context: ...
- Repeated failure pattern: ...
- Manual steps still outside CI: ...
- Gaps / assumptions: ...

## Primary blocker
- Bucket: ...
- Why it matters now: ...
- Evidence: ...

## Secondary blocker
- Bucket: ...
- Why it matters now: ...

## Recommended pipeline shape
1. ...
2. ...
3. ...

## Engine and platform checks
- Unity / Unreal specifics: ...
- SDK / signing / toolchain: ...
- Cache or artifact policy: ...

## Recommended next artifact
- Choose one: pipeline setup plan | workflow stage split brief | cache-key policy | platform preflight checklist | artifact/release checklist | CI-signal hardening plan | log-triage handoff packet

## Route-outs
- Skill: ...
- Why: ...
- Packet to pass: ...

## What not to do yet
- 1-3 bullets that avoid brittle rewrites or cargo-cult caching

Step 7: Tailor the packet to the engine and signal tier

For Unity

• watch engine/editor version pinning
• ask whether Packages/manifest.json / lock inputs and platform modules are stable
• separate package restore, build, test, and package stages
• treat Library/ and package caches as explicit policy, not ritual cleanup
• for branch-gate, bias toward fast compile/test/smoke feedback and cancel-in-progress behavior
• for nightly-package-candidate or release-certification-candidate, make candidate naming, build-target grouping, signing, and artifact retention explicit

For Unreal

• keep UBT/UHT, cook, package, and publish mentally separate
• call out plugin/module drift, asset redirect fallout, and AutomationTool visibility
• distinguish DDC/cache questions from packaging/log-root-cause work
• make platform packaging prerequisites visible before late-stage failure
• for branch-gate, avoid hiding every merge behind full cook/package unless the project risk truly requires it
• for nightly-package-candidate or release-certification-candidate, make cook/package duration, target-specific prerequisites, and publish/promotion rules explicit

Step 8: Ask for the smallest missing packet

If confidence is low, request only what changes the decision: 1. current workflow file or job outline 2. trigger shape (PR/push vs schedule/manual vs protected release lane) 3. engine version and target platforms 4. one recent failed job/log if the issue may be single-log-not-pipeline 5. current artifact naming / retention / approval pattern 6. what still happens manually after CI completes

Output format

Always return a short game pipeline brief.

Required qualities:

• choose one signal tier and one primary packet type
• separate structural pipeline work from one-off log triage
• recommend one next artifact, not a full platform rewrite
• stay around 300-550 words unless the user asks for more
• keep release/demo context visible when it changes the priority
• make candidate promotion / approval truth explicit when it changes the answer

Examples

Example 1: Unity cache superstition

Input

Our Unity GitHub Actions build passes locally but fails after package updates. We keep deleting caches and rerunning until it works.

Good output direction

• packet type: cache-policy
• primary blocker: dependency-cache-policy
• secondary blocker: reproducibility-drift
• next artifact: cache-key policy
• route-out remains optional unless one specific log becomes the real question

Example 2: Heavy packaging on every branch

Input

Our PR pipeline takes 70 minutes because Android packaging runs on every branch. What should change first?

Good output direction

• signal tier: branch-gate
• packet type: ci-signal-hardening or stage-split
• primary blocker: feedback-speed-confidence
• next artifact: CI-signal hardening plan or workflow stage split brief
• call out that full packaging likely belongs in a heavier candidate lane, not every merge gate

Example 3: Unreal giant job blob

Input

We have an Unreal pipeline but packaging takes forever and failures show up as one giant log blob.

Good output direction

• signal tier: usually nightly-package-candidate unless the user proves every merge truly needs full packaging
• packet type: stage-split
• primary blocker: stage-boundary-blur
• secondary blocker: feedback-speed-confidence
• next artifact: workflow stage split brief

Example 4: One failing packaging log

Input

Our Unreal Android packaging job failed last night. Here's the AutomationTool output.

Good output direction

• packet type: route-to-log-triage
• primary blocker: single-log-not-pipeline
• route to game-build-log-triage
• pass along the failing stage, engine version, target platform, and exact log excerpt

Example 5: Manual nightly/demo candidate process

Input

We already have a quick branch build, but QA needs a nightly Windows + Steam Deck candidate with clear artifact names.

Good output direction

• signal tier: nightly-package-candidate
• packet type: artifact-release or pipeline-setup
• primary blocker: artifact-release-hygiene
• next artifact: artifact/release checklist or pipeline setup plan
• keep candidate naming, retention, and consumer handoff explicit

Best practices

1. Name the signal tier before the packet — branch-gate, nightly/package-candidate, and release/certification work should not share one fake default answer. 2. Act like a release engineer, not a generic infra lecturer — choose the next packet that reduces repeat pain. 3. Preserve the log/pipeline boundary — one red build often needs game-build-log-triage before a structural rewrite. 4. Treat caches as policy — define what is keyed, shared, invalidated, and intentionally regenerated. 5. Expose stage boundaries — compile, test, cook/package, and publish should not collapse into one unreadable blob. 6. Keep release context visible — prototype, demo, certification, and launch demand different tradeoffs. 7. Prefer one next artifact over a sprawling CI/CD manifesto. 8. Route release-gate policy to `testing-strategies` when the fight is governance, not engine-pipeline shape.

References

• references/intake-packets-and-route-outs.md
• references/pipeline-patterns.md
• references/signal-tiers-and-promotion-lanes.md
• Unity Docs — Troubleshoot common issues • Build Automation • Unity Docs
• Unity Scriptable Build Pipeline — Cache Server Client
• Epic Docs — Packaging Your Project
• Epic Docs — Logging in Unreal Engine

Game CI/CD intake packets and route-outs

Use this reference to keep game-ci-cd-pipeline compact and routing-first. Start by naming the signal tier (branch-gate, nightly-package-candidate, or release-certification-candidate), then choose the packet type.

Signal tiers

branch-gate

Fast merge/commit validation. Use when the pain is slow PR feedback, packaging on every branch, or weak developer trust in quick CI.

nightly-package-candidate

Heavier scheduled/manual QA, demo, or review builds. Use when candidate packaging should exist, but not on every merge.

release-certification-candidate

Protected, signed, store-bound, or certification-bound candidates. Use when approval, retention, or promotion rules are part of the pain.

Primary packet types

1. pipeline-setup

Use when the team still builds demo, QA, or release candidates mostly by hand.

Minimum packet:

• engine + version
• target platforms
• current manual build/release steps
• release context (prototype, demo, launch, patch)
• where artifacts currently go

Best next artifact:

• pipeline setup plan

2. stage-split

Use when the workflow is one giant job blob and nobody can name the first failing stage.

Minimum packet:

• workflow file or job outline
• where compile/test/cook/package/publish currently happen
• one recent failed job URL or excerpt
• current artifact/log visibility

Best next artifact:

• workflow stage split brief

3. cache-policy

Use when the team keeps deleting caches or cannot explain cache keys.

Minimum packet:

• engine + version
• what is cached now (Library, DDC, package caches, intermediate folders)
• cache invalidation rules if any
• failure symptoms after cache reuse

Best next artifact:

• cache-key policy

4. preflight-readiness

Use when SDK, signing, provisioning, or platform setup fails late.

Minimum packet:

• target platform
• toolchain / SDK / signing prerequisites
• stage where failure is discovered now
• whether prerequisites are checked before packaging

Best next artifact:

• platform preflight checklist

5. artifact-release

Use when builds exist but QA/review/publish handoff is messy.

Minimum packet:

• artifact names and destinations
• branch/channel naming
• retention window
• who consumes the outputs

Best next artifact:

• artifact/release checklist

6. ci-signal-hardening

Use when builds are slow, expensive, and still not trusted.

Minimum packet:

• current runtime per stage
• earliest useful tests/smoke checks
• which failures should block packaging
• where confidence is currently lost

Best next artifact:

• CI-signal hardening plan

Route-outs

Route to game-build-log-triage

Use when the main question is the first actionable error inside one failing Unity/Unreal build, cook, package, CI, or editor log.

Pass this packet:

• engine + version
• target platform
• exact failing stage
• shortest useful log excerpt or job URL
• any recent change that likely triggered the failure

Route to bmad-gds

Use when build automation is only one piece of a broader milestone / demo / launch coordination decision.

Route to game-performance-profiler

Use when the build completes but the real problem is frame time, memory, hitching, or target-device performance.

Route to steam-store-launch-ops

Use when the team is really asking about Steam page, demo timing, or public launch operations rather than build automation.

Boundary reminder

game-ci-cd-pipeline owns repeated structural pipeline decisions. It should not become a general-purpose log debugger or a whole-studio producer/orchestrator.

Game CI/CD Pipeline Patterns

Use this reference when the request is broader than one red build and narrower than a full platform migration.

Core distinction

• `game-build-log-triage`: identify the first actionable failure from a specific log excerpt.
• `game-ci-cd-pipeline`: redesign or audit the pipeline so repeated failures become visible, reproducible, and less frequent.

Five recurring game-pipeline pain patterns

1. One giant job blob

Symptoms:

• one workflow step does restore, compile, test, package, upload, and release prep
• the user says "CI failed" but cannot name the first failing stage
• the log is huge and the real error is buried near the middle

Recommended response:

• split jobs or at least clearly named stages
• preserve stage-specific artifacts/logs
• make later steps depend on earlier red/green gates

2. Cache superstition

Symptoms:

• the team repeatedly deletes Library/, Intermediate/, Saved/, or equivalent caches
• success depends on random cleanup rather than explicit keys or invalidation rules
• teams cannot tell what is safe to cache vs regenerate

Recommended response:

• describe cache scope in terms of engine version, dependency manifest, target platform, and build configuration
• distinguish package/dependency caches from generated build-state caches
• avoid recommending broad cache deletion as the steady-state workflow

3. Platform prerequisites discovered too late

Symptoms:

• packaging fails only after a long build/cook step
• Android/iOS/signing/toolchain issues surface at the end of the workflow
• environment assumptions live in one developer machine rather than CI checks

Recommended response:

• add explicit preflight verification for platform SDK, signing, provisioning, and build tools
• make platform readiness a named stage, not an implicit assumption

4. Artifact ambiguity

Symptoms:

• QA or publishers do not know which build to test
• branch/config/platform are unclear from filenames
• successful builds disappear too quickly or are overwritten

Recommended response:

• define an artifact naming convention with branch/channel, platform, configuration, and revision
• set retention expectations for QA/review builds
• separate candidate builds from shippable release artifacts

5. Slow pipelines nobody trusts

Symptoms:

• builds are expensive and still miss obvious regressions
• teams skip CI because feedback is too slow
• the pipeline is optimized for build completion, not decision confidence

Recommended response:

• keep the earliest confidence-building checks small and fast
• decide which tests or smoke checks should run before expensive packaging
• focus on the signal needed to unblock the team, not just maximum automation

Engine-specific reminders

Unity

• Ask about engine version, packages, lockfiles, platform modules, and whether editor-only code leaks into builds.
• Packaging failures often hide earlier compile/package-manager issues.
• Editor.log and package-manager logs are evidence sources, not the pipeline plan itself.

Unreal

• Keep UBT/UHT, cook, package, and artifact stages mentally separate.
• Missing assets, redirectors, or plugin/module drift often explode during later packaging steps.
• AutomationTool output is frequently a downstream symptom; stage boundaries matter.

Good next artifacts

• workflow rewrite brief
• cache-key policy
• build matrix plan
• release artifact checklist
• platform preflight checklist

Prefer one of those over a generic "improve CI" answer.

Signal tiers and promotion lanes

Use this reference when game-ci-cd-pipeline needs to say which lane owns the current pain before choosing the packet.

1. branch-gate

Use when the question is about fast merge/commit validation.

Typical signs:

• PR or push builds are too slow
• full Android/iOS/console packaging runs on every branch
• developers do not trust CI because the feedback arrives too late
• the team needs a cheaper compile/test/smoke lane before heavier packaging

Bias toward:

• ci-signal-hardening
• stage-split
• sometimes cache-policy

Anti-pattern:

• treating every merge like a release candidate just because packaging exists

2. nightly-package-candidate

Use when the team needs heavier QA/review/demo builds that should not block every merge.

Typical signs:

• scheduled or manually triggered packaging
• nightly Windows/macOS/Steam Deck or multi-platform candidate builds
• QA/review teams need clearer artifact names, retention, and handoff rules
• broader target coverage is desired, but only after fast branch CI passes

Bias toward:

• artifact-release
• pipeline-setup
• stage-split
• preflight-readiness

Anti-pattern:

• hiding nightly/demo candidate work inside the same branch gate and calling it "CI trust"

3. release-certification-candidate

Use when the team is dealing with signed, approval-heavy, store-bound, or certification-bound candidates.

Typical signs:

• stricter approvals or protected environments
• signing/provisioning/publisher requirements
• console/store/cert packaging with long retention and explicit promotion rules
• the branch/nightly lane already exists, but release-candidate truth is still manual

Bias toward:

• artifact-release
• preflight-readiness
• pipeline-setup

Route-outs:

• testing-strategies when the real argument is which checks block promotion
• steam-store-launch-ops when the remaining work is public launch/store readiness rather than engine pipeline mechanics

Lane-selection checklist

1. What triggers this lane now — PR/push, schedule/manual, or protected release flow? 2. Who consumes the output — developers, QA/review, publishing/release, or certification stakeholders? 3. Which outputs need the longest retention or strictest naming? 4. Which failures are allowed to be slow, and which must stay fast? 5. Which parts still happen manually after CI finishes?

Durable rule

Choose the signal tier first. Then choose the smallest honest packet inside that tier.