Skip to Content
デベロッパーガイドDevelopmentIssue および PR の自動化

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

本ドキュメントでは、Issue と Pull Request の管理・トリアージに使用する自動化プロセスの詳細を説明します。目標は迅速なフィードバックを提供し、コントリビューションが効率的にレビューおよびマージされるようにすることです。この自動化を理解することで、コントリビューターは何を期待すべきか、リポジトリボットとどのようにやり取りすればよいかを把握できます。

基本原則：Issue と Pull Request

まず第一に、ほとんどの Pull Request（PR）は、対応する Issue にリンクされている必要があります。Issue は「何を」「なぜ」（バグや機能）を説明し、PR は「どのように」（実装）を説明します。この分割により、作業の追跡、機能の優先順位付け、明確な履歴コンテキストの維持が容易になります。私たちの自動化はこの原則に基づいて構築されています。

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

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

1. Issue を作成した場合：Qwen Triage

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

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

2. Pull Request をオープンした場合：継続的インテグレーション (CI)

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

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

3. リリース自動化

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

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

この詳細な概要がお役に立てば幸いです。自動化やプロセスについてご質問があれば、遠慮なくお問い合わせください！

Last updated on
統合テストQwen Code 拡張機能