Passer au contenu principal
Solutions aux échecs de build courants, réponses aux questions fréquentes et guide pour migrer depuis l’ancienne configuration interactive.
Pour la configuration générale de l’environnement, consultez Configuration de l’environnement. Pour les détails de syntaxe, consultez la Référence YAML.

​
Dépannage des échecs de build

​
Étape 1 : Vérifier le statut du build

Accédez à Settings > Environnement de Devin > Historique des builds. Votre build affichera l’un des statuts suivants :
StatutCe que cela signifieQue faire
SuccessTout a fonctionnéRien — votre image de machine est prête
PartialLe build principal a réussi, mais certains repos ont échouéVérifiez quels repos ont échoué ; les sessions associées peuvent rencontrer des problèmes
FailedLe build lui-même a échouéVérifiez les logs de l’étape en échec
CancelledUn build plus récent a remplacé celui-ciNormal — lancez un build plus récent si nécessaire
SkippedAucune modification de configuration détectéeRien — aucun build n’était nécessaire

​
Étape 2 : Lire les logs de build

Les logs de build sont organisés par étape :
  1. Configuration partagée — commandes Enterprise et à l’échelle de l’organisation
  2. Clonage — clonage du dépôt
  3. Configuration du dépôt — commandes propres à chaque dépôt
  4. Finalisation — contrôle d’état et création de l’image
Recherchez la première erreur dans les logs. Les erreurs suivantes sont souvent des conséquences en cascade de la première.
Si vous avez utilisé la forme développée avec des champs name, les logs indiqueront exactement quelle étape a échoué. C’est l’un des principaux avantages de donner un nom à vos étapes : 
# Sans noms — difficile à déboguer
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  npm install -g pnpm

# Avec noms — facile d'identifier les échecs
initialize:
  - name: Install uv
    run: curl -LsSf https://astral.sh/uv/install.sh | sh
  - name: Install pnpm
    run: npm install -g pnpm

​
Step 3: Identifier le type d’échec

​
Échecs du clonage

Symptôme : Le build échoue lors du clonage. Causes courantes :
  • L’accès au dépôt n’est pas configuré — vérifiez Enterprise Settings > Integrations
  • Un dépôt privé nécessite un jeton d’authentification
  • Le dépôt a été renommé ou supprimé
  • Problème de connectivité réseau (VPN ou proxy requis)
Correctif : Vérifiez que Devin a accès au dépôt dans vos Settings d’intégration. Pour les registres privés, assurez-vous que les identifiants sont configurés dans Secrets.

​
Échecs de l’installation des dépendances

Symptôme : Le build échoue pendant la configuration du repo, généralement lors de npm install, pip install ou d’une commande similaire. Causes courantes :
  • Le registre de packages privé nécessite une authentification — ajoutez un token à Secrets
  • Conflit de versions de package — verrouillez des versions spécifiques
  • Délai d’expiration réseau — vérifiez si VPN est nécessaire
  • URL du registre mal configurée
Correctif : Ajoutez l’authentification au registre dans votre section maintenance. Voir Exemples de configuration pour les schémas de registre privé.

​
Échecs liés à un délai d’expiration

Symptôme : Le build semble bloqué, puis échoue. Causes courantes :
  • Un prompt interactif attend une entrée — ajoutez les flags -y, utilisez DEBIAN_FRONTEND=noninteractive
  • L’installation d’un très grand nombre de dépendances prend trop de temps
  • La commande dépasse le délai d’expiration d’une heure
Correctif : Ajoutez des flags non interactifs à toutes les commandes d’installation. Déplacez les installations lentes et ponctuelles vers initialize afin qu’elles ne s’exécutent que pendant les builds (et non à chaque session). 
# Mauvais — restera bloqué en attente d'une entrée
initialize: |
  sudo apt-get install libpq-dev

# Bon — non interactif
initialize: |
  sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq libpq-dev

​
Erreurs d’autorisation

Symptôme : « Permission denied » dans les logs. Causes courantes :
  • Absence de sudo pour l’installation de packages système
  • Tentative d’écriture dans des répertoires protégés
  • Fichier appartenant à un autre utilisateur issu d’un build précédent
Correctif : Utilisez sudo pour les opérations au niveau système (apt-get, écriture dans /etc/, etc.). Pour les gestionnaires de packages au niveau utilisateur (npm, pip, cargo), sudo n’est généralement pas nécessaire.

​
Erreurs “commande introuvable”

Symptôme : Un outil installé lors de initialize n’est pas disponible dans maintenance ou lors des étapes suivantes. Causes courantes :
  • L’outil s’installe dans un répertoire qui ne figure pas dans PATH
  • Les modifications apportées au profil shell (.bashrc) ne sont pas prises en compte dans les étapes suivantes
