game-ci-cd-pipeline

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Game CI/CD Pipeline

游戏CI/CD流水线

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:

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
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

当任务是选择下一个游戏流水线制品，而非撰写通用DevOps文章时，使用本技能。

game-ci-cd-pipeline

每次运行需回答两个关联问题：

当前属于哪个信号层级/晋升通道？
- ```
branch-gate
```
  —— 快速合并/提交验证
- ```
nightly-package-candidate
```
  —— 较慢的定时或手动触发的QA/评审候选构建
- ```
release-certification-candidate
```
  —— 受保护、需签名、审批严格的发布或认证候选版本
该层级内最小且务实的下一个制品是什么？
- 流水线搭建
- 阶段拆分
- 缓存策略
- 预检查就绪
- 制品/发布规范
- CI信号强化
- 或路由至日志诊断

选择制品前请阅读以下文档：

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.

Unity或Unreal团队需要从零搭建CI/CD，且避免过度设计
流水线反复出现不稳定、缓慢或不透明问题，核心原因是工作流结构而非单一孤立日志
构建、打包/编译、缓存、制品或发布交接步骤持续破坏团队对流水线的信任
团队仍手动交付演示/评审/发布版本，需要首个可复现的流水线制品
发行商助手、承包商或技术负责人需要一份简洁的游戏流水线审计简报

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.

核心任务是定位某一特定Unity/Unreal构建日志中的首个可操作故障 → 使用
```
game-build-log-triage
```
核心任务是跨设计、QA、构建压力和发布时间的里程碑协调 → 使用
```
bmad-gds
```
核心任务是运行时性能分析或帧时间瓶颈诊断 → 使用
```
game-performance-profiler
```
核心任务是Steam页面/愿望单/发布商店运营 → 使用
```
steam-store-launch-ops
```
核心任务是普通Web/后端仓库的通用非游戏CI/CD → 使用仓库对应的通用DevOps技能

Instructions

操作步骤

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

步骤1：先分类信号层级，再选择一个主要制品类型

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

yaml

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
```

将请求标准化为恰好一个信号层级和一个主要制品。

yaml

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

信号层级含义：

```
branch-gate
```
—— 快速合并/提交验证，应避免频繁执行高成本打包操作
```
nightly-package-candidate
```
—— 定时或手动触发的QA/评审/演示候选构建，比普通分支CI更繁重
```
release-certification-candidate
```
—— 受保护、审批严格、已签名、面向商店或认证的候选版本工作

制品含义：

```
pipeline-setup
```
—— 为仍大量依赖手动操作的团队制定首个可复现流水线方案
```
stage-split
```
—— 将恢复/构建/测试/编译/打包/发布步骤分离，便于快速定位首个失败阶段
```
cache-policy
```
—— 终结围绕
```
Library
```
、
```
Intermediate
```
、
```
Saved
```
、DDC或包缓存的盲目操作
```
preflight-readiness
```
—— 在执行高成本打包前，提前暴露SDK/签名/工具链/平台的前置要求
```
artifact-release
```
—— 修复制品命名、留存规则、候选版与正式版区分度，以及QA交接流程
```
ci-signal-hardening
```
—— 在不重写整个系统的前提下，提升反馈速度和信任度
```
route-to-log-triage
```
—— 请求主要围绕单个失败构建/日志，应转至
```
game-build-log-triage
```
处理

Step 2: Gather the minimum credible evidence

步骤2：收集最少的可信证据

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.

仅收集证明决策所需的最小范围证据：

已知的引擎及版本
当前CI平台或工作流文件
当前触发方式：PR/推送、定时/手动、受保护发布通道，或未知
目标平台和发布场景
重复失败模式：编译、打包、工具链、缓存、制品混乱、速度或信任问题
CI完成后仍需手动执行的步骤
若候选版本晋升是痛点，当前的制品命名/留存或审批规则
若团队反复提及单个失败构建，提供一份近期失败任务/日志

若证据不足，保持低置信度，优先选择

route-to-log-triage

或窄范围制品，而非虚假的完整重设计方案。

Step 3: Choose the signal tier explicitly

步骤3：明确选择信号层级

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.

在建议制品前，先确定哪个通道是问题所在：

branch-gate
：当反馈为PR/合并验证缓慢、每个分支都执行繁重打包，或快速反馈机制薄弱时
nightly-package-candidate
：当QA/评审/演示构建需要更繁重的打包、更广泛的目标覆盖，或在普通分支CI外进行定时/手动晋升时
release-certification-candidate
：当工作涉及严格审批、签名、面向商店/认证，或需要比普通CI更严格的制品留存规则时
unknown
：仅当现有证据无法区分通道时使用

若用户同时提及多个通道，选择当前最影响信任度的瓶颈通道，并将其他通道列为后续路由方向。

Step 4: Classify the primary blocker

步骤4：分类主要障碍

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
```

选择一个主要障碍，最多再选一个次要障碍。

主要障碍

```
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
```

典型映射：

