1. Vue d’ensemble du processus
- 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.
- L’action GitLab est déclenchée : L’ouverture de la PR déclenche automatiquement un workflow GitHub Actions.
- 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.
- 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.
- 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
- 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 Devin et les autres outils intégrés.
- Tester l’intégration
- Afficher la page des sessions Devin
Ceci suppose que vous disposez d’un fichier de propriétés SonarCloud local
sonar-project.properties qui indique :La réponse de session v1 indique la progression via
status_enum. Une session qui se termine normalement renvoie finished ; blocked et expired sont des statuts terminaux qui nécessitent une intervention humaine. Consultez Récupérer les détails d’une session existante pour la liste complète des valeurs.