Correctif : Ajoutez le répertoire de l’outil à PATH via $ENVRC : 
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  echo 'export PATH="$HOME/.local/bin:$PATH"' >> $ENVRC

​
Étape 4 : Itérez

Après avoir identifié le problème :
  1. Corrigez votre configuration YAML
  2. Enregistrez — un nouveau build démarre automatiquement
  3. Consultez les logs du nouveau build
Testez d’abord les commandes. Avant d’ajouter une commande à votre configuration, essayez de l’exécuter dans une session Devin pour vous assurer qu’elle fonctionne. C’est plus rapide que d’attendre un cycle de build complet.

​
Référence rapide des erreurs courantes

ErreurCause probableCorrectif
command not foundOutil non installé ou absent du PATHAjouter à initialize, ou ajouter au PATH via $ENVRC
Permission deniedAbsence de sudoUtiliser sudo apt-get install pour les packages système
npm ERR! 404Package privé, sans authentificationAjouter le auth token du registre dans maintenance (exemples)
E: Unable to locate packageapt-get update n’a pas été exécuté au préalableAjouter sudo apt-get update -qq avant apt-get install
TimeoutInstallation lente ou prompt interactifDéplacer vers initialize ; ajouter -y et DEBIAN_FRONTEND=noninteractive
Fichiers de configuration vides au démarrage de la sessionIdentifiants écrits dans initializeDéplacer les étapes liées aux identifiants vers maintenance
Le build réussit mais la session est défaillanteLa commande maintenance échoue au démarrage de la sessionTester manuellement vos commandes maintenance dans une session

​
Migrer depuis la configuration interactive

Si vous utilisez actuellement l’ancienne configuration interactive (l’assistant pas à pas), vous pouvez passer à une configuration déclarative pour améliorer la reproductibilité et prendre en charge plusieurs repos.

​
Comment fonctionne la migration

L’ancienne configuration et la configuration déclarative produisent chacune leur propre image de machine. Les sessions utilisent l’une ou l’autre — jamais un hybride. Une bascule au niveau de l’org intitulée “Use legacy machine snapshot” détermine l’image utilisée :
  • Bascule activée (par défaut) — toutes les sessions utilisent l’ancien snapshot. Aucune interruption.
  • Bascule désactivée — toutes les sessions utilisent le snapshot déclaratif.
Cela signifie que vous pouvez configurer et tester la configuration déclarative en parallèle, pendant que tout le monde continue à travailler avec l’ancien snapshot.

​
Étapes de migration

1

Préparez votre configuration

Notez les commandes de votre configuration interactive actuelle — vous les associerez aux sections YAML :
Étape de l’ancien assistantÉquivalent déclaratif
Git pullAutomatique (intégré)
Configure secretsSecrets (inchangé)
Installer les dépendancessection initialize
Maintenir les dépendancessection maintenance
Configurer le lintentrée knowledge nommée lint
Configurer les testsentrée knowledge nommée test
Exécuter l’application en localentrée knowledge nommée startup
Notes supplémentairesentrée knowledge nommée notes
2

Rédigez votre YAML

Accédez à Settings > Devin’s Environment et sélectionnez votre dépôt. Associez vos anciennes commandes :
# Ancien "Install Dependencies" → initialize
initialize: |
  nvm use 18
  npm install -g pnpm

# Ancien "Maintain Dependencies" → maintenance
maintenance: |
  pnpm install

# Ancien "Set up lint/tests/app/notes" → knowledge
knowledge:
  - name: lint
    contents: |
      pnpm lint
  - name: test
    contents: |
      pnpm test
  - name: startup
    contents: |
      pnpm dev (port 3000)
  - name: notes
    contents: |
      Always run lint before committing.
Vous pouvez aussi simplement démarrer une session Devin et lui demander de configurer le repo — Devin peut générer automatiquement la configuration pour vous.
3

Enregistrez et attendez le build

Enregistrez votre configuration. Un build démarre automatiquement. Suivez sa progression dans Build History. Les builds sont gratuits — ils ne consomment pas d’ACU.
4

Testez avant de basculer

Avant de migrer tout le monde, testez la configuration déclarative sur des sessions individuelles à l’aide du manual override. Cela vous permet (ou permet à la personne qui itère sur la configuration) d’utiliser le snapshot déclaratif pendant que tout le monde reste sur l’ancien snapshot.Faites évoluer la configuration jusqu’à ce que la configuration déclarative atteigne une parité complète avec votre environnement existant.
5

Basculez