"本地运行正常但CI中失败" →
```
reproducibility-drift
```
"我们的工作流是一个巨型任务，无法定位失败点" →
```
stage-boundary-blur
```
"我们不断删除缓存直到成功" →
```
dependency-cache-policy
```
"QA永远不知道哪个构建是正确的" →
```
artifact-release-hygiene
```
"Android/iOS/主机打包在后期失败" →
```
platform-toolchain-readiness
```
"构建速度慢，没人相信CI结果" →
```
feedback-speed-confidence
```
"这是一份失败的打包日志" →
```
single-log-not-pipeline
```

Step 5: Run the boundary check

步骤5：执行边界检查

Before writing advice, verify the lane:

Is this a structural pipeline question or just a failing log?
Does the chosen signal tier match the actual trigger/approval/artifact problem?
Is the best next artifact one of the packet types above?
Are you staying inside game-engine pipeline work instead of drifting into generic web-app DevOps?
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.

在撰写建议前，验证通道匹配性：

这是结构性流水线问题，还是仅为单个失败日志？
所选信号层级是否与实际触发/审批/制品问题匹配？
最佳下一个制品是否属于上述制品类型？
是否专注于游戏引擎流水线工作，而非偏离到通用Web应用DevOps？
引擎特定细节是否有助于诊断，而非增加冗余信息？

若答案大多为"这是单个失败日志"，则路由至

game-build-log-triage

并留下简短交接制品。若答案大多为"这实际上是发布门限政策问题"，则将政策决策路由至

testing-strategies

，本技能专注于游戏引擎实现层面。

Step 6: Build the packet brief

步骤6：构建制品简报

Return this exact structure:

markdown

undefined

返回以下固定结构：

markdown

undefined

Game CI/CD Brief

游戏CI/CD简报

Packet choice

制品选择

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

信号层级：branch-gate | nightly-package-candidate | release-certification-candidate | unknown
制品类型：...
引擎：...
CI平台：...
发布场景：...
置信度：高 | 中 | 低

Evidence used

使用的证据

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

工作流/系统背景：...
重复失败模式：...
CI外仍需手动执行的步骤：...
缺口/假设：...

Primary blocker

主要障碍

Bucket: ...
Why it matters now: ...
Evidence: ...

分类：...
当前影响：...
证据：...

Secondary blocker

次要障碍

Bucket: ...
Why it matters now: ...

分类：...
当前影响：...

Recommended pipeline shape

Engine and platform checks

引擎与平台检查

Unity / Unreal specifics: ...
SDK / signing / toolchain: ...
Cache or artifact policy: ...

Unity / Unreal 特定事项：...
SDK / 签名 / 工具链：...
缓存或制品策略：...

Recommended next artifact

Route-outs

路由方向

Skill: ...
Why: ...
Packet to pass: ...

技能：...
原因：...
交接制品：...

What not to do yet

暂不建议执行的操作

1-3 bullets that avoid brittle rewrites or cargo-cult caching

undefined

1-3条避免脆弱重写或盲目跟风缓存的要点

undefined

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

步骤7：根据引擎和信号层级定制制品

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

针对Unity

关注引擎/编辑器版本固定
确认
```
Packages/manifest.json
```
/锁文件输入及平台模块是否稳定
分离包恢复、构建、测试和打包阶段
将
```
Library/
```
和包缓存视为明确策略，而非例行清理
对于
```
branch-gate
```
，优先快速编译/测试/冒烟反馈及取消进行中任务的机制
对于
```
nightly-package-candidate
```
或
```
release-certification-candidate
```
，明确候选版本命名、构建目标分组、签名及制品留存规则

针对Unreal

区分UBT/UHT、编译、打包和发布环节
指出插件/模块漂移、资源重定向影响及AutomationTool可见性问题
区分DDC/缓存问题与打包/日志根源分析工作
在后期失败前提前暴露平台打包前置要求
对于
```
branch-gate
```
，除非项目风险确实需要，否则避免每次合并都执行完整编译/打包
对于
```
nightly-package-candidate
```
或
```
release-certification-candidate
```
，明确编译/打包时长、目标平台特定前置要求及发布/晋升规则

Step 8: Ask for the smallest missing packet

步骤8：请求缺失的最小范围信息

If confidence is low, request only what changes the decision:

current workflow file or job outline
trigger shape (PR/push vs schedule/manual vs protected release lane)
engine version and target platforms
one recent failed job/log if the issue may be
```
single-log-not-pipeline
```
current artifact naming / retention / approval pattern
what still happens manually after CI completes

若置信度低，仅请求能改变决策的信息：

当前工作流文件或任务大纲
触发方式（PR/推送 vs 定时/手动 vs 受保护发布通道）
引擎版本和目标平台
若问题可能为
```
single-log-not-pipeline
```
，提供一份近期失败任务/日志
当前制品命名/留存/审批模式
CI完成后仍需手动执行的步骤

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

始终返回简短的游戏流水线简报。

必备要求：

选择一个信号层级和一个主要制品类型
区分结构性流水线工作与一次性日志诊断
推荐一个下一个制品，而非完整平台重写
字数保持在300-550字左右，除非用户要求更多内容
当发布/演示场景影响优先级时，保持其可见性
当候选版本晋升/审批规则影响答案时，明确相关规则

Examples

示例

