mcore-create-issue

将 CI 失败整理为 GitHub Issue

调查失败的 GitHub Actions 作业，提取根本原因，并在 NVIDIA/Megatron-LM 中提交一份结构清晰的 Bug Issue。

工作流

1. 解析 URL

参数是一个 GitHub Actions URL，形式如下之一：

• 作业 URL：https://github.com/<owner>/<repo>/actions/runs/<run_id>/job/<job_id>
• 运行 URL：https://github.com/<owner>/<repo>/actions/runs/<run_id>

提取 run_id，以及（如果存在）job_id。

2. 确定失败的作业

• 如果提供了 job_id，直接使用该作业。

• 如果只提供了 run_id，列出该运行中所有失败的作业：

  gh run view <run_id> --repo NVIDIA/Megatron-LM --json jobs \
    --jq '[.jobs[] | select(.conclusion == "failure") | {id: .databaseId, name: .name, url: .url}]'
  

  如果有多个作业失败，请询问用户要整理哪个作业；如果用户表示全部处理，则整理所有失败的作业。

3. 获取失败日志

对于每个失败的作业，获取日志并缩小范围以定位失败内容：

# Pull the raw log and keep only error-bearing lines
gh api repos/NVIDIA/Megatron-LM/actions/jobs/<job_id>/logs 2>&1 \
  | grep -E "(FAILED|ERROR|\bError\b|assert|Traceback|Exception|##\[error\])" \
  | head -200

同时获取完整的作业名称：

gh run view --job <job_id> --repo NVIDIA/Megatron-LM --json name --jq .name

如果 grep 输出内容过少，请下载完整日志，并查找 pytest 的 FAILURES 部分或最后一个非零退出信号。

4. 确定触发该运行的 PR 和测试作者

触发该运行的 PR：运行的 head 分支遵循 pull-request/<number> 格式。 提取编号并解析该 PR：

gh run view <run_id> --repo NVIDIA/Megatron-LM --json headBranch --jq .headBranch
# → e.g. "pull-request/4332"
# Extract PR number and fetch metadata:
gh pr view <pr_number> --repo NVIDIA/Megatron-LM --json number,title,url \
  --jq '{number: .number, title: .title, url: .url}'

测试文件作者：查找最后一次修改失败测试文件的 GitHub 登录名。该文件可能不存在于 main 上——先确定 PR 的基础分支，再从该分支开始搜索：

# 1. Get the PR's base branch (e.g. "main", "dev", "release/X.Y")
gh pr view <pr_number> --repo NVIDIA/Megatron-LM --json baseRefName --jq .baseRefName

# 2. Search commits on that base branch
gh api "repos/NVIDIA/Megatron-LM/commits?path=<test-file-path>&sha=<base-branch>&per_page=1" \
  --jq '.[0] | {login: .author.login, name: .commit.author.name, sha: .sha}'

如果结果为空（文件由 PR 本身引入），则查询该 PR 的提交：

gh api "repos/NVIDIA/Megatron-LM/pulls/<pr_number>/commits" \
  --jq '[.[] | select(.files? // [] | any(.filename == "<test-file-path>"))] | .[0].author.login'

如果以上方法都无效，则列出 PR 的提交，并选择提交消息与失败测试文件最相关的提交作者。

5. 提取根本原因

从日志中确定：

• 失败的测试：匹配 FAILED tests/...::... 的行会给出准确的 pytest 节点 ID。
• 错误消息：断言失败、异常类型或第一个有意义的回溯帧——最多保留约 30 行。
• 作业名称：GitHub Actions 作业名称（例如 tests/unit_tests/transformer/moe/**/*.py - latest）。
• 运行 / 作业 URL 和 PR URL：用于在 Issue 中添加链接。

6. 检查是否存在重复 Issue

搜索是否已有涵盖相同测试的开放 Issue：

gh issue list --repo NVIDIA/Megatron-LM \
  --state open \
  --search "<failed-test-filename>" \
  --json number,title,url \
  --limit 10

• 如果存在匹配的开放 Issue，不要创建新的 Issue。向用户报告已有 Issue，然后停止。
• 如果未找到匹配项，则继续提交新的 Issue。

7. 创建 Issue

传入 --assignee <test-author-login>，将 Issue 指派给测试文件的作者。在 Issue 正文中包含触发该运行的 PR URL。

gh issue create \
  --repo NVIDIA/Megatron-LM \
  --title "🐛 CI failure: <failed-test-node-id>" \
  --label "bug" \
  --assignee "<test-author-login>" \
  --body "..."

使用 Bug 报告模板的正文结构：

**Describe the bug**

CI test `<failed-test-node-id>` failed in job [`<job-name>`](<job-url>).
Tag @NVIDIA/mcore-oncall to get oncall's attention to this issue.

**Failing run**

| Field | Value |
|-------|-------|
| PR    | [#<pr_number>: <pr_title>](<pr_url>) |
| Run   | [<run_id>](<run_url>) |
| Job   | [<job_name>](<job_url>) |

**Error**

<核心错误消息 / 回溯——最多 30 行>

**Steps/Code to reproduce bug**

Re-run the failing CI job linked above, or locally inside the dev container:

```bash
pytest <failed-test-node-id>

其他上下文

通过 /triage-issue 自动整理。

If multiple tests failed in the same job, list each one as a separate bullet
under "Describe the bug" and include the combined error snippets. Assign the
issue to the author of whichever test file appears first in the failure list.

### 8. Report back to the user

Print the URL of the newly created issue (or the duplicate, if found) so the
user can review or share it.

## Important guidelines

- Never create an issue if a duplicate already exists — link the existing one instead.
- Always include the triggering PR link in the issue body.
- Always assign the issue to the test file's most recent author. If the author
  lookup fails (e.g. the commit was made by a bot or the login is unavailable),
  skip `--assignee` and note it in the "Additional context" section.
- Keep the error snippet concise (≤30 lines). Truncate long tracebacks and note that the full log is available via the job URL.
- Do not guess the root cause — quote the actual log output verbatim.
- If the job is still in progress or the logs are unavailable, say so and ask the user to retry once the run completes.