mcore-create-issue

CI の失敗をトリアージして GitHub Issue を作成する

失敗した GitHub Actions ジョブを調査し、根本原因を特定して、NVIDIA/Megatron-LM に適切な形式のバグ報告 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 が見つからない場合は、新しい Issue の作成に進みます。

7. Issue を作成する

--assignee <test-author-login> を指定して、テストファイルの作成者を担当者に設定します。Issue の本文にトリガーとなった PR の URL を含めます。

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

バグ報告テンプレートの本文構成を使用します。

**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**

<core error message / traceback — 30 lines max>

**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.