关于 ci-fix
供仓库维护者诊断 CI 失败并实施最小范围修复的技能。它通过 GitHub CLI 检查运行记录和日志,将修改推送到专用分支,但不会创建 PR。
主要功能
- 01定位失败的工作流运行
- 02检查失败步骤日志
- 03以小幅修改解决根因
- 04将修复推送到专用分支
- 05监控 CI 验证结果
适用场景
- 01调查 Pull Request 上失败的检查
- 02修复构建、测试或 lint 失败并验证
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ warpdotdev/ oz-skills --skill ci-fix安装后在 Claude Code 中输入/ci-fix确认已加载。
详细介绍
CI 修复
诊断 CI 故障,并通过最小化、针对性的差异实施修复。将修复推送到专用分支,不创建 PR。
前提条件
继续之前,确认 GitHub CLI 已通过身份验证:
gh auth status
如果尚未通过身份验证,请先让用户运行 gh auth login。
工作流
1. 定位失败的运行
确定失败的工作流运行。如果正在处理 PR 分支:
gh pr view --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion == "FAILURE")'
如果从某个分支或运行 ID 开始:
gh run list --branch <branch> --status failure --limit 5
gh run view <run-id> --verbose
2. 提取失败日志
提取失败步骤的日志,以确定根本原因:
gh run view <run-id> --log-failed
如需深入检查:
gh run view <run-id> --log --job <job-id>
gh run download <run-id> -D .artifacts/<run-id>
3. 确定根本原因
分析日志,查找常见的故障模式:
- 构建/编译错误:缺少依赖项、类型错误、语法问题
- 测试失败:断言失败、超时、不稳定的测试
- 代码检查/格式问题:违反样式规范、未使用的导入
- 环境问题:缺少机密、权限不足、资源限制
优先选择能解决问题的最小修复。确定性的代码修复优于工作流配置调整。
4. 实施修复
进行最小范围的更改,并遵循仓库现有的风格:
- 只修复出问题的部分,避免无关的重构
- 尽可能将更改限制在失败的作业/步骤中
- 如果修改工作流文件,请保留现有权限,避免扩大令牌的访问范围
5. 推送到修复分支
创建或更新专用修复分支:
git checkout -b ci-fix/<original-branch>
git add -A
git commit -m "fix: resolve CI failure in <job-name>
Co-Authored-By: Warp <[email protected]>"
git push -u origin ci-fix/<original-branch>
如果修复分支已存在,请更新它:
git checkout ci-fix/<original-branch>
git pull origin <original-branch>
# make fixes
git commit -m "fix: <description>
Co-Authored-By: Warp <[email protected]>"
git push
6. 验证修复
在修复分支上触发 CI 并监控运行情况:
gh run list --branch ci-fix/<original-branch> --limit 1
gh run watch <new-run-id> --exit-status
要仅重新运行失败的作业:
gh run rerun <run-id> --failed
安全须知
- 除非用户明确要求,否则避免使用
pull_request_target,因为它可能会将机密暴露给不受信任的代码 - 尽量精简工作流中的
permissions:,不要为了通过测试而扩大访问权限 - 对于不稳定的测试,优先采用确定性修复,而不是盲目重新运行
交付内容
修复后,提供简要总结:
- 失败的运行:链接或 ID
- 根本原因:故障原因及其成因
- 修复:更改内容
- 验证:显示绿色状态的新运行链接
评论
支持 Markdown