自動化およびトリアージプロセス

このドキュメントでは、課題（Issues）およびプルリクエスト（Pull Requests）の管理・トリアージに使用している自動化プロセスについて、詳細な概要を提供します。私たちの目標は、迅速なフィードバックを提供し、貢献された内容が効率的にレビュー・統合されることを保証することです。この自動化プロセスを理解することで、貢献者として何が期待されるか、またリポジトリ内のボットとどのように最適に連携するかを把握できます。

ガイドラインの原則：課題とプルリクエスト

まず第一に、ほぼすべてのプルリクエスト（PR）は、対応する課題（Issue）にリンクされるべきです。課題は「何を」および「なぜ」行うのか（バグまたは新機能）を記述し、一方で PR は「どのように」実装するのか（実装方法）を示します。この分離により、作業の追跡、機能の優先順位付け、および明確な履歴的文脈の維持が可能になります。当社の自動化は、この原則に基づいて構築されています。

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

以下に、当リポジトリ内で実行される具体的な自動化ワークフローをまとめます。

1. イシューオープン時：自動イシュートライアージ

これは、イシューを作成した際に最初に動作するボットです。その役割は、初期分析を実行し、適切なラベルを適用することです。

• ワークフローファイル: .github/workflows/qwen-automated-issue-triage.yml
• 実行タイミング: イシューが作成された直後、または再オープンされた直後。
• 処理内容:
  • 詳細なガイドラインに基づき、Qwen モデルを用いてイシューのタイトルと本文を分析します。
  • 1つの area/* ラベルを適用: イシューをプロジェクトの機能領域（例：area/ux、area/models、area/platform）に分類します。
  • 1つの kind/* ラベルを適用: イシューの種別（例：kind/bug、kind/enhancement、kind/question）を特定します。
  • 1つの priority/* ラベルを適用: 記述された影響度に基づき、P0（緊急）から P3（低）までの優先度を割り当てます。
  • 必要に応じて status/need-information ラベルを適用: イシューに重要な情報（例：ログや再現手順）が不足している場合、追加情報の提供を依頼するためにこのラベルが付与されます。
  • 必要に応じて status/need-retesting ラベルを適用: イシューで言及されている CLI のバージョンが、現在の最新版から6つ以上古い場合、最新版での再テストを依頼するためにこのラベルが付与されます。
• あなたがすべきこと:
  • イシューテンプレートを可能な限り完全に記入してください。記載する情報が詳細であるほど、トライアージの精度が向上します。
  • status/need-information ラベルが付与された場合は、コメントで依頼された情報をご提供ください。

2. プルリクエストを開いたとき：継続的インテグレーション（CI）

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

• ワークフローファイル: .github/workflows/ci.yml
• 実行タイミング: プルリクエストへのすべてのプッシュ時。
• 実行内容:
  • Lint（コードチェック）: コードがプロジェクトのフォーマットおよびスタイル規則に準拠しているかを検証します。
  • テスト: macOS、Windows、Linux の各プラットフォームおよび複数の Node.js バージョンで、自動化されたテストスイート全体を実行します。これは CI プロセスの中で最も時間がかかる工程です。
  • カバレッジコメントの投稿: すべてのテストが正常に完了した後、ボットがプルリクエストにコメントを投稿します。このコメントには、変更内容がテストによってどの程度網羅されているかの概要が示されます。
• あなたが行うべきこと:
  • すべての CI チェックが成功することを確認してください。すべてが正常に完了すると、コミットの横に緑色のチェックマーク ✅ が表示されます。
  • チェックが失敗した場合（赤色の「X」❌）、失敗したチェックの横にある「Details（詳細）」リンクをクリックしてログを確認し、問題を特定して修正をプッシュしてください。

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

このワークフローは定期的に実行され、すべてのオープン状態のプルリクエスト（PR）が適切にイシューと関連付けられ、一貫したラベルが付与されていることを保証します。

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

4. 問題の継続的なトリアージ：定期実行型問題トリアージ

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

• ワークフローファイル: .github/workflows/qwen-scheduled-issue-triage.yml
• 実行タイミング: すべてのオープン状態の問題に対して毎時実行されます。
• 処理内容:
  • ラベルが一切付与されていない問題、または依然として status/need-triage ラベルが付与されている問題を積極的に検出します。
  • その後、初期トリアージボットと同様に、QwenCode を活用した強力な分析を実行し、適切なラベルを適用します。
• あなたが行うべきこと:
  • 特に何もする必要はありません。このワークフローは、初期トリアージが失敗した場合でも、すべての問題が最終的に分類されるよう保証するための安全網です。

5. リリースの自動化

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

• ワークフローファイル: .github/workflows/release.yml
• 実行タイミング: 「nightly」リリース向けには毎日スケジュール実行され、正式なパッチ／マイナーリリース向けには手動で実行されます。
• 実行内容:
  • プロジェクトを自動的にビルドし、バージョン番号を更新して、npm にパッケージを公開します。
  • 生成されたリリースノートとともに、GitHub 上に対応するリリースを作成します。
• 貢献者としての対応:
  • 貢献者の方は、このプロセスに関して特に何もする必要はありません。プルリクエスト（PR）が main ブランチにマージされれば、その変更は次の nightly リリースに確実に含まれます。

この詳細な概要が役立つことを願っています。当社の自動化やプロセスについてご質問がございましたら、遠慮なくお尋ねください！