setup-ci

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Setup CI/CD Workflow

搭建CI/CD工作流

Generate GitHub Actions CI/CD workflows by collecting project requirements through a questionnaire.

通过收集项目需求的交互式问卷生成GitHub Actions CI/CD工作流。

1. Sync main

1. 同步主分支

git checkout main && git pull

git checkout main && git pull

2. Create worktree and branch

2. 创建工作树与分支

git worktree add .claude/worktrees/chore-setup-ci -b chore/setup-ci
cd .claude/worktrees/chore-setup-ci

All work happens in the worktree — main stays clean.

git worktree add .claude/worktrees/chore-setup-ci -b chore/setup-ci
cd .claude/worktrees/chore-setup-ci

所有操作都在工作树中进行——主分支保持干净。

3. Auto-detect project context

3. 自动检测项目上下文

Before asking questions, scan the project to pre-fill answers:

Language/runtime: check for

package.json

(Node.js),

pyproject.toml

setup.py

requirements.txt

(Python),

Cargo.toml

(Rust),

go.mod

(Go),

pom.xml

build.gradle

(Java),

Gemfile

(Ruby), etc.

Package manager: npm/yarn/pnpm/bun, pip/poetry/uv, cargo, go, maven/gradle
Test framework: detect from config or dependencies (jest, pytest, cargo test, go test, etc.)
Build command: check
```
scripts.build
```
in package.json, Makefile targets, etc.
Existing CI: check if
```
.github/workflows/
```
already exists — if so, ask if user wants to replace or extend
Monorepo: check for
```
workspaces
```
,
```
turbo.json
```
,
```
nx.json
```
,
```
lerna.json
```

Present findings: "I detected: [language], [package manager], [test framework], [build tool]. Is this correct?"

在提问前，先扫描项目以预填答案：

语言/运行时：检查是否存在
```
package.json
```
（Node.js）、
```
pyproject.toml
```
/
```
setup.py
```
/
```
requirements.txt
```
（Python）、
```
Cargo.toml
```
（Rust）、
```
go.mod
```
（Go）、
```
pom.xml
```
/
```
build.gradle
```
（Java）、
```
Gemfile
```
（Ruby）等文件
包管理器：npm/yarn/pnpm/bun、pip/poetry/uv、cargo、go、maven/gradle
测试框架：从配置文件或依赖中检测（jest、pytest、cargo test、go test等）
构建命令：检查package.json中的
```
scripts.build
```
、Makefile目标等
现有CI：检查
```
.github/workflows/
```
是否已存在——若存在，询问用户是替换还是扩展
单体仓库（Monorepo）：检查是否存在
```
workspaces
```
、
```
turbo.json
```
、
```
nx.json
```
、
```
lerna.json
```

展示检测结果：“我检测到：[语言]、[包管理器]、[测试框架]、[构建工具]。是否正确？”

4. Interactive questionnaire

4. 交互式问卷

Ask the user each section. Use the auto-detected defaults where available. Skip questions that don't apply.

逐个向用户询问各部分内容。尽可能使用自动检测的默认值。跳过不适用的问题。

Section A: Basics

A部分：基础设置

#	Question	Options
A1	Trigger branches — which branches should trigger CI?	`main` only / `main` + PR / all branches / custom
A2	Node/Python/Go version(s) — which version(s) to test against?	single version / matrix (e.g., 3.11, 3.12, 3.13)
A3	OS matrix — which OS to run on?	ubuntu-latest only / ubuntu + macos / ubuntu + macos + windows

序号	问题	选项
A1	触发分支 — 哪些分支应该触发CI？	仅 `main` 分支 / `main` 分支+PR / 所有分支 / 自定义
A2	Node/Python/Go版本 — 测试时使用哪些版本？	单一版本 / 多版本矩阵（如3.11、3.12、3.13）
A3	操作系统矩阵 — 在哪些操作系统上运行？	仅ubuntu-latest / ubuntu + macos / ubuntu + macos + windows

Section B: Testing

B部分：测试

#	Question	Options
B1	Unit tests — enable?	yes / no
B2	Test command — what runs your tests?	auto-detected or custom
B3	Coverage check — enable minimum coverage threshold?	no / yes → ask threshold (e.g., 80%)
B4	Coverage tool — which tool?	auto-detect (coverage.py, istanbul/c8, tarpaulin, etc.) or custom
B5	Upload coverage report? — to Codecov, Coveralls, or artifact?	none / codecov / coveralls / artifact