Une fois prêt, mettez sur OFF « Use legacy machine snapshot » dans les paramètres de votre org. Toutes les nouvelles sessions utiliseront alors le snapshot déclaratif.
Les flux d’authentification interactifs (par ex. la connexion AWS SSO via navigateur, ou les flux OAuth nécessitant un navigateur) ne peuvent pas être reproduits au format déclaratif. Si votre ancienne configuration utilise une authentification via navigateur, vous devrez convertir ces flux en alternatives sans interface graphique (API key, jetons de service account, etc.) avant la migration. Ajoutez les identifiants à Secrets et référencez-les dans votre section maintenance.

​
Migration des entreprises

Pour les entreprises avec plusieurs organisations :
  1. Configurez d’abord le YAML au niveau de l’entreprise — pour l’infrastructure partagée, comme le VPN, les certificats et les paramètres de proxy.
  2. Migrez une org à la fois. Chaque org dispose de sa propre option ancien, ce qui vous permet d’effectuer la migration progressivement sans affecter les autres équipes.
  3. Envisagez une org de test. Pour les grandes entreprises, créez une organisation de test dédiée afin de valider la configuration déclarative avant de la déployer dans les orgs de production.
  4. Utilisez Devin à grande échelle. Devin peut configurer des repos via des sessions parallèles — lancez une session par repo et Devin générera automatiquement des propositions de configuration. Cette approche fonctionne bien pour l’intégration de 10 à plus de 100 repos.

​
Que devient mon ancien snapshot ?

Votre ancien snapshot est conservé. Si le nouveau build déclaratif échoue, Devin revient au dernier snapshot ayant abouti avec succès (qui peut être votre ancien snapshot). Vous pouvez également restaurer des snapshots précédents dans Build History.

​
Différences clés

FonctionnalitéAncien (interactif)Déclaratif (YAML)
ReproductibilitéAvec état — les snapshots accumulent les modifications au fil du tempsEntièrement reproductible à partir du YAML
Multi-repoUn repo à la foisPlusieurs repos dans un même build avec clonage simultané
MaintenanceÉtapes manuelles de « maintenance des dépendances »Automatique — maintenance s’exécute au démarrage de la session
Couches Enterprise/orgNon pris en chargeHiérarchie à 3 niveaux (Enterprise → Org → Repo)
Suggestions de DevinUniquement dans l’assistantPendant la session — Devin peut suggérer des mises à jour de configuration
CoûtLes sessions de l’assistant consommaient des ACUSessions de configuration ~1–3 ACU ; les builds sont gratuits

​
Questions fréquentes

​
Général

Que se passe-t-il si je lance une session sur un repo qui n’est pas configuré ? Devin fonctionnera quand même — il devra simplement repartir de zéro pour comprendre votre projet à chaque fois. Cela implique de passer du temps à installer les dépendances, à déterminer comment lancer le build et les tests, et à deviner les conventions. Les sessions prennent plus de temps et consomment davantage d’ACU. Configurer votre environnement permet à Devin de démarrer chaque session déjà préconfigurée et prête à l’emploi. Combien de temps prend un build ? En général, 5 à 15 minutes selon le nombre de repos et la taille des dépendances. Les builds expirent au bout de 2 heures. Combien cela coûte-t-il ? Les builds sont gratuits — ils ne coûtent pas d’ACU. Si vous utilisez une session Devin pour configurer un repo (par exemple, en demandant à Devin de générer votre configuration), cette session coûte généralement 1 à 3 ACU. Une fois la configuration enregistrée, tous les builds suivants basés sur celle-ci sont gratuits. Puis-je utiliser à la fois la configuration ancienne et la configuration déclarative ? Une org n’utilise qu’un seul mode à la fois, contrôlé par le bouton « Use legacy machine snapshot ». Vous pouvez configurer la configuration déclarative en parallèle tant que le bouton est encore activé (mode ancien), puis basculer lorsque vous êtes prêt. Consultez le guide de migration pour plus de détails. Puis-je tester la configuration déclarative sans affecter les autres utilisateurs ? Oui. Utilisez le manual override sur des sessions individuelles pour utiliser temporairement le snapshot déclaratif pendant que tous les autres restent sur le snapshot ancien. Pour les entreprises, vous pouvez également créer une organisation de test dédiée. Que se passe-t-il si mon build échoue ? Devin utilise le snapshot réussi le plus récent. Un build en échec n’interrompt pas les sessions existantes. Quand dois-je utiliser initialize plutôt que maintenance ? Utilisez initialize pour les installations d’outils ponctuelles (apt-get install, configuration du runtime du langage, outils CLI globaux). Utilisez maintenance pour l’installation de dépendances qui doivent rester à jour (npm install, pip install, uv sync). Comment ajouter des variables d’environnement ? Écrivez-les dans $ENVRC : 
initialize: |
  echo "MY_VAR=value" >> $ENVRC
