CI 流水线优化器

让 CI/CD 流水线更快、更省钱。分析工作流文件，识别性能瓶颈、缺失的缓存、本可并行执行却串行运行的步骤、不必要的工作，以及过大的 Docker 构建。

适用场景：”CI 太慢了“、”优化我们的流水线“、”缩短构建时间“、”CI 成本太高“、”加速 GitHub Actions“、”流水线耗时 20 分钟“，或进行 CI/CD 维护工作。

命令

1. analyze — 全量流水线分析

扫描所有 CI 配置文件，识别可优化项。

步骤 1：发现流水线配置

echo "=== CI 流水线发现 ==="

# GitHub Actions
if [ -d ".github/workflows" ]; then
  echo "平台: GitHub Actions"
  ls -la .github/workflows/*.yml .github/workflows/*.yaml 2>/dev/null
fi

# GitLab CI
[ -f ".gitlab-ci.yml" ] && echo "平台: GitLab CI"

# CircleCI
[ -f ".circleci/config.yml" ] && echo "平台: CircleCI"

# Jenkins
[ -f "Jenkinsfile" ] && echo "平台: Jenkins"

# Bitbucket
[ -f "bitbucket-pipelines.yml" ] && echo "平台: Bitbucket Pipelines"

# Azure DevOps
[ -f "azure-pipelines.yml" ] && echo "平台: Azure DevOps"

步骤 2：缓存分析

echo ""
echo "=== 缓存分析 ==="

# GitHub Actions：检查缓存步骤
if [ -d ".github/workflows" ]; then
  echo "--- 缓存使用情况 ---"
  rg -n "actions/cache|cache:" .github/workflows/ 2>/dev/null

  # 检查是否缓存了 node_modules
  HAS_NODE_CACHE=$(rg -c "node_modules|npm-cache|yarn-cache|pnpm-store" .github/workflows/ 2>/dev/null | awk -F: '{s+=$2} END {print s+0}')
  [ -f "package.json" ] && [ "$HAS_NODE_CACHE" -eq 0 ] && echo "⚠️  缺失：Node.js 依赖缓存"

  # 检查是否配置了 pip 缓存
  HAS_PIP_CACHE=$(rg -c "pip-cache|pip.*cache|~/.cache/pip" .github/workflows/ 2>/dev/null | awk -F: '{s+=$2} END {print s+0}')
  [ -f "requirements.txt" ] && [ "$HAS_PIP_CACHE" -eq 0 ] && echo "⚠️  缺失：Python pip 缓存"

  # 检查是否启用 Docker 层缓存
  HAS_DOCKER_CACHE=$(rg -c "docker/build-push-action.*cache|buildx.*cache|docker-layer-caching" .github/workflows/ 2>/dev/null | awk -F: '{s+=$2} END {print s+0}')
  HAS_DOCKER=$(rg -c "docker build|docker-compose|docker/build-push" .github/workflows/ 2>/dev/null | awk -F: '{s+=$2} END {print s+0}')
  [ "$HAS_DOCKER" -gt 0 ] && [ "$HAS_DOCKER_CACHE" -eq 0 ] && echo "⚠️  缺失：Docker 层缓存"

  # 检查是否启用构建产物缓存（turbo、nx）
  [ -f "turbo.json" ] && ! rg -q "turborepo-cache|turbo.*cache" .github/workflows/ 2>/dev/null && echo "⚠️  缺失：Turborepo 远程缓存"
fi

# GitLab CI
if [ -f ".gitlab-ci.yml" ]; then
  rg -n "cache:" .gitlab-ci.yml 2>/dev/null
  HAS_CACHE=$(rg -c "cache:" .gitlab-ci.yml 2>/dev/null || echo "0")
  [ "$HAS_CACHE" -eq 0 ] && echo "⚠️  .gitlab-ci.yml 中未配置缓存"
fi

步骤 3：并行化分析

echo ""
echo "=== 并行化机会 ==="

if [ -d ".github/workflows" ]; then
  # 查找存在串行任务但可改为并行的工作流
  for wf in .github/workflows/*.yml .github/workflows/*.yaml; do
    [ -f "$wf" ] || continue
    echo "--- $(basename $wf) ---"

    # 检查是否含 needs:（任务依赖）
    JOBS=$(rg -c "^s{2}w+:" "$wf" 2>/dev/null || echo "0")
    NEEDS=$(rg -c "needs:" "$wf" 2>/dev/null || echo "0")

    echo "  任务数: $JOBS, 依赖项 (needs): $NEEDS"

    if [ "$JOBS" -gt 1 ] && [ "$NEEDS" -eq 0 ]; then
      echo "  ✅ 任务并行执行（无依赖）"
    elif [ "$NEEDS" -gt 0 ]; then
      echo "  检查是否可移除部分 'needs' 以支持并行执行："
      rg -n "needs:" "$wf" 2>/dev/null | head -5
    fi

    # 检查是否使用 matrix 策略
    HAS_MATRIX=$(rg -c "matrix:" "$wf" 2>/dev/null || echo "0")
    [ "$HAS_MATRIX" -gt 0 ] && echo "  ✅ 使用 matrix 策略"

    # 检查是否存在可拆分为并行任务的步骤
    STEPS=$(rg -c "^s*- (name|run|uses):" "$wf" 2>/dev/null || echo "0")
    [ "$STEPS" -gt 15 ] && echo "  ⚠️  单个任务中含 $STEPS 个步骤 — 建议拆分为并行任务"
  done
fi

步骤 4：冗余工作检测

echo ""
echo "=== 冗余工作 ==="

if [ -d ".github/workflows" ]; then
  for wf in .github/workflows/*.yml .github/workflows/*.yaml; do
    [ -f "$wf" ] || continue

    # 检查路径过滤器（仅在相关变更时运行）
    HAS_PATHS=$(rg -c "paths:" "$wf" 2>/dev/null || echo "0")
    [ "$HAS_PATHS" -eq 0 ] && echo "⚠️  $(basename $wf)：未配置路径过滤器 — 将响应所有文件变更"

    # 检查条件执行逻辑
    HAS_IF=$(rg -c "if:" "$wf" 2>/dev/null || echo "0")
    echo "  $(basename $wf)：$HAS_IF 个条件步骤"

    # 全量检出 vs 浅层检出
    FULL_CHECKOUT=$(rg -c "fetch-depth: 0" "$wf" 2>/dev/null || echo "0")
    [ "$FULL_CHECKOUT" -gt 0 ] && echo "  ⚠️  全量 Git 历史检出（fetch-depth: 0）— 是否必需？"

    # 多次 npm install 步骤
    NPM_INSTALLS=$(rg -c "npm install|npm ci|yarn install|pnpm install" "$wf" 2>/dev/null || echo "0")
    [ "$NPM_INSTALLS" -gt 1 ] && echo "  ⚠️  $NPM_INSTALLS 个独立安装步骤 — 建议合并或启用缓存"
  done
fi

步骤 5：Docker 构建优化

echo ""
echo "=== Docker 构建优化 ==="

find . -name "Dockerfile" -not -path '*/node_modules/*' 2>/dev/null | while read df; do
  echo "--- $df ---"
  LINES=$(wc -l < "$df")
  echo "  行数: $LINES"

  # 是否为多阶段构建？
  STAGES=$(grep -c "^FROM " "$df")
  [ "$STAGES" -gt 1 ] && echo "  ✅ 多阶段构建（$STAGES 个阶段）" || echo "  ⚠️  单阶段构建 — 建议改用多阶段以减小镜像体积"

  # 在包安装前执行 COPY（破坏缓存）
  COPY_ALL=$(grep -n "COPY . .|COPY ./ " "$df" | head -1 | cut -d: -f1)
  RUN_INSTALL=$(grep -n "npm install|npm ci|pip install|go build" "$df" | head -1 | cut -d: -f1)
  if [ -n "$COPY_ALL" ] && [ -n "$RUN_INSTALL" ] && [ "$COPY_ALL" -lt "$RUN_INSTALL" ]; then
    echo "  ⚠️  在 install 前执行 COPY . — 每次文件变更都会破坏 Docker 缓存"
    echo "     修复建议：先 COPY package*.json，再 install，最后 COPY 其余文件"
  fi

  # 是否存在 .dockerignore？
  DIR=$(dirname "$df")
  [ -f "$DIR/.dockerignore" ] || [ -f ".dockerignore" ] || echo "  ⚠️  缺失 .dockerignore — 向 Docker 守护进程发送了不必要的文件"

  # 基础镜像是否过大？
  BASE=$(grep "^FROM " "$df" | tail -1 | awk '{print $2}')
  echo "$BASE" | grep -qE "^(ubuntu|debian|centos|node:|python:)" && 
    ! echo "$BASE" | grep -qE "(slim|alpine|distroless)" && 
    echo "  ⚠️  基础镜像过大（$BASE）— 建议改用 slim/alpine/distroless 变体"
done

2. cache — 缓存配置建议

为项目生成具体的缓存配置：

# GitHub Actions + Node.js 场景
- uses: actions/cache@v4
  with:
    path: |
      ~/.npm
      node_modules
    key: node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: node-

各技术生态推荐方案：

• Node.js：基于 lockfile 哈希缓存 node_modules 或 ~/.npm
• Python：基于 requirements.txt 哈希缓存 ~/.cache/pip
• Go：基于 go.sum 哈希缓存 ~/go/pkg/mod
• Rust：基于 Cargo.lock 哈希缓存 ~/.cargo 和 target/
• Docker：使用 BuildKit cache mount 或 docker/build-push-action 缓存

3. timeline — 构建时间线可视化

解析 CI 日志或配置，估算任务耗时：

流水线: build-and-test.yml
总预估耗时：~12 分钟（串行）→ ~6 分钟（优化后）

[lint]        ████░░░░░░░░  2 分钟
[test]        ██████████░░  5 分钟  （依赖：lint）
[build]       ████████░░░░  4 分钟  （依赖：lint）
[deploy]      ██░░░░░░░░░░  1 分钟  （依赖：test, build）

优化建议：并行执行 [test] 和 [build] → 节省 4 分钟

4. suggest — 生成优化后的流水线

输出已应用全部优化项的重写版流水线：

• 添加缓存配置
• 对相互独立的任务启用并行化
• 添加路径过滤器
• 优化 Docker 构建流程
• 为仅文档变更等场景添加条件执行逻辑以跳过无关步骤

输出格式

• text（默认）：面向人类阅读的分析报告与优化建议
• json：{platform, workflows: [{name, jobs, steps, caches, issues: []}], optimizations: [], estimated_savings: ""}
• markdown：适用于 PR 描述或 Wiki 文档的报告
• yaml：可直接使用的优化后工作流配置

注意事项

• 支持 GitHub Actions、GitLab CI、CircleCI 和 Jenkinsfile 的静态分析
• 不访问 CI 日志或运行历史 — 仅静态分析配置文件
• 时间预估为启发式结果（基于常见操作的典型耗时）
• 缓存建议具备框架感知能力，并遵循当前最佳实践
• Docker 优化检查覆盖项目中所有 Dockerfile
• 针对单体仓库（monorepo），建议采用路径过滤触发机制及影响范围测试（affected-only testing）