序号	问题	选项
B1	单元测试 — 是否启用？	是 / 否
B2	测试命令 — 运行测试的命令是什么？	自动检测值或自定义
B3	覆盖率检查 — 是否启用最低覆盖率阈值？	否 / 是 → 询问阈值（如80%）
B4	覆盖率工具 — 使用哪个工具？	自动检测（coverage.py、istanbul/c8、tarpaulin等）或自定义
B5	上传覆盖率报告？ — 上传至Codecov、Coveralls还是作为工件？	不上传 / codecov / coveralls / 工件

Section C: Build & Lint

C部分：构建与代码扫描

#	Question	Options
C1	Build step — enable?	yes / no / not applicable
C2	Build command	auto-detected or custom
C3	Linting — enable?	yes / no
C4	Lint command	auto-detected (eslint, ruff, clippy, golangci-lint, etc.) or custom
C5	Type checking — enable?	yes / no (for TS: tsc --noEmit, Python: mypy/pyright, etc.)
C6	Format check — enable?	yes / no (prettier, black, rustfmt, gofmt, etc.)

序号	问题	选项
C1	构建步骤 — 是否启用？	是 / 否 / 不适用
C2	构建命令	自动检测值或自定义
C3	代码扫描（Linting） — 是否启用？	是 / 否
C4	扫描命令	自动检测（eslint、ruff、clippy、golangci-lint等）或自定义
C5	类型检查 — 是否启用？	是 / 否（针对TS：tsc --noEmit，Python：mypy/pyright等）
C6	格式检查 — 是否启用？	是 / 否（prettier、black、rustfmt、gofmt等）

Section D: Security & Quality

D部分：安全与质量

#	Question	Options
D1	Dependency audit — check for known vulnerabilities?	yes / no
D2	Secret scanning — add trufflehog or gitleaks?	yes / no
D3	SAST — static analysis (CodeQL, semgrep)?	none / codeql / semgrep / custom

序号	问题	选项
D1	依赖审计 — 是否检查已知漏洞？	是 / 否
D2	密钥扫描 — 是否添加trufflehog或gitleaks？	是 / 否
D3	静态应用安全测试（SAST） — 静态分析工具（CodeQL、semgrep）？	不使用 / codeql / semgrep / 自定义

Section E: Deployment

E部分：部署

#	Question	Options
E1	Auto-deploy — deploy on merge to main?	no / yes → ask target
E2	Deploy target	Vercel / Netlify / AWS / GCP / Fly.io / Docker registry / npm publish / PyPI publish / custom
E3	Preview deploys — on PR?	yes / no
E4	Release automation — auto-create GitHub release on tag?	yes / no

序号	问题	选项
E1	自动部署 — 合并至main分支时自动部署？	否 / 是 → 询问部署目标
E2	部署目标	Vercel / Netlify / AWS / GCP / Fly.io / Docker镜像仓库 / npm发布 / PyPI发布 / 自定义
E3	预览部署 — 在PR时部署预览版？	是 / 否
E4	发布自动化 — 打标签时自动创建GitHub发布版本？	是 / 否

Section F: Custom additions

F部分：自定义扩展

#	Question	Options
F1	Additional workflows — anything else you need?	free text — user describes custom needs

Examples to suggest if user is unsure:

Scheduled jobs (cron-based cleanup, stale issue bot)
Performance benchmarks on PR
Docker image build and push
Database migration check
E2E tests (Playwright, Cypress)
Changelog generation
PR labeling / auto-assign
Notification (Slack, Discord, email)

序号	问题	选项
F1	额外工作流 — 还有其他需求吗？	自由文本——用户描述自定义需求

若用户不确定，可提供以下示例建议：

定时任务（基于cron的清理、过期Issue机器人）
PR中的性能基准测试
Docker镜像构建与推送
数据库迁移检查
端到端测试（Playwright、Cypress）
变更日志生成
PR标签自动添加/自动分配
通知（Slack、Discord、邮件）

5. Generate workflows

5. 生成工作流

Based on answers, generate GitHub Actions YAML files:

.github/workflows/ci.yml
— main CI pipeline (test, build, lint, coverage)
.github/workflows/deploy.yml
— deployment pipeline (if E1 = yes)
.github/workflows/security.yml
— security checks (if any D section = yes)
Additional files — one per custom workflow from Section F

根据回答生成GitHub Actions YAML文件：