Example 1: Unity cache superstition

示例1：Unity缓存乱象

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

输入

我们的Unity GitHub Actions构建在本地正常，但更新包后在CI中失败。我们不断删除缓存并重跑直到成功。

推荐输出方向

制品类型：
```
cache-policy
```
主要障碍：
```
dependency-cache-policy
```
次要障碍：
```
reproducibility-drift
```
下一个制品：
```
cache-key policy
```
仅当明确指向单个日志时，才需添加路由方向

Example 2: Heavy packaging on every branch

示例2：每个分支都执行繁重打包

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

workflow stage split brief

call out that full packaging likely belongs in a heavier candidate lane, not every merge gate

输入

我们的PR流水线耗时70分钟，因为每个分支都要运行Android打包。首先应该做什么改变？

推荐输出方向

信号层级：
```
branch-gate
```
制品类型：
```
ci-signal-hardening
```
或
```
stage-split
```
主要障碍：
```
feedback-speed-confidence
```

下一个制品：

CI-signal hardening plan

或

workflow stage split brief

指出完整打包应属于更繁重的候选通道，而非每个合并门限

Example 3: Unreal giant job blob

示例3：Unreal巨型任务块

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
```

输入

我们有Unreal流水线，但打包耗时极长，失败信息显示为一个巨型日志块。

推荐输出方向

信号层级：通常为
```
nightly-package-candidate
```
，除非用户证明每次合并确实需要完整打包
制品类型：
```
stage-split
```
主要障碍：
```
stage-boundary-blur
```
次要障碍：
```
feedback-speed-confidence
```
下一个制品：
```
workflow stage split brief
```

Example 4: One failing packaging log

示例4：单个失败打包日志

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

输入

我们的Unreal Android打包任务昨晚失败了。这是AutomationTool输出日志。

推荐输出方向

制品类型：
```
route-to-log-triage
```
主要障碍：
```
single-log-not-pipeline
```
路由至
```
game-build-log-triage
```
传递失败阶段、引擎版本、目标平台及精确日志片段

Example 5: Manual nightly/demo candidate process

示例5：手动夜间/演示候选版本流程

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

pipeline setup plan

keep candidate naming, retention, and consumer handoff explicit

输入

我们已有快速分支构建，但QA需要一个带有明确制品名称的夜间Windows + Steam Deck候选版本。

推荐输出方向

信号层级：
```
nightly-package-candidate
```
制品类型：
```
artifact-release
```
或
```
pipeline-setup
```
主要障碍：
```
artifact-release-hygiene
```

下一个制品：

artifact/release checklist

或

pipeline setup plan

明确候选版本命名、留存规则及用户交接流程

Best practices

最佳实践

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

先命名信号层级再选择制品 —— 分支门限、夜间/候选包、发布/认证工作不应共享通用默认答案
以发布工程师的视角思考，而非通用基础设施讲师 —— 选择能减少重复痛点的下一个制品
保留日志/流水线边界 —— 单个失败构建通常需要先通过
```
game-build-log-triage
```
处理，再进行结构性重写
将缓存视为策略 —— 明确缓存的键值、共享规则、失效机制及主动再生场景
暴露阶段边界 —— 编译、测试、编译/打包、发布不应合并为一个不可读的任务块
保持发布场景可见 —— 原型、演示、认证、发布阶段需要不同的权衡策略
优先推荐单个下一个制品，而非冗长的CI/CD宣言
当争议点在于治理而非引擎流水线架构时，将发布门限政策路由至
testing-strategies

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

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-pipeline

Original

Translation

Game CI/CD Pipeline

游戏CI/CD流水线

When to use this skill

何时使用本技能

When not to use this skill

何时不使用本技能

Instructions

操作步骤

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

步骤1：先分类信号层级，再选择一个主要制品类型

Step 2: Gather the minimum credible evidence

步骤2：收集最少的可信证据

Step 3: Choose the signal tier explicitly

步骤3：明确选择信号层级

Step 4: Classify the primary blocker

步骤4：分类主要障碍

Step 5: Run the boundary check

步骤5：执行边界检查

Step 6: Build the packet brief

步骤6：构建制品简报

Game CI/CD Brief

游戏CI/CD简报

Packet choice

制品选择

Evidence used

使用的证据

Primary blocker

主要障碍

Secondary blocker

次要障碍

Recommended pipeline shape

推荐流水线架构

Engine and platform checks

引擎与平台检查

Recommended next artifact

推荐下一个制品

Route-outs

路由方向

What not to do yet

暂不建议执行的操作

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

步骤7：根据引擎和信号层级定制制品

Step 8: Ask for the smallest missing packet

步骤8：请求缺失的最小范围信息

Output format

输出格式

Examples

示例

Example 1: Unity cache superstition

示例1：Unity缓存乱象

Example 2: Heavy packaging on every branch

示例2：每个分支都执行繁重打包

Example 3: Unreal giant job blob

示例3：Unreal巨型任务块

Example 4: One failing packaging log

示例4：单个失败打包日志

Example 5: Manual nightly/demo candidate process

示例5：手动夜间/演示候选版本流程

Best practices

最佳实践

References

参考资料