Skip to main content
L’API de Devin est un outil puissant, veuillez lire l’article suivant avant de poursuivre ce guide.

1. Vue d’ensemble du processus

  1. La Pull Request est ouverte : Une Pull Request (PR) est soumise au dépôt avec des modifications qui peuvent contenir des problèmes identifiés par un outil d’analyse de code.
  2. L’action GitLab est déclenchée : L’ouverture de la PR déclenche automatiquement un workflow GitHub Actions.
  3. L’action GitLab appelle l’API Devin : La GitHub Action envoie une requête à l’API Devin, en lui transmettant les problèmes identifiés pour qu’ils soient résolus automatiquement.
  4. La session Devin est initialisée : Une session Devin est lancée, reçoit le contexte du problème et tente de le résoudre à partir des données fournies.
  5. Devin propose une PR pour revue humaine : Une fois le problème résolu, Devin génère une PR avec les modifications proposées et la soumet pour revue humaine.

2. Étapes pour y parvenir

  1. Configurer l’environnement GitLab pour héberger les secrets requis :
    • Configurez l’environnement GitLab pour stocker en toute sécurité les secrets nécessaires, comme les jetons d’authentification et les clés de configuration, afin d’interagir avec l’API de Devin et les autres outils intégrés.
Une fois ces étapes terminées, votre pipeline sera prêt à résoudre automatiquement les problèmes à l’aide de l’API de Devin, ce qui accélérera le processus et réduira le besoin d’intervention manuelle.
  1. Tester l’intégration
Une fois la configuration terminée, vous pouvez tester l’intégration en déclenchant manuellement une action GitLab. Cela vous permettra de vérifier que l’action appelle correctement l’API Devin et résout les problèmes identifiés.
  1. Afficher la page des sessions Devin
Après le déclenchement du GitLab Build et le traitement des problèmes par Devin, vous pouvez consulter l’état et les résultats sur la page des sessions Devin. Cette page fournit des informations détaillées sur les problèmes résolus et les modifications proposées. Comme mentionné précédemment, les valeurs requises provenant de SonarQube sont : Pour configurer l’intégration, vous devrez obtenir les trois valeurs suivantes depuis votre instance SonarQube : Vous aurez besoin de three_values from SonarQube : {SONAR_TOKEN, SONAR_ORG, SONAR_PROJECT_KEY} Une fois que vous disposez de toutes les valeurs requises, vous êtes prêt à configurer l’action GitLab.
Ceci suppose que vous disposez d’un fichier de propriétés SonarCloud local sonar-project.properties qui indique :
L’action GitLab a le code source suivant
Pour rappel, voici devin_remediation.py :
Pour garantir que l’Action GitLab définit les bonnes variables d’environnement, ajoutez-les aux GitLab CI/CD Secrets. Accéder aux bons paramètres peut être délicat. Allez dans Settings et modifiez Secrets. Ajoutez SONAR_TOKEN et DEVINS_API sous Repository Secrets.
SonarQube
Si vous utilisez une instance GitLab auto-hébergée, la seule différence est la suivante : Une fois configurée, vous pouvez surveiller l’exécution de votre GitLab Action. Si elle s’exécute correctement, elle apparaîtra comme suit :
SonarQube
Vous pouvez consulter les sessions Devin dans le Session Manager.
SonarQube
Une fois l’opération terminée, Devin ouvrira automatiquement des pull requests (PR). Pour les utilisateurs de GitLab, reportez-vous au guide associé.