--- name: gitea-fix-ci description: "Use when a user asks to debug or fix failing Gitea Actions, Gitea PR checks, or CI workflow runs for a Gitea-hosted repository. Also triggers on Chinese phrasing such as CI 挂了/流水线红了/构建失败/工作流失败." --- # Gitea Fix CI ## 概述 从 pull request 或 workflow run 诊断失败的 Gitea Actions，提取最小可用的失败上下文， 然后在改代码之前先给出修复计划。核心原则：CI 日志是证据，不要仅凭红色状态臆测原因。 本 skill 不是独立执行器。它指导你在当前工作区中使用随附的取证脚本 `scripts/fetch_ci_logs.py`、`tea`、本地 `git` 和 Gitea API。 取证阶段（step 2-4）优先使用随附脚本，把「探测版本 → 找失败 run → 列 job → 下载失败 job 日志」这段易记错 API 路径的逻辑交给它。脚本仅取证到日志，分类、 修复计划与改代码仍由你按本文档执行。将 `` 替换为包含本 `SKILL.md` 的目录： ```bash # 方式一（优先）：通过环境变量提供 API token export GITEA_TOKEN= python /scripts/fetch_ci_logs.py version # 探测实例版本并确认连通性 python /scripts/fetch_ci_logs.py runs --status failure --branch python /scripts/fetch_ci_logs.py jobs # 标注 failure 的 job python /scripts/fetch_ci_logs.py logs # 日志存临时文件并回显尾部 # 方式二：显式复用当前仓库的 Git HTTP 凭据 python /scripts/fetch_ci_logs.py --use-git-credential version python /scripts/fetch_ci_logs.py --use-git-credential runs --status failure ``` `base-url`、owner 和 repo 默认从 git remote 推导。认证规则如下： - 设置了 `GITEA_TOKEN` 时始终优先使用它，即使同时传入 `--use-git-credential`。 - 只有显式传入 `--use-git-credential` 才会非交互调用 `git credential fill`，并将 当前仓库对应的用户名和密码用于 HTTP Basic 认证；脚本不会静默读取 Git 凭据。 - 未设置 token 且未传入该参数时按匿名方式访问，私有仓库通常会返回 401。 - 所有携带凭据的请求必须使用 HTTPS；认证 header 只发送到配置的 Gitea 同源地址， 跨源请求和跨源重定向会被拒绝。凭据不会出现在命令参数、日志或异常文本中。 脚本不可用（未装 Python、旧版 Gitea 无 job-log API、脱离 Gitea 环境）时，回退到 下文的手动 `tea`/API/web 路径。 ## 适用场景 - Gitea 托管的仓库出现失败的 Gitea Actions 或 PR checks - 用户要求检查某个失败的 workflow run、job 或 CI 状态 - 用户要求在 push、更新分支或更新 pull request 之后修复 CI - 本地测试通过，但远端 Gitea Actions 失败 ## 不适用场景 - 仓库并非托管在 Gitea 或 Forgejo 兼容的基础设施上 - 失败属于外部 CI 服务，只是从 Gitea 链接出去 - 用户只想在本地跑测试或 lint - 没有凭据、token 或网络访问权限，且用户也未提供失败的日志文本 ## 输入 - 仓库路径，默认为当前工作区 - Gitea base URL 和仓库 owner/name，尽量从 `git remote -v` 获取 - Pull request 编号、分支、commit SHA 或 workflow run ID - 认证方式：`tea` 登录 profile、用于 API 请求的 `GITEA_TOKEN`，或通过 `--use-git-credential` 显式读取的当前仓库 Git HTTP 凭据 - 若无法远端访问，则由用户粘贴的 CI 日志 ## 流程 1. **基线本地状态** - 记录 `git status --short`、当前分支和最新 commit SHA。 - 从 `git remote -v` 识别 remote URL 和 owner/repo。 - 继续之前先确认 remote 是 Gitea/Forgejo：对照已知的 Gitea 实例核对 host， 或探测 `/api/v1/version`。若 remote 是 GitHub、GitLab 或其他服务，按"不适用场景"停止。 - 收集 CI 证据期间不要修改文件。 2. **验证 Gitea 访问** - 优先运行 `fetch_ci_logs.py version` 探测实例版本并确认脚本能连通实例。脚本从 remote 推导 base URL，认证按 `GITEA_TOKEN` → 显式 `--use-git-credential` → 匿名的顺序选择。注意：`version` 只读 `/api/v1/version`，成功仅代表连通与鉴权 可用，**不代表 Actions API 一定可用**。Actions 端点是否存在需在后续 `runs`/`jobs` 步骤中实际验证；旧版 Gitea（见下）会在此才暴露 404。 - 脚本不可用时，回退到手动方式。优先使用已安装并已认证的 `tea`： - `tea login list` - 使用前先运行 `tea actions --help` 确认已安装的 `tea` 版本存在 `actions` 子命令；并非所有版本都带这些子命令。 - `tea actions runs list --status failure --branch ` - `tea actions runs view ` - `tea actions runs logs --job ` - `tea pulls view ` - 若 `tea` 不可用，或已安装版本缺少 Actions 命令，则直接使用 Gitea API。 - 当 API 行为不明确时，检查 `/api/v1/version` 和 `/swagger.v1.json`。较旧的 Gitea（1.21 及更早）在 web UI 中提供 Actions 页面，但不提供 workflow run/job/log 的 API 端点；应对照上报的版本确认可用性，而不是想当然。 - 绝不打印 token、用户名或密码。API token 只通过环境变量传递；Git 凭据只通过 `git credential fill` 的标准输入/输出在脚本进程内传递，不放入 argv。 3. **定位失败的 workflow run** - 若入口是 PR 而非 run ID，先把 PR 解析成 run：取 PR 的 head 分支与 head SHA （`fetch_ci_logs.py` 的 `runs` 支持 `--branch`/`--sha`；手动则 `GET /api/v1/repos///pulls/` 取 `head.ref`/`head.sha`）， 再按该 SHA 过滤 runs。PR 页面的 checks 列表可能聚合多个 workflow，逐一定位到 具体失败 run，不要假设只有一个。 - 优先用脚本：`fetch_ci_logs.py runs --status failure --branch ` （也支持 `--sha`/`--event`/`--limit`），已知 run ID 时用 `fetch_ci_logs.py jobs ` 直接列出各 job 并标注失败项。 - 脚本不可用时回退到手动方式。已知 run ID 时，直接获取该 run。 - 否则按分支、事件、状态或 commit SHA 过滤，列出最近的 workflow runs。 - API 模式： - `GET /api/v1/repos///actions/runs` - `GET /api/v1/repos///actions/runs/` - `GET /api/v1/repos///actions/runs//jobs` - 较旧 Gitea 的 web 回退： - `GET ///actions` - 解析 `///actions/runs/` 链接和状态标签。 - 区别对待 `failure`、`cancelled` 和缺失的必需 checks。被取消（cancelled）的 job 可能需要重跑或排查队列，而非改代码。 4. **获取 job 日志** - 优先用脚本：`fetch_ci_logs.py logs `。它把日志存到受跟踪源码路径 之外的临时文件、只回显尾部若干行，并打印临时文件路径供进一步查看 （`--tail N` 调整行数，`--json` 输出结构化结果）。 - 脚本不可用时回退到手动方式。对每个失败的 job，下载其日志： - `GET /api/v1/repos///actions/jobs//logs` - 在较旧 Gitea 的 web 回退（无 job-log API）下，按 UI 的 job index 下载日志： - `GET ///actions/runs//jobs//logs` - 先打开 run 页面读取每个 job 的状态；取状态为 `failure` 的 job 的 index， 不要默认用 index `0`。失败的 job 很少是第一个，盲目用 index `0` 通常会返回 某个通过的 job 的日志。只有当 run 页面不暴露每个 job 的状态时，才回退到逐一 扫描 index。 - 大日志保存到受跟踪源码路径之外的临时文件。 - 提取首个可操作的错误块、其上下文命令、job 名、workflow 名、run URL、分支和 SHA。 - 若日志缺失，明确报告，而不是编造原因。 5. **分类失败** - 代码/测试失败：断言失败、编译错误、lint 错误、类型错误 - 环境失败：缺失 secret、runner 镜像、依赖安装、网络、缓存、权限或服务启动 - 工作流失败：YAML 非法、语法不支持、触发条件错误、路径错误、分支/ref 假设错误 - 基础设施失败：runner 离线、队列卡住、run 被取消、超时 6. **制定修复计划** - 用确切的 job/run 标识总结失败证据。 - 提出与证据匹配的最小代码或工作流改动。 - 包含本地验证命令和远端复检路径。 - 在用户批准修复计划之前不要实施。 7. **批准后实施** - 只应用已批准的修复。 - 运行最接近复现该失败 job 的本地命令。 - 若失败仅涉及工作流，验证工作流文件语法及其引用的路径或脚本。 8. **复检** - 告诉用户需要在 Gitea 中 push 或重跑什么。 - 若获准，使用 Gitea API 检查重跑状态。 - 最终输出必须区分本地验证与远端 CI 状态。 ## 输出约定 - `Target:` 仓库、分支/SHA、PR 或 run ID - `Failed CI:` workflow、job、状态、run URL 或 API 路径 - `Evidence:` 精简的日志片段与分类 - `Plan:` 提出的修复、本地验证、远端复检 - `Changes:` 批准后改动的文件 - `Result:` 已运行的本地检查与剩余的远端状态 ## 成功标准 - 失败分析基于 Gitea Actions 的 run/job 数据或粘贴的日志 - 修复计划指明其针对的确切 workflow run 或 job - 计划批准前不发生任何代码或工作流改动 - 验证区分本地命令与远端 Gitea Actions 结果 - 不回显 token；私有日志只保留可操作的片段，不整段外泄 ## 危险信号（Red Flags） 出现以下情况说明流程走偏，停下纠正而非继续： - **凭红色状态臆测原因**：还没下载 job 日志就断言失败原因或动手改代码。 - **误读双字段结果**：把 `status`（生命周期）当成结果判定。Gitea Actions 沿用 GitHub 兼容的双字段模型——`status=completed` 只表示跑完了，真正的成败在 `conclusion`（`failure`/`success`/`cancelled`）。判定失败必须看有效结果， 而非 `status=completed` 就当通过。 - **盲取 job index `0`**：在 web 回退下不看每个 job 状态就用 index `0` 下载日志； 失败的 job 很少是第一个，通常会误取到某个通过 job 的日志。 - **把 `version` 成功当作 Actions API 可用**：`version` 只探连通与鉴权，Actions 端点可能仍返回 404（旧版 Gitea）。 - **把 `cancelled`/基础设施问题当代码 bug 修**：被取消、runner 离线、队列卡住、 超时应重跑或排查环境，不是改代码。 - **回显 token 或整段私有日志**：只保留可操作的最小片段。 - **静默读取或降级传输凭据**：Git 凭据必须由 `--use-git-credential` 显式启用； token 和 Git 凭据都不得通过 HTTP 或跨源重定向发送。 ## 失败处理 - 401 且未使用认证时，通过环境提供 `GITEA_TOKEN` 或显式传入 `--use-git-credential`；401 且已使用认证时检查凭据是否有效，不要在对话中索要 secret - 403 表示所选凭据缺少仓库或 Actions 读取权限；补足权限，而不是切换到匿名访问 - 404 优先核对 owner/repo、端点和 Gitea 版本；旧版本缺少 Actions API 时使用 web 回退 - 若 Gitea 版本缺少 Actions API 端点，请用户提供相关日志文本或从浏览器复制的 job 日志 - 若失败的 check 归属外部 CI 服务，报告外部 URL 并在证据收集处停止 - 若失败仅为基础设施问题，建议重跑/排查 runner，而非改代码