Passer au contenu principal

​
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, rendez-vous sur app.devin.ai > Settings > Integrations > 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 ? Consultez le guide d’intégration GitHub Enterprise Server pour obtenir des instructions de configuration à l’aide de jetons d’accès personnels.

​
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.
  1. Dans votre compte Devin sur app.devin.ai, accédez à Settings > Integrations > GitHub et cliquez sur Add Connection.
Devin
  1. Si vous n’êtes pas déjà connecté à GitHub, vous serez invité à vous authentifier.
Devin
  1. Sélectionnez l’organisation GitHub que vous souhaitez connecter à Devin.
Devin
  1. Choisissez d’accorder à Devin l’accès à All repositories ou Select repositories afin de contrôler à quels dépôts Devin peut accéder.
Devin
  1. 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.
Devin
Nous vous recommandons d’activer des règles de protection sur votre branche principale afin de garantir que toutes les vérifications requises sont effectuées 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 dépôts à des organisations spécifiques depuis Enterprise Settings > Repository Permissions.
Devin
Si vous travaillez avec un dépôt 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 tant que la session n’a pas été archivée.

​
Gestion des autorisations de Devin dans GitHub

Lors de la configuration, vous pouvez accorder à Devin l’accès à tous les dépôts de votre organisation ou restreindre l’accès à certains dépôts spécifiques. Vous pouvez ajuster l’accès aux dépôts à tout moment via les paramètres de GitHub :
  1. Pour votre organisation GitHub, accédez à Settings > GitHub Apps (par exemple, https://github.com/organizations/<org_name>/settings/installations)
  2. Sélectionnez Configure pour l’intégration Devin.ai
  3. Sous Repository access, choisissez d’accorder l’accès à tous les dépôts ou uniquement à certains dépôts
  4. Cliquez sur Save pour appliquer vos modifications
Devin
Devin a besoin des autorisations suivantes : Accès en lecture à :
AutorisationDescription
dependabot alertsPermet à Devin de résoudre les alertes Dependabot en votre nom (c.-à-d. mettre à jour les versions de dépendances)
actionsPermet à Devin de consulter les actions configurées pour un dépôt afin de comprendre si les changements de Devin passent la CI
deploymentsPermet à Devin de voir quelles versions d’un dépôt ont été déployées
metadataPermet à Devin de consulter les métadonnées cruciales d’un dépôt, par exemple qui en est propriétaire
packagesPermet à Devin de voir quelles versions d’un dépôt ont été publiées sous forme de package
pagesPermet à Devin de consulter les pages associées à un dépôt, par exemple pour voir la documentation
repository security advisoriesPermet à Devin de consulter les avis de sécurité liés à un dépôt afin d’aider à corriger les problèmes de sécurité
membersPermet à Devin de consulter les membres d’une organisation
webhooksPermet à Devin de consulter les hooks configurés pour un dépôt, par exemple pour le linting et la vérification de types
Accès en lecture et en écriture à :
AutorisationDescription
checksPermet à Devin de consulter et de reporter les résultats des checks pour un dépôt afin de comprendre et de communiquer si les changements de Devin passent la CI
commit statusesPermet à Devin de consulter et de définir les statuts de commit afin d’indiquer si un commit passe la CI
contentsPermet à Devin de contribuer à la base de code
discussionsPermet à Devin de contribuer aux discussions
issuesPermet à Devin d’ouvrir de nouveaux tickets/issues
pull requestsPermet à Devin de créer de nouvelles PR
projectsPermet à Devin de consulter et de gérer les projets associés à un dépôt, par exemple pour récupérer des informations sur une tâche
workflowsPermet à Devin de configurer de nouveaux workflows, par exemple pour aider à configurer la CI/CD
Ces autorisations permettent à Devin de travailler dans vos dépôts comme un contributeur classique — en poussant de nouvelles branches, en ouvrant des pull requests et en participant aux discussions de PR.

​
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. 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é :
  1. PULL_REQUEST_TEMPLATE/devin_pr_template.md
  2. docs/PULL_REQUEST_TEMPLATE/devin_pr_template.md
  3. .github/PULL_REQUEST_TEMPLATE/devin_pr_template.md
  4. pull_request_template.md
  5. docs/pull_request_template.md
  6. .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 l’auteur du commit. GitHub vérifie les signatures par rapport à l’identité de l’auteur, mais dans tout mode Commit authoring où l’auteur est l’utilisateur à l’origine de la demande (p. ex., “Co-authored”, “User only”, “User as author, Devin as committer”), Devin remplace user.email à chaque session par l’adresse e-mail propre à l’utilisateur — ce qui ne correspondra pas à une clé GPG partagée unique. Définissez le mode Commit authoring de votre organisation sur “Devin only” ou “Devin as author, user as committer” avant de vous appuyer sur cette configuration.
Configurez cela au niveau 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 :
  1. 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.
  2. Générez localement une clé GPG avec l’adresse e-mail de ce compte comme UID, en suivant les instructions de GitHub.
  3. 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é de l’auteur du commit, 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.)
  4. 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 > Secrets.
  5. 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
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.
  1. 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.
    Changer de contexte des paramètres GitHub
  2. 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.
    Désinstaller Devin.ai Integration
  3. 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

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.
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.
Les clés de chiffrement sont gérées par AWS KMS et sont périodiquement renouvelées.