Intégration GitHub de Devin

Pourquoi intégrer Devin à GitHub ?

Intégrer Devin à votre organisation GitHub permet à Devin de créer des pull requests, de répondre aux commentaires sur les PR et de collaborer directement au sein de vos dépôts. Devin peut ainsi devenir un véritable collaborateur au sein de votre équipe d’ingénieurs. Pour commencer, ouvrez Settings → Connections → GitHub, cliquez sur Add Connection et suivez les instructions. Vous choisirez à quels dépôts Devin peut accéder et passerez en revue les autorisations requises.

Vous utilisez GitHub Enterprise Server ou GitHub Enterprise Cloud avec Data Residency ? Consultez le guide d’intégration GitHub Enterprise Server pour obtenir des instructions de configuration.

Configuration de l’intégration

Vous devez être administrateur de votre organisation GitHub pour créer et gérer l’intégration Devin. Vous rencontrez des difficultés ? Consultez notre page Problèmes courants.

Dans votre compte Devin, ouvrez Settings → Connections → GitHub et cliquez sur Add Connection.

Si vous n’êtes pas déjà connecté à GitHub, vous serez invité à vous authentifier.

Sélectionnez l’organisation GitHub que vous souhaitez connecter à Devin.

Choisissez d’accorder à Devin l’accès à All repositories ou Select repositories afin de contrôler à quels dépôts Devin peut accéder.

Une fois l’autorisation GitHub terminée, vous serez redirigé vers les paramètres de Devin, où vous pourrez confirmer que l’intégration est active.

Nous vous recommandons d’activer des règles de protection de branche sur votre branche principale afin de garantir que tous les checks requis sont effectués avant que Devin ne puisse fusionner des modifications.

Utiliser Devin avec l’intégration GitHub

Pour les utilisateurs Core et Teams

Une fois l’intégration configurée, vous pouvez @mentionner des dépôts directement dans vos messages au sein de l’application web Devin.

Pour les utilisateurs Enterprise

Une fois l’intégration configurée, vous pouvez déléguer des repositories à des organisations spécifiques depuis Settings > Repositories.

Si vous travaillez avec un repository pour la première fois, nous vous recommandons de suivre la configuration de l’environnement de développement dans le parcours d’onboarding afin de garantir que Devin dispose d’informations exactes et à jour sur votre base de code. Devin répond automatiquement aux commentaires sur les PR sur lesquelles ses sessions travaillent, tant que la session n’a pas été archivée. Pour démarrer une nouvelle session depuis n’importe quelle PR, consultez Démarrer Devin depuis un commentaire sur les PR.

Lancer Devin depuis un commentaire sur les PR

Vous pouvez confier des tâches à Devin sans quitter GitHub. Sur n’importe quelle pull request ouverte d’un repository connecté à Devin, publiez un commentaire commençant par /devin, suivi de ce que vous souhaitez faire réaliser :

/devin fix the failing lint check and push a commit

Devin démarre une nouvelle session avec ce repository, utilise la PR comme contexte (en reprenant la PR si pertinent) et répond sur la PR avec un lien vers la session.

Commentaire	Ce qui se passe
`/devin <prompt>`	Démarre une session Devin pour la PR avec votre prompt
`/devin review`	Démarre une Devin Review de la PR
`/devin`	Devin répond avec les instructions d’utilisation

Prérequis :

Début du commentaire — la commande doit figurer en début de commentaire. Elle est insensible à la casse et fonctionne aussi bien dans les commentaires de conversation de PR que dans les review comments inline.
PR ouvertes uniquement — les commentaires sur des problèmes, ou sur des PR fermées ou mergées, sont ignorés.
Accès en écriture — l’auteur du commentaire doit disposer de l’autorisation write ou admin sur le repository.
Compte lié — le GitHub account de l’auteur du commentaire doit être lié à son Devin account, et celui-ci doit être member d’une organisation Devin ayant accès au repository ainsi que l’autorisation d’utiliser les sessions Devin.

Si une session Devin travaille déjà sur la PR, les commentaires /devin sont transmis à cette session au lieu d’en démarrer une nouvelle.

Association des utilisateurs

La connexion via l’application GitHub décrite ci-dessus s’applique à l’ensemble de l’organisation. En complément, chaque utilisateur peut associer son propre compte GitHub à Devin afin que Devin agisse sous son identité : les pull requests que Devin ouvre dans ses sessions lui sont attribuées, et les commentaires ou revues qu’il soumet via Devin Review apparaissent sous son compte GitHub. Pour associer un compte GitHub personnel :

