ci-fix

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

CI Fix

CI修复

Diagnose CI failures and implement fixes with minimal, targeted diffs. Pushes fixes to a dedicated branch without creating PRs.

诊断CI失败问题并通过最小化、针对性的代码差异实施修复。将修复内容推送到专用分支，无需创建PR。

Prerequisites

前提条件

Verify GitHub CLI authentication before proceeding:

bash

gh auth status

If not authenticated, instruct the user to run

gh auth login

first.

在开始前请验证GitHub CLI的身份验证状态：

bash

gh auth status

如果未通过身份验证，请指导用户先运行

gh auth login

命令。

Workflow

工作流程

1. Locate the Failing Run

1. 定位失败的运行实例

Determine the failing workflow run. If working on a PR branch:

bash

gh pr view --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion == "FAILURE")'

If working from a branch or run ID:

bash

gh run list --branch <branch> --status failure --limit 5
gh run view <run-id> --verbose

确定失败的工作流运行实例。如果处理的是PR分支：

bash

gh pr view --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion == "FAILURE")'

如果处理的是普通分支或已知运行ID：

bash

gh run list --branch <branch> --status failure --limit 5
gh run view <run-id> --verbose

2. Extract Failure Logs

2. 提取失败日志

Pull logs from failed steps to identify the root cause:

bash

gh run view <run-id> --log-failed

For deeper inspection:

bash

gh run view <run-id> --log --job <job-id>
gh run download <run-id> -D .artifacts/<run-id>

从失败步骤中提取日志以识别根本原因：

bash

gh run view <run-id> --log-failed

如需深入检查：

bash

gh run view <run-id> --log --job <job-id>
gh run download <run-id> -D .artifacts/<run-id>

3. Identify Root Cause

3. 识别根本原因

Analyze logs for common failure patterns:

Build/compilation errors: Missing dependencies, type errors, syntax issues
Test failures: Assertion failures, timeouts, flaky tests
Linting/formatting: Style violations, unused imports
Environment issues: Missing secrets, permissions, resource limits

Prefer the smallest fix that resolves the issue. Deterministic code fixes are better than workflow plumbing changes.

分析日志以查找常见失败模式：

构建/编译错误：缺少依赖项、类型错误、语法问题
测试失败：断言失败、超时、不稳定测试
代码检查/格式化问题：风格违规、未使用的导入
环境问题：缺少机密信息、权限不足、资源限制

优先采用能解决问题的最小化修复方案。确定性代码修复优于对工作流配置的调整。

4. Implement the Fix

4. 实施修复

Make minimal, scoped changes matching the repository's existing style:

Fix only what's broken—avoid unrelated refactoring
Keep changes to the failing job/step when possible
If modifying workflow files, preserve existing permissions and avoid expanding token access

根据仓库现有代码风格进行最小化、范围明确的修改：

仅修复出现问题的部分——避免无关的重构
尽可能仅修改失败的任务/步骤
如果修改工作流文件，请保留现有权限设置，不要为了让测试通过而扩大令牌权限

5. Push to Fix Branch

5. 推送到修复分支

Create or update a dedicated fix branch:

bash

git checkout -b ci-fix/<original-branch>
git add -A
git commit -m "fix: resolve CI failure in <job-name>

Co-Authored-By: Warp <agent@warp.dev>"
git push -u origin ci-fix/<original-branch>

If the fix branch already exists, update it:

bash

git checkout ci-fix/<original-branch>
git pull origin <original-branch>

创建或更新专用修复分支：

bash

git checkout -b ci-fix/<original-branch>
git add -A
git commit -m "fix: resolve CI failure in <job-name>

Co-Authored-By: Warp <agent@warp.dev>"
git push -u origin ci-fix/<original-branch>

如果修复分支已存在，则更新它：

bash

git checkout ci-fix/<original-branch>
git pull origin <original-branch>

make fixes

进行修复

git commit -m "fix: <description>

Co-Authored-By: Warp agent@warp.dev" git push

undefined

git commit -m "fix: <description>

Co-Authored-By: Warp agent@warp.dev" git push

undefined

6. Verify the Fix

6. 验证修复

Trigger CI on the fix branch and monitor:

bash

gh run list --branch ci-fix/<original-branch> --limit 1
gh run watch <new-run-id> --exit-status

To rerun only failed jobs:

bash

gh run rerun <run-id> --failed

在修复分支上触发CI并进行监控：

bash

gh run list --branch ci-fix/<original-branch> --limit 1
gh run watch <new-run-id> --exit-status

如需仅重新运行失败的任务：

bash

gh run rerun <run-id> --failed

Safety Notes

安全注意事项

Avoid
```
pull_request_target
```
unless explicitly requested—it can expose secrets to untrusted code
Keep workflow
```
permissions:
```
minimal; don't broaden access to make tests pass
For flaky tests, prefer deterministic fixes over blind reruns

除非明确要求，否则避免使用
```
pull_request_target
```
——它可能会将机密信息暴露给不可信代码
保持工作流
```
permissions:
```
配置最小化；不要为了让测试通过而扩大权限范围
对于不稳定测试，优先采用确定性修复而非盲目重新运行

Deliverable

交付物

After fixing, provide a brief summary:

Failing run: Link or ID
Root cause: What broke and why
Fix: What changed
Verification: New run link showing green status

修复完成后，提供简要总结：

失败的运行实例：链接或ID
根本原因：故障内容及原因
修复方案：修改的内容
验证结果：显示正常状态的新运行实例链接