自動化とトリアージプロセス

このドキュメントでは、イシューとプルリクエストを管理・トリアージするために使用している自動化プロセスについて詳しく説明します。私たちの目標は、迅速なフィードバックを提供し、コントリビューションが効率的にレビュー・統合されるようにすることです。この自動化の仕組みを理解することで、コントリビューターとしてのあなたが何を期待すべきか、そしてリポジトリのボットとどうやってうまくやり取りできるかが分かるようになります。

基本原則：イシューとプルリクエスト

まず最初に重要なのは、ほぼすべてのプルリクエスト（PR）は対応するイシューにリンクされているべきだということです。イシューには「何をするのか」と「なぜそれをするのか」（バグや機能）が記述され、プルリクエストは「どのように実装するか」を示します。この分離により、作業の追跡、機能の優先順位付け、明確な履歴の維持が可能になります。私たちの自動化はこの原則に基づいて構築されています。

詳細な自動化ワークフロー

以下は、私たちのリポジトリで実行されている具体的な自動化ワークフローの内訳です。

1. Issue を作成するとき：Automated Issue Triage

これは、Issue を作成した際に最初にやり取りするボットです。このボットの役割は、初期分析を実行し、適切なラベルを適用することです。

• ワークフローファイル: .github/workflows/qwen-automated-issue-triage.yml
• 実行タイミング: Issue が作成または再オープンされた直後。
• 処理内容:
  • Qwen モデルを使用して、Issue のタイトルと本文を詳細なガイドラインに基づいて分析します。
  • area/* ラベルを 1 つ適用: Issue をプロジェクトの機能領域（例: area/ux、area/models、area/platform）に分類します。
  • kind/* ラベルを 1 つ適用: Issue の種類（例: kind/bug、kind/enhancement、kind/question）を識別します。
  • priority/* ラベルを 1 つ適用: 説明された影響度に基づき、優先度を P0（クリティカル）から P3（低）まで割り当てます。
  • status/need-information を適用する場合があります: Issue に重要な情報（ログや再現手順など）が不足している場合、追加情報の提供を求めるフラグが立てられます。
  • status/need-retesting を適用する場合があります: Issue で参照されている CLI のバージョンが 6 世代以上古い場合、現在のバージョンでの再テストを求めるフラグが立てられます。
• あなたがすべきこと:
  • Issue テンプレートにできるだけ詳細に記入してください。提供される情報が多いほど、トリアージの精度が向上します。
  • status/need-information ラベルが追加された場合は、コメント欄に要求された情報を提供してください。

2. プルリクエストを開いたとき: Continuous Integration (CI)

このワークフローは、すべての変更がマージされる前に品質基準を満たしていることを保証します。

• ワークフローファイル: .github/workflows/ci.yml
• 実行タイミング: プルリクエストへのプッシュごとに実行されます。
• 実行内容:
  • Lint: コードがプロジェクトのフォーマットおよびスタイルルールに従っているかをチェックします。
  • Test: macOS、Windows、Linux および複数の Node.js バージョンで自動テストスイート全体を実行します。これは CI プロセスの中で最も時間がかかる部分です。
  • Post Coverage Comment: すべてのテストが正常にパスした後、ボットが PR にコメントを投稿します。このコメントには、変更がテストによってどれだけカバーされているかの概要が記載されています。
• あなたがすべきこと:
  • すべての CI チェックがパスすることを確認してください。すべてが成功すると、コミットの横に緑色のチェックマーク ✅ が表示されます。
  • チェックが失敗した場合（赤い「X」❌）、失敗したチェックの横にある「Details」リンクをクリックしてログを確認し、問題を特定して修正をプッシュしてください。

3. プルリクエストの継続的なトリアージ: PR 監査とラベル同期

このワークフローは定期的に実行され、すべてのオープンなプルリクエストが正しくイシューにリンクされており、一貫したラベルが付与されていることを確認します。

• ワークフローファイル: .github/workflows/qwen-scheduled-pr-triage.yml
• 実行タイミング: すべてのオープンなプルリクエストに対して15分ごとに実行されます。
• 処理内容:
  • リンクされたイシューの確認: ボットはプルリクエストの説明文をスキャンし、イシューにリンクするキーワード（例: Fixes #123、Closes #456）を探します。
  • status/need-issue の追加: リンクされたイシューが見つからない場合、ボットはプルリクエストに status/need-issue ラベルを追加します。これは、イシューを作成してリンクする必要があることを明確に示すサインです。
  • ラベルの同期: イシューがリンクされている場合、ボットはプルリクエストのラベルがイシューのラベルと完全に一致するようにします。不足しているラベルがあれば追加し、不要なラベルは削除します。また、以前に付与されていた場合は status/need-issue ラベルも削除されます。
• あなたがすべきこと:
  • 常にプルリクエストをイシューにリンクしてください。 これが最も重要なステップです。プルリクエストの説明文に Resolves #<issue-number> のような行を追加してください。
  • これにより、プルリクエストが正しく分類され、レビュープロセスがスムーズに進むようになります。

4. 問題の継続的トリアージ: Scheduled Issue Triage

これは、トリアージプロセスによって問題が見逃されることがないようにするためのフォールバックワークフローです。

• ワークフローファイル: .github/workflows/qwen-scheduled-issue-triage.yml
• 実行タイミング: すべての未解決の問題に対して1時間ごとに実行されます。
• 処理内容:
  • ラベルがまったくない、またはまだ status/need-triage ラベルがついている問題を積極的に検索します。
  • 次に、初期トリアージボットと同じ強力な QwenCode ベースの分析をトリガーして、正しいラベルを適用します。
• あなたがすべきこと:
  • 通常は何もする必要はありません。このワークフローは、初期トリアージが失敗した場合でも、すべての問題が最終的に分類されることを保証するための安全装置です。

5. リリース自動化

このワークフローは、Qwen Code の新しいバージョンをパッケージ化し、公開するプロセスを処理します。

• ワークフローファイル: .github/workflows/release.yml
• 実行タイミング: 「ナイトリー」リリースのための日次スケジュール、および公式のパッチ/マイナー リリースのための手動実行。
• 処理内容:
  • プロジェクトを自動的にビルドし、バージョン番号を更新して、npm にパッケージを公開します。
  • 自動生成されたリリースノートとともに、GitHub に対応するリリースを作成します。
• あなたがすべきこと:
  • コントリビューターとして、このプロセスに対して何もする必要はありません。PR が main ブランチにマージされると、あなたの変更が次のナイトリー リリースに確実に含まれることを安心してください。

この詳細な概要が役立つことを願っています。自動化やプロセスについて質問がある場合は、遠慮なくお尋ねください！