Rendez-vous dans Settings > Connections depuis les paramètres de votre compte personnel
Repérez la ligne GitHub dans la liste des comptes
Cliquez sur Link et finalisez l’autorisation GitHub

Pour supprimer l’association par la suite, cliquez sur Unlink user sur la même ligne. Devin révoque alors le token OAuth auprès de GitHub.

La ligne GitHub n’apparaît que si votre organisation dispose d’une connexion GitHub. Si elle est absente, vérifiez que vous êtes membre d’une organisation Devin dont l’intégration GitHub est configurée. Les instances GitHub Enterprise Server apparaissent sur des lignes GitHub Enterprise distinctes, identifiées par leur hôte, et s’associent de la même manière.

Pour que Devin ouvre les pull requests au nom de l’utilisateur associé, un administrateur doit également définir Open PRs as dans Settings > Devin > Pull requests :

Devin : ouvre toujours les pull requests en tant que Devin
User : ouvre en tant qu’utilisateur si son compte git est associé, sinon en tant que Devin
User only : ouvre en tant qu’utilisateur, et échoue si son compte git n’est pas associé (les automatisations et les utilisateurs de service basculent malgré tout sur Devin)

Deux paramètres connexes se trouvent dans cette même section Pull requests :

Allow PRs to be opened by session participants : permet à Devin d’ouvrir une PR au nom de toute personne ayant contribué à la session, et pas seulement de celle qui l’a lancée.
Require session access for PR comments : les commentaires sur les PR ne sont transmis à une session Devin que si leur auteur a accès à cette session. Les Enterprise Admin peuvent imposer ce paramètre à toutes les organisations.

Gestion des autorisations de Devin dans GitHub

Lors de la configuration, vous pouvez accorder à Devin l’accès à tous les repositories de votre organisation ou restreindre l’accès à certains repositories spécifiques. Vous pouvez ajuster l’accès aux repositories à tout moment via les paramètres de GitHub :

