Skip to main content
Devin の API は強力なツールです。このガイドを読み進める前に、まず次の記事をお読みください。

1. プロセス概要

  1. Pull Request が作成される: コードスキャンツールによって問題が検出された可能性のある変更を含む Pull Request (PR) がリポジトリに送信されます。
  2. GitLab Action がトリガーされる: PR のオープンによって、自動的に GitLab Action ワークフローがトリガーされます。
  3. GitLab Action が Devin API を呼び出す: GitLab Action が Devin API にリクエストを送り、検出された問題を自動解決のために渡します。
  4. Devin セッションが初期化される: Devin セッションが起動し、問題のコンテキストを受け取り、提供されたデータに基づいて解決を試みます。
  5. Devin が人間によるレビュー用の PR を提案する: 問題が解決されると、Devin は提案された変更を含む PR を作成し、人間によるレビューのために送信します。

2. この手順を完了するためのステップ

  1. 必要なシークレットを保持するために GitLab 環境を構成する:
    • Devin の API やその他の連携ツールとやり取りするために必要な認証トークンや設定キーなどのシークレットを安全に保存できるよう、GitLab 環境を設定します。
これらの手順が完了すると、パイプラインは Devin の API を使用して問題を自動的に解決できるようになり、処理の高速化と手動対応の削減につながります。
  1. 連携をテストする
セットアップが完了したら、GitLab Action を手動でトリガーして連携をテストできます。これにより、Action が正しく Devin API を呼び出し、検出された問題を解決できているかを検証できます。
  1. Devin Sessions ページを参照する
GitLab Build がトリガーされ、Devin が問題を処理した後は、Devin の Sessions ページでステータスと結果を確認できます。このページでは、解決された問題の詳細や、提案された変更内容を確認できます。 前述のとおり、SonarQube から取得する必要がある値は次のとおりです。 連携を構成するには、次の 3 つの値を SonarQube インスタンスから取得する必要があります: SonarQube から three_values が必要です: {SONAR_TOKEN, SONAR_ORG, SONAR_PROJECT_KEY} すべての必要な値がそろったら、GitLab Action を構成する準備が整います。
これは、sonar-project.properties というローカルの SonarCloud プロパティファイルがあり、そこで次の内容が指定されていることを前提としています:
GitLab Action のソースコードは次のとおりです。
おさらいとして、devin_remediation.py は次のとおりです。
v1 のセッションレスポンスは、進行状況を status_enum で報告します。正常に完了したセッションは finished を報告し、blockedexpired は人による対応が必要な終了ステータスです。値の一覧については 既存セッションの詳細を取得する を参照してください。
GitLab Action が正しい環境変数を設定できるようにするには、それらを GitLab CI/CD Variables に追加します。 目的の設定画面へ移動するのは少し分かりにくい場合があります。Settings > CI/CD に移動し、Variables を展開します。Project variables のセクションに SONAR_TOKENSONAR_ORGDEVIN_API_KEY を追加します。変数名は、上記のパイプライン設定で参照されているものと一致している必要があります。
SonarQube
セルフホスト型の GitLab を使用している場合、異なる点は次のとおりです。 設定が完了すると、実行中の GitLab Action を監視できます。正常に実行されると、次のように表示されます。
SonarQube
Devin セッションは Session Manager で閲覧できます。
SonarQube
完了すると、Devin は自動的にプルリクエストを作成します。GitLab を利用する場合は、リンク先のガイドを参照してください。