.github/workflows/ci.yml
— 主CI流水线（测试、构建、代码扫描、覆盖率检查）
.github/workflows/deploy.yml
— 部署流水线（若E1选择“是”）
.github/workflows/security.yml
— 安全检查（若D部分有选项选“是”）
额外文件 — F部分每个自定义工作流对应一个文件

CI workflow template structure

CI工作流模板结构

yaml

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up <runtime>
        uses: actions/setup-<runtime>@v5
        with:
          <runtime>-version: '<version>'
      - name: Install dependencies
        run: <install-command>
      - name: Lint
        run: <lint-command>
      - name: Type check
        run: <typecheck-command>
      - name: Test
        run: <test-command>
      - name: Coverage check
        run: <coverage-command>
        # fail if below threshold

yaml

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up <runtime>
        uses: actions/setup-<runtime>@v5
        with:
          <runtime>-version: '<version>'
      - name: Install dependencies
        run: <install-command>
      - name: Lint
        run: <lint-command>
      - name: Type check
        run: <typecheck-command>
      - name: Test
        run: <test-command>
      - name: Coverage check
        run: <coverage-command>
        # 若低于阈值则失败

Rules for generation

生成规则

Use the latest stable action versions (checkout@v4, setup-node@v5, setup-python@v5, etc.)
Pin action versions to major tags, not SHA (readable + auto-patches)
Add
```
concurrency
```
group to cancel stale runs on same PR
Cache dependencies (actions/cache or built-in caching in setup actions)
Keep jobs parallelized where possible (lint and test can run concurrently)
Add meaningful job names and step names
Use
```
fail-fast: false
```
in matrix builds so one failure doesn't cancel others

使用最新稳定版Action（checkout@v4、setup-node@v5、setup-python@v5等）
将Action版本固定到主版本标签，而非SHA（可读性更高且自动获取补丁）
添加
```
concurrency
```
组以取消同一PR上的过期运行任务
缓存依赖（使用actions/cache或setup类Action的内置缓存功能）
尽可能并行化任务（代码扫描和测试可同时运行）
使用有意义的任务名称和步骤名称
在矩阵构建中设置
```
fail-fast: false
```
，避免单个失败导致其他任务被取消

6. Present and confirm

6. 展示并确认

Show the user:

List of files to be created
Summary of what each workflow does
Any secrets or environment variables they'll need to configure

Ask for confirmation before writing files.

向用户展示：

待创建的文件列表
每个工作流的功能摘要
需要配置的密钥或环境变量

在写入文件前询问用户确认。

7. Write files and create PR

7. 写入文件并创建PR

Write all workflow files to
```
.github/workflows/
```
Commit with descriptive message
Push and create PR via
```
gh pr create
```
Wait for CI/CD checks to complete:
```
gh pr checks <number> --watch
```
If checks fail, fix the issues and push again — do not notify the user until all checks are green
Once all checks pass, return the PR URL and ask the user to review
DO NOT merge — wait for explicit approval

将所有工作流文件写入
```
.github/workflows/
```
使用描述性信息提交
推送并通过
```
gh pr create
```
创建PR
等待CI/CD检查完成：
```
gh pr checks <number> --watch
```
若检查失败，修复问题后重新推送——直到所有检查通过再通知用户
所有检查通过后，返回PR链接并请用户审核
请勿合并——等待用户明确批准

8. Merge (only when approved)

8. 合并（仅在获得批准后）

```
gh pr merge <number> --merge
```

Clean up worktree:

cd <project-root> && git worktree remove .claude/worktrees/chore-setup-ci

git checkout main && git pull && git branch -d chore/setup-ci

```
gh pr merge <number> --merge
```

清理工作树：

cd <项目根目录> && git worktree remove .claude/worktrees/chore-setup-ci

git checkout main && git pull && git branch -d chore/setup-ci

Rules

规则

Never merge without explicit approval
Never push directly to main
Always auto-detect first — don't ask questions you can answer by reading the project
Present defaults — user should only need to confirm or override, not type from scratch
One concern per workflow file — don't cram everything into one giant YAML
Never hardcode secrets — always use
```
${{ secrets.XXX }}
```
and tell user what to configure

未经明确批准绝不合并
绝不直接推送到主分支
始终先自动检测——不要询问可通过读取项目内容回答的问题
提供默认值——用户只需确认或覆盖，无需从头输入
每个工作流文件对应一个关注点——不要将所有内容塞进一个庞大的YAML文件
绝不硬编码密钥——始终使用
```
${{ secrets.XXX }}
```
并告知用户需要配置的内容