Pour votre organisation GitHub, accédez à Settings > GitHub Apps (par exemple, https://github.com/organizations/<org_name>/settings/installations)
Sélectionnez Configure pour l’intégration Devin.ai
Sous Repository access, choisissez d’accorder l’accès à tous les repositories ou uniquement à certains repositories
Cliquez sur Save pour appliquer vos modifications

Devin a besoin des autorisations suivantes : Accès en lecture à :

Autorisation	Description
`dependabot alerts`	Permet à Devin de résoudre les alertes Dependabot en votre nom (c.-à-d. mettre à jour les versions de dépendances)
`deployments`	Permet à Devin de voir quelles versions d’un repository ont été déployées
`metadata`	Permet à Devin de consulter les métadonnées cruciales d’un repository, par exemple qui en est propriétaire
`packages`	Permet à Devin de voir quelles versions d’un repository ont été publiées sous forme de package
`pages`	Permet à Devin de consulter les pages associées à un repository, par exemple pour voir la documentation
`repository security advisories`	Permet à Devin de consulter les avis de sécurité liés à un repository afin d’aider à corriger les problèmes de sécurité
`members`	Permet à Devin de consulter les membres et les équipes d’une organisation, notamment pour la synchronisation des équipes GitHub
`organization administration`	Permet à Devin de lire les paramètres de l’organisation, comme l’autorisation par défaut sur les repositories, utilisés pour la synchronisation des équipes GitHub
`custom organization roles`	Permet à Devin de lire les rôles personnalisés de l’organisation, utilisés pour la synchronisation des équipes GitHub
`code scanning alerts`	Permet à Devin de consulter les alertes d’analyse de code d’un repository afin d’aider à les corriger
`secret scanning alerts`	Permet à Devin de consulter les alertes d’analyse des secrets d’un repository afin d’aider à les corriger
`webhooks`	Permet à Devin de consulter les hooks configurés pour un repository, par exemple pour le linting et la vérification de types

Accès en lecture et en écriture à :

Autorisation	Description
`actions`	Permet à Devin de consulter les actions configurées pour un repository afin de comprendre si les changements de Devin passent la CI, et de relancer des workflows
`checks`	Permet à Devin de consulter et de reporter les résultats des checks pour un repository afin de comprendre et de communiquer si les changements de Devin passent la CI
`commit statuses`	Permet à Devin de consulter et de définir les statuts de commit afin d’indiquer si un commit passe la CI
`contents`	Permet à Devin de contribuer à la base de code
`discussions`	Permet à Devin de contribuer aux discussions
`issues`	Permet à Devin d’ouvrir de nouveaux tickets/issues
`pull requests`	Permet à Devin de créer de nouvelles PR
`projects`	Permet à Devin de consulter et de gérer les projets associés à un repository, par exemple pour récupérer des informations sur une tâche
`workflows`	Permet à Devin de configurer de nouveaux workflows, par exemple pour aider à configurer la CI/CD

Ces autorisations permettent à Devin de travailler dans vos repositories comme un contributeur classique — en poussant de nouvelles branches, en ouvrant des pull requests et en participant aux discussions de PR.

Lorsque l’application GitHub de Devin demande de nouvelles autorisations, GitHub envoie un e-mail aux administrateurs de votre organisation pour qu’ils les approuvent dans les paramètres d’installation. D’ici là, Devin continue de fonctionner avec les autorisations déjà accordées.

Modèles de pull request

Lorsque Devin crée une pull request, il utilise un modèle provenant de votre dépôt pour structurer la description de la pull request. Si vous fournissez un modèle, Devin en suit le format lorsqu’il soumet des PR sur GitHub.

Modèle spécifique à Devin (recommandé)

Vous pouvez fournir à Devin son propre modèle sans modifier votre modèle par défaut destiné aux humains en ajoutant un fichier nommé devin_pr_template.md dans l’un des emplacements PULL_REQUEST_TEMPLATE pris en charge ci-dessous. C’est utile si vous souhaitez que Devin ajoute un contexte supplémentaire, comme une checklist de relecture ou un diagramme Mermaid des fichiers modifiés.

Ordre de recherche des modèles

Devin recherche les modèles dans l’ordre suivant et utilise le premier trouvé :

PULL_REQUEST_TEMPLATE/devin_pr_template.md
docs/PULL_REQUEST_TEMPLATE/devin_pr_template.md
.github/PULL_REQUEST_TEMPLATE/devin_pr_template.md
pull_request_template.md
docs/pull_request_template.md
.github/pull_request_template.md

Si aucun modèle n’est trouvé, Devin utilise son format par défaut pour la description de PR.

Si vous voulez que Devin utilise votre pull_request_template.md existant, copiez-le ou créez un lien symbolique vers l’un des chemins devin_pr_template.md listés ci-dessus.

Pour plus d’informations sur les modèles de pull request GitHub (emplacements pris en charge, modèles multiples, paramètres de requête, etc.), consultez la documentation GitHub : Creating a pull request template for your repository.

Signature des commits

Pour signer les commits de Devin avec GPG, configurez la clé dans votre environnement afin qu’elle soit conservée d’une session à l’autre. Générer la clé dans un terminal de session ne fonctionnera pas — chaque session Devin démarre à partir d’une nouvelle copie de l’image de la machine ; toute clé créée pendant la session est donc supprimée à la fin de celle-ci.

La signature GPG via la configuration de l’environnement ne produit des commits Verified que lorsque Devin est le committer. GitHub vérifie les signatures par rapport à l’adresse e-mail du committer, mais dans tout mode Commit authoring où le committer est l’utilisateur à l’origine de la demande (“Co-authored (you + Devin)”, “You only”, “Devin as author, you as committer”), Devin effectue les commits en utilisant l’adresse e-mail propre à chaque utilisateur comme committer — ce qui ne correspondra pas à une clé GPG partagée unique. Avant de vous appuyer sur cette configuration, demandez à un enterprise admin de définir Commit authoring dans Enterprise Settings > Devin > Git commit attribution sur “Devin only”, “Co-authored (Devin + you)” ou “You as author, Devin as committer”. Ce paramètre à l’échelle de l’entreprise prévaut sur la préférence personnelle Git commit author de chaque utilisateur ; tant qu’il reste sur Per-user (Default), c’est le choix propre à chaque utilisateur dans Settings > Preferences qui s’applique. Si votre organisation ne fait pas partie d’une entreprise, il n’existe aucun contrôle à l’échelle de l’organisation : chaque utilisateur qui démarre des sessions Devin doit définir sa préférence personnelle Git commit author dans Settings > Preferences sur l’un de ces modes.

Configurez cela à l’échelle de l’organisation (ou au niveau Enterprise, si toutes vos organisations en ont besoin) afin que chaque dépôt reçoive une configuration de signature des commits :

Créez (ou choisissez) un compte utilisateur GitHub dédié qui possédera à la fois l’identité d’auteur des commits et les identifiants utilisés par Devin pour effectuer les pushs — p. ex., devin@company.com. Utiliser un seul compte pour les deux simplifie la configuration de la signature ; en utiliser deux répartit la configuration décrite ci-dessous entre les deux.
Générez localement une clé GPG avec l’adresse e-mail de ce compte comme UID, en suivant les instructions de GitHub.
Téléversez la clé publique sur le compte GitHub dont l’adresse e-mail vérifiée correspond à l’UID GPG, dans GitHub Settings > SSH and GPG keys. GitHub vérifie les signatures par rapport à l’identité du committer, et non à l’identité qui effectue le push — la clé publique doit se trouver sur le compte qui possède l’adresse e-mail dans user.email. (S’il s’agit du même compte dédié que celui utilisé pour les pushs, vous ne devez le faire qu’une seule fois.)
Exportez la clé privée, encodez-la en base64, puis ajoutez-la (avec les GIT_USER_NAME / GIT_USER_EMAIL correspondants) comme secrets dans Settings → Resources → Secrets.
Dans votre configuration d’environnement à l’échelle de l’organisation, importez la clé et activez la signature au démarrage de chaque session. Consultez l’exemple de signature GPG des commits prêt à copier-coller pour obtenir le YAML complet.

L’adresse e-mail du committer (user.email) doit correspondre à un UID de la clé GPG, et cette même adresse e-mail doit être une adresse vérifiée sur le compte GitHub où vous avez téléversé la clé publique. Si l’un de ces trois éléments ne correspond pas, GitHub affichera le commit comme Unverified même si la signature elle-même est valide.

Considérations relatives à la sécurité

Protection de branche : Nous recommandons d’activer des règles de protection de branche sur votre branche principale afin de garantir que tous les contrôles requis ont été validés avant que Devin ne puisse fusionner les modifications.
Autorisations au niveau de l’organisation : Devin utilise les autorisations accordées au niveau de l’organisation, et non les autorisations de l’utilisateur qui exécute la session.
Accès homogène : Tous les utilisateurs ayant accès aux organisations GitHub et Devin partagent les mêmes autorisations d’intégration Devin.
Création de dépôts : Devin ne peut pas créer de nouveaux dépôts dans votre compte GitHub.

Autorisation d’adresses IP

Si votre organisation exige une autorisation d’adresses IP pour l’accès à GitHub, ajoutez les adresses IP suivantes :

100.20.50.251
44.238.19.62
52.10.84.81
52.183.72.253
20.172.46.235
52.159.232.99
4.204.199.103
140.232.64.0/26

Ces adresses IP peuvent changer lors de futures mises à jour. Nous vous recommandons de consulter régulièrement nos notes de version afin de suivre toute modification.

Dépannage : organisation GitHub connectée à la mauvaise organisation Devin

Si votre organisation GitHub est déjà connectée à une organisation Devin à laquelle vous n’avez pas accès, un administrateur de l’organisation GitHub peut supprimer l’installation existante et la réinstaller pour une autre organisation Devin.

Nous vous recommandons de confirmer avec le propriétaire de l’organisation Devin actuelle avant de supprimer l’installation.

Accédez à github.com/settings/installations et cliquez sur Configure à côté de Devin.ai Integration. Si nécessaire, basculez vers le bon contexte d’organisation GitHub à l’aide du menu déroulant Go to settings page en haut à droite.
Sur la page d’installation, faites défiler jusqu’à la section Danger zone et cliquez sur Uninstall pour supprimer Devin.ai Integration de l’organisation GitHub.
Revenez à app.devin.ai et actualisez la page. Vous pouvez maintenant réinstaller l’intégration GitHub pour votre organisation Devin.

FAQ sur l’intégration GitHub

Puis-je connecter un compte GitHub personnel au compte Devin de mon organisation ?

Oui, vous pouvez connecter une organisation GitHub ou un compte GitHub personnel à votre organisation Devin. Nous vous recommandons toutefois de connecter le compte qui dispose des autorisations appropriées pour que Devin puisse accéder aux dépôts dont votre équipe a besoin.

Comment l’application GitHub gère-t-elle l’authentification des utilisateurs ?

Seuls les utilisateurs membres de l’organisation ayant installé l’intégration GitHub peuvent l’utiliser dans leurs sessions Devin. Devin hérite de l’accès à l’intégration GitHub en fonction de l’appartenance de l’utilisateur à cette organisation.

Comment Devin gère-t-il et fait-il tourner les clés de chiffrement ?

Les clés de chiffrement sont gérées par AWS KMS et sont périodiquement renouvelées.

Prise en main

Concepts essentiels

Mise en place de Devin

Travailler avec Devin

Guides produit

Intégrations

Administration

Notes de version

Intégration GitHub de Devin

Pourquoi intégrer Devin à GitHub ?

Configuration de l’intégration