Puis-je installer des paquets système ? Oui, utilisez sudo apt-get install dans votre section initialize. Utilisez toujours DEBIAN_FRONTEND=noninteractive et l’option -y pour éviter toute demande de confirmation interactive. Que faire si j’ai besoin de versions différentes de Node selon les repos ? Utilisez nvm dans la configuration au niveau du repo : 
initialize: |
  nvm install 18
  nvm use 18
Les flux d’authentification interactifs sont-ils pris en charge ? Non. L’authentification via navigateur (comme la connexion AWS SSO ou les flux OAuth nécessitant une fenêtre de navigateur) ne peut pas être reproduite dans le format déclaratif. Remplacez-les par des alternatives sans interface — utilisez des clés API, des jetons de compte de service ou d’autres méthodes reposant sur des identifiants, puis stockez-les dans Secrets. Il n’existe actuellement aucune solution de contournement pour les workflows qui exigent strictement un SSO via navigateur. Ces dépôts doivent continuer à utiliser la configuration interactive jusqu’à ce que des alternatives sans interface soient disponibles.

​
Spécifique au build

Que signifie « succès partiel » ? Le build principal (configuration Enterprise + configuration de l’org + clonage) a réussi, mais une ou plusieurs configurations au niveau du dépôt ont échoué. Les sessions fonctionneront, mais il se peut que les dépendances des repos en échec ne soient pas installées correctement. Pourquoi mon build a-t-il été annulé ? Un build plus récent a été déclenché avant la fin du vôtre. Seul le build le plus récent s’exécute ; les anciens builds en file d’attente sont automatiquement annulés. Modifier la configuration d’un repo reconstruit-il tout ? Oui — un build crée une seule image de machine contenant tous les repos configurés. Toute modification de la configuration déclenche une reconstruction complète. Puis-je revenir à un build précédent ? Oui, via Build History dans les Environment Settings. Vous pouvez restaurer n’importe quel snapshot précédent ayant abouti. Combien de repos puis-je inclure ? Jusqu’à 10 repos sont clonés en parallèle pendant un build. Il n’y a pas de limite stricte au nombre total de repos, mais plus il y a de repos, plus les builds sont longs. Devin peut configurer des repos à grande échelle via des sessions parallèles — lancez une session par repo pour 10 à 100+ repos.

​
Spécificités d’Enterprise

Qui peut modifier la configuration au niveau Enterprise ? Les administrateurs Enterprise uniquement. Les administrateurs d’org peuvent modifier la configuration à l’échelle de l’organisation et au niveau du repo. Les membres ordinaires peuvent modifier la configuration au niveau du repo s’ils disposent de l’autorisation ManageOrgSnapshots. Consultez Configuration de l’environnement Enterprise pour voir le tableau complet des autorisations. La modification de la configuration Enterprise reconstruit-elle toutes les orgs ? Oui. Une modification au niveau Enterprise déclenche des builds pour chaque organisation de l’Enterprise. Des orgs différentes peuvent-elles avoir des configurations différentes ? Oui. Chaque org dispose de sa propre configuration à l’échelle de l’organisation et de ses configurations au niveau du repo. La configuration Enterprise est partagée et additive — elle s’exécute avant la configuration de chaque org. Les configurations de niveau inférieur peuvent-elles remplacer celles de niveau supérieur ? Non. La hiérarchie (Enterprise → Org → Repo) est strictement additive. Les commandes de chaque niveau s’exécutent dans l’ordre, une fois le niveau précédent terminé. Les niveaux inférieurs ne peuvent ni empêcher ni modifier ce que les niveaux supérieurs configurent. La configuration au niveau Enterprise peut-elle cloner des dépôts ? Non. Le clonage de dépôt nécessite un accès au niveau de l’org. La configuration au niveau Enterprise peut installer des outils et une infrastructure partagés, mais le clonage de repo doit être configuré au niveau de l’org ou du repo.

​
Limites connues

  • Aucun aperçu ni environnement de test du build — chaque modification de configuration déclenche un build complet. Testez d’abord les commandes dans une session.
  • Configuration sérielle des repos — la configuration au niveau du repo s’exécute sur un repo à la fois (par ordre alphabétique). Un grand nombre de repos allonge les builds.
  • Aucune logique conditionnelle en YAML — le format ne prend pas en charge les instructions if/else. Utilisez des conditions shell dans vos commandes si nécessaire (par ex. : [ -f package.json ] && npm install).
  • Aucune recherche dans les logs de build — les logs de build doivent être parcourus manuellement. Utilisez des étapes nommées pour repérer plus facilement les échecs.

​
Étapes suivantes