mcpField
F
frontend-review-ci

frontend-review-ci

github.com/mizchi云与 DevOps41647 次安装1 周前更新
代码仓库

关于 frontend-review-ci

frontend-review-ci 是用于分析和优化前端项目 GitHub Actions CI 的技能。它检查运行时长和工作流结构，给出优化建议并起草 PR 描述，不会修改工作流或创建 PR。

主要功能

  1. 01审计 CI 运行和步骤耗时
  2. 02检查工作流缓存与并发设置
  3. 03识别串行任务和分片机会
  4. 04提出针对性的 YAML 修改建议
  5. 05起草 PR 描述

适用场景

  1. 01定位缓慢前端 CI 的瓶颈
  2. 02检查各工作流的缓存覆盖情况
  3. 03规划 lint 与 typecheck 并行执行
  4. 04准备针对性的 CI 优化方案

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mizchi/skills --skill frontend-review-ci

安装后在 Claude Code 中输入/frontend-review-ci确认已加载。

附带文件README.md

详细介绍

前端审查 — CI 优化

你正在优化某个前端项目的 GitHub Actions CI。目标是 中位数 ≤ 10 分钟，最大值 ≤ 15 分钟。CI 越快，开发者就越信任它；这种信任正是优化机制发挥作用的关键。

流程

  1. 运行 scripts/audit-ci.sh --repo <client-repo>。
  2. 阅读 <client-repo>/.frontend-review/report/latest/raw/ci.json。
  3. 对于最慢的运行，深入检查步骤级耗时： 
    gh run view <run-id> --log | grep -E '^\d{4}-' | head -200
  4. 检查 .github/workflows/ 下现有的工作流，并记录：
    • 每个任务（lint、build、test、coverage 等）是否都使用了 pnpm/npm 存储缓存？常见遗漏：test.yml 配置了缓存，但 lint.yml 和 pages.yml 没有。
    • actions/setup-node 是否使用了 cache: pnpm，或者是否有手动的 actions/cache 配置块用于缓存 pnpm 存储？两者都可以；键必须包含 hashFiles('**/pnpm-lock.yaml')。
    • actions/cache 是否缓存了 Playwright 浏览器存储（~/.cache/ms-playwright）？
    • 是否有 concurrency: 配置块？
    • vitest / playwright 是否进行了分片？
    • 是否通过 needs: 不必要地串行执行了任务？
    • lint 和 typecheck 是否位于同一个串行任务中？它们互不依赖，应该拆分为两个并行任务。

输出

将以下内容写入 <client-repo>/.frontend-review/report/latest/md/ci-analysis.md：

  • 当前中位数 / 最大耗时
  • 一个有代表性的失败运行和成功运行中最慢的 3 个步骤
  • 具体建议，每条建议都对应到 YAML 补丁中的一行（而非完整重写）
  • 每条建议的预估收益

然后撰写一份 PR 描述草稿，供用户复制到 gh pr create，并将分支命名为 ci/optimize。

开发迭代耗时目标

诊断 CI 缓慢问题时，请将以下阈值作为参考。任何阶段耗时超过其目标的 2 倍，都应专门建立一个瓶颈问题。

阶段目标测量方式
HMR（编辑 → 屏幕显示）< 500 msVite --debug 输出
单文件单元测试< 1 svitest / jest 输出
test:ci — 全量测试套件< 1 minCI 步骤耗时
typecheck< 30 sCI 步骤耗时
lint< 30 sCI 步骤耗时
E2E — 一个分片< 50 sCI 步骤耗时
PR CI 总耗时（并行）< 5 minGitHub Actions 墙钟时间
install（命中缓存）< 15 sCI 步骤耗时
build< 30 sCI 步骤耗时

PR CI 总耗时是关键门槛。CI 超过 5 分钟时，开发者通常会绕过它。

瓶颈识别流程

  1. 获取近期最慢运行的步骤级耗时： 
    gh run view <run-id> --log | grep -E '^\d{4}-' | head -200
  2. 找出 DAG 中耗时最长的单个任务——并行图中只有最长路径决定墙钟时间。
  3. 在该任务中找出耗时最长的步骤。
  4. 每个 PR 只提出一项更改——将多项优化打包在一起，会导致无法判断回归归因。
  5. 在同一分支上测量优化前后的墙钟时间，以验证收益。

常见优化模式

领域常见修复方式
installpnpm / npm 存储缓存键、--frozen-lockfile、缩小 onlyBuiltDependencies 范围。检查每个工作流文件——只为部分任务配置缓存是最常见的疏漏；install 未使用缓存时约需 20-25 s，命中缓存后可降至约 2-3 s
lint + typecheck拆分为两个并行任务（互不依赖）。对于约有 170 个 TS 文件的项目，仅此一项就能将 lint 任务的墙钟时间缩短一半
typecheck拆分 Project References、设置 skipLibCheck: true、解决循环类型导入
lintPR 使用 lint-staged（仅检查已更改文件），启用 linter 自带的增量缓存
vitest设置 isolate: false，调整 --pool 线程数，将测试夹具从 coverage 中排除
Playwright根据测试量调整分片数量，使用 page.route() 模拟外部 API，将不稳定测试移至仅每日运行的标签
Runner 规格只有穷尽上述方法后，才考虑使用更大型的 runner（4 核以上）

边界

  • 不要实际创建 PR 或推送分支——只需起草描述。
  • 不要修改客户端仓库中的工作流 YAML；用户会在审阅你的提案后进行修改。

参考

  • 检查清单：checklist/09-ci-optimization.md
  • 阶段：phase/week-1-ci-baseline.md
  • 模板：templates/github-actions/ci.yml、templates/github-actions/e2e.yml

评论

支持 Markdown