Des blueprints à copier-coller pour les langages et cas d’usage courants. Combinez-les pour composer votre configuration complète. Les exemples utilisent Bash sous Linux ; remplacez les hôtes, périmètres et commandes donnés en exemple par les vôtres.
Pour le détail de chaque champ, consultez la référence Blueprint.
Secrets : configurez les secrets nommés dans l’onglet Secrets de chaque éditeur de blueprint. Les étapes de build reçoivent les secrets applicables du blueprint. Pendant une session, assurez-vous que chaque commande reçoit les secrets dont elle a besoin : les secrets à périmètre repo nécessitent des liaisons d’environnement exec explicites, par exemple env={"REGISTRY_TOKEN": "secret:repo:owner/repo:REGISTRY_TOKEN"}. Consultez Secrets. Ne codez jamais en dur des credentials dans votre blueprint.
Les étapes de build ne sont pas des hooks de démarrage de session. initialize et maintenance s’exécutent pendant la construction des snapshots ; maintenance n’est pas exécuté automatiquement au démarrage d’une session. knowledge fournit des instructions à Devin, et non des hooks exécutables.Ne laissez pas de credentials dans des fichiers persistants, y compris $ENVRC. Le nettoyage des snapshots supprime les fichiers de secrets injectés par Devin, mais pas les fichiers quelconques créés par vos commandes. Utilisez les références de variables littérales prises en charge par l’outil concerné, ou transmettez les credentials dans l’environnement de la commande. Lorsqu’un outil exige des fichiers de credentials, créez-les le temps d’une seule opération et supprimez-les avant qu’elle ne se termine. Répétez cette configuration explicitement au besoin dans une session.
Blueprints minimaux pour les configurations les plus courantes. Copiez-en un, collez-le dans l’éditeur de blueprints, et le tour est joué.
Projet full-stack (Node + Python)
Étapes de build propres à chaque dépôt, gestion des dépendances et entrées Knowledge. Définissez-les dans Settings > Environnement > Blueprints > [votre dépôt].
uv (recommandé)
pip + venv
Configuration recommandée pour les projets Python qui utilisent uv pour la gestion des dépendances. Configuration Python traditionnelle avec pip et venv. À utiliser lorsque votre projet s’appuie sur requirements.txt.
Configuration Node.js par défaut avec npm.Utilisez npm install (et non npm ci) dans maintenance. Cette commande effectue une mise à jour incrémentielle, tandis que npm ci supprime node_modules et réinstalle tout depuis zéro à chaque exécution de la commande.
Pour les projets qui utilisent pnpm.
Configuration Go standard avec modules.
Configuration de Java avec Gradle.JDK 17 est préinstallé sur l’image de base de Devin. Ignorez l’étape d’installation du JDK si l’OpenJDK 17 par défaut vous convient.
Configuration de Java avec Maven.JDK 17 est préinstallé sur l’image de base de Devin. Ignorez l’étape d’installation du JDK si l’OpenJDK 17 par défaut vous convient.
Configuration de Rails avec PostgreSQL.
Configuration standard de Rust avec Cargo.
Rust (via rustup) et Cargo sont préinstallés sur l’image de base de Devin. Passez l’étape d’installation si la toolchain stable par défaut vous convient. Il vous suffit de récupérer les dépendances.
Monorepo avec un frontend Node.js et un backend Python. Chaque sous-projet a ses propres entrées Knowledge.Utilisez des subshells (cd dir && command) plutôt que cd dir && command afin que le répertoire de travail soit réinitialisé entre les étapes.
Monorepo Java dans lequel différents services nécessitent différentes versions de JDK. Installez les deux JDK lors de l’initialisation, puis utilisez les entrées knowledge pour indiquer à Devin quelle valeur de JAVA_HOME utiliser pour chaque service.
Registres de packages privés
Configurez les gestionnaires de paquets pour résoudre les dépendances depuis des registres privés. Définissez ces paramètres dans Settings > Environment > Blueprints > Org-wide setup (ou par repo si un seul repo en a besoin).
Stockez des références, pas des credentials en clair. Les délimiteurs heredoc entre quotes tels que <<'EOF' préservent les références de variables dans le fichier. npm, Yarn Berry, Maven et Gradle savent résoudre les références ci-dessous au moment de leur exécution. pip, en revanche, n’interprète pas les variables shell dans pip.conf : utilisez donc des variables d’environnement. Les fichiers de setup du shell doivent être sourcés explicitement dans la même commande que l’outil ; ne partez pas du principe qu’un nouveau shell les source ou rafraîchit les credentials.Les URL écrites directement dans une configuration persistante, comme un index Cargo, un mirror Docker ou un mirror APT, ne doivent pas contenir de credentials. Conservez l’authentification dans les secrets distincts indiqués par chaque template.Si vous avez utilisé un ancien template qui écrivait des credentials sur le disque, supprimez ces fichiers et effectuez un rebuild à partir d’une base propre plutôt que d’un snapshot qui les contient. Effectuez une rotation des credentials susceptibles d’avoir été compromis.
Si votre registre privé utilise une CA d’entreprise, commencez par vérifier que le certificat d’autorité de certification est installé au niveau Enterprise. La configuration ci-dessous suppose que la confiance HTTPS est déjà établie.
npm (scoped)
npm (miroir complet)
pnpm
Yarn
Configurez npm pour récupérer les packages d’un scope (par ex. @myorg/*) à partir d’un registre privé, tandis que les packages publics continuent de provenir du registre npm par défaut.
GITHUB_PACKAGES_TOKEN — Jeton d’accès personnel ou jeton GitHub App avec le périmètre read:packages
Remplacez @myorg par votre scope npm. URL courantes de registres privés :
- GitHub Packages:
https://npm.pkg.github.com
- Artifactory:
https://artifactory.example.com/artifactory/api/npm/npm-virtual
- Nexus:
https://nexus.example.com/repository/npm-group
- GitLab:
https://gitlab.example.com/api/v4/packages/npm
- AWS CodeArtifact:
https://<domain>.d.codeartifact.<region>.amazonaws.com/npm/<repo>
Faites passer tous les packages npm par votre registre privé (et pas seulement les packages d’un scope).
NPM_REGISTRY_URL — URL complète de votre registre npm (par ex. https://artifactory.example.com/artifactory/api/npm/npm-virtual)
NPM_REGISTRY_HOST — Nom d’hôte uniquement, sans protocole (par ex. artifactory.example.com)
REGISTRY_TOKEN — Jeton d’authentification npm pour le registre
Configurez pnpm pour récupérer des packages à partir d’un registre privé.
NPM_REGISTRY_URL — URL complète de votre registre npm
NPM_REGISTRY_HOST — Nom d’hôte uniquement, sans protocole
REGISTRY_TOKEN — Jeton d’authentification npm pour le registre
Configurez Yarn (Classic v1 ou Berry v2+) pour récupérer des packages à partir d’un registre privé.
NPM_REGISTRY_URL — URL complète de votre registre npm/Yarn
REGISTRY_TOKEN — Jeton d’authentification pour le registre
Yarn Classic (v1) :Remplacez registry.example.com par l’hôte de votre registre. Yarn Classic lit le fichier .npmrc de npm.Yarn Berry (v2+) :
Configurez pip et uv pour récupérer les packages depuis votre registre PyPI privé (p. ex., Nexus, Artifactory).
PYPI_REGISTRY_URL — URL complète de votre index PyPI, y compris les identifiants si nécessaire (p. ex., https://user:token@nexus.example.com/repository/pypi-proxy/simple)
Pour préparer les dépendances pendant un build, ajoutez la même commande source ... && dans maintenance, après l’étape de configuration. Encodez en pourcentage les caractères spéciaux des credentials présents dans l’URL.Modèles courants d’URL de registres PyPI :
- Artifactory :
https://artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple
- Nexus :
https://nexus.example.com/repository/pypi-proxy/simple
- AWS CodeArtifact :
https://aws:TOKEN@domain-owner.d.codeartifact.region.amazonaws.com/pypi/repo/simple/
- Azure Artifacts :
https://pkgs.dev.azure.com/org/project/_packaging/feed/pypi/simple
- GitLab :
https://gitlab.example.com/api/v4/groups/<group-id>/-/packages/pypi/simple
Configurez Poetry pour récupérer les packages depuis un registre PyPI privé.
POETRY_REGISTRY_URL — URL complète de votre registre compatible PyPI
REGISTRY_USER — Nom d’utilisateur du registre
REGISTRY_PASS — Mot de passe du registre ou jeton d’API
Pour l’installation des dépendances, déclarez également la source de packages private dans le pyproject.toml de votre projet. poetry config repositories.private configure le repository de publication ; les credentials de l’environnement s’appliquent au nom de source correspondant.
Installez le JDK et configurez Maven pour faire transiter toute la résolution des dépendances par votre registre privé (p. ex. Artifactory, Nexus).Le JDK 17 est préinstallé sur l’image de base de Devin. Passez l’étape d’installation si l’OpenJDK 17 par défaut vous suffit. Vous n’avez besoin que de l’installation de Maven et de la configuration du registre.
MAVEN_REGISTRY_URL — URL de votre registre Maven (p. ex. https://artifactory.example.com/artifactory/maven-virtual)
REGISTRY_USER — Nom d’utilisateur du registre
REGISTRY_PASS — Mot de passe du registre ou jeton d’API
Schémas d’URL courants pour les registres Maven :
- Artifactory:
https://artifactory.example.com/artifactory/maven-virtual
- Nexus:
https://nexus.example.com/repository/maven-public
- Azure Artifacts:
https://pkgs.dev.azure.com/org/project/_packaging/feed/maven/v1
- GitHub Packages:
https://maven.pkg.github.com
- GitLab:
https://gitlab.example.com/api/v4/groups/<group-id>/-/packages/maven
- AWS CodeArtifact:
https://<domain>.d.codeartifact.<region>.amazonaws.com/maven/<repo>
Installez le JDK et configurez Gradle pour résoudre l’ensemble des dépendances via votre registre privé.Le JDK 17 est préinstallé sur l’image de base de Devin. Ignorez l’étape d’installation du JDK si la version par défaut vous convient.
GRADLE_REGISTRY_URL — URL de votre registre Gradle/Maven
REGISTRY_USER — Nom d’utilisateur du registre
REGISTRY_PASS — Mot de passe du registre ou jeton d’API
Installez Go et configurez-le pour qu’il résolve les modules via un proxy de modules privé (par exemple Athens, Artifactory ou un endpoint GOPROXY).
GO_PROXY_URL — URL de votre proxy de modules Go (par exemple https://athens.corp.internal)
Connectez le Git provider et accordez l’accès aux dépôts qui hébergent vos modules privés via les Git integrations. Utilisez des URL Git HTTPS classiques avec l’authentification configurée de Devin. N’intégrez pas de token dans une réécriture d’URL Git.Pour préremplir le cache des modules pendant les builds, ajoutez cette commande à la section maintenance du blueprint du repository, où go.mod est disponible. Ne l’exécutez pas dans le setup à l’échelle de l’organisation, qui s’exécute avant le clonage des repositories.Formats d’URL de proxy Go courants :
- Artifactory :
https://artifactory.example.com/artifactory/go-virtual
- Nexus :
https://nexus.example.com/repository/go-proxy
- Athens :
https://athens.corp.internal
Configurez NuGet pour résoudre les packages depuis un flux privé.
NUGET_SOURCE_URL — URL de votre flux NuGet
NuGetPackageSourceCredentials_private — Credentials du flux au format d’environnement NuGet : Username=any;Password=<PAT> (utilisez le username requis par votre flux)
Configurez Docker pour récupérer les images depuis un registre de conteneurs privé.La commande docker login peut écrire les credentials dans son répertoire de configuration. Utilisez un répertoire isolé pour chaque opération et supprimez-le, même si le pull échoue. Réexécutez la séquence de connexion et de pull lorsque vous avez besoin d’une autre image au cours d’une session.
DOCKER_MIRROR_URL (optionnel) — URL de votre miroir Docker Hub (par ex., https://mirror.corp.internal)
DOCKER_REGISTRY_URL — URL de votre registre de conteneurs privé (par ex., registry.corp.internal:5000)
DOCKER_REGISTRY_USER — Nom d’utilisateur du registre
DOCKER_REGISTRY_PASS — Mot de passe ou token d’API du registre
Pour mettre en cache une image dans le snapshot, placez ce même sous-shell complet dans une étape de build. Ne répartissez pas la connexion et le nettoyage sur plusieurs étapes, et vérifiez que le nettoyage aboutit avant la création de l’image. L’URL d’un mirror de registre ne doit pas contenir de credentials.URLs de container registry courantes :
- Amazon ECR :
<account-id>.dkr.ecr.<region>.amazonaws.com
- Azure Container Registry :
<name>.azurecr.io
- Google Artifact Registry :
<region>-docker.pkg.dev
- GitHub Container Registry :
ghcr.io
- GitLab Container Registry :
registry.gitlab.example.com
- Nexus :
https://nexus.example.com:8443
- JFrog :
<name>.jfrog.io
Configurez Cargo pour résoudre les crates depuis un registre privé.Rust (via rustup) et Cargo sont préinstallés sur l’image de base de Devin. Passez l’étape d’installation si la chaîne d’outils stable par défaut suffit. Seule la configuration du registre est nécessaire.
CARGO_REGISTRY_INDEX — URL de l’index du registre privé (par ex. sparse+https://cargo.corp.internal/api/v1/crates/)
CARGO_REGISTRIES_PRIVATE_TOKEN — Jeton d’authentification pour le registre nommé private
L’URL de l’index du registre ne doit pas contenir de credentials. Le provider cargo:token de Cargo lit le token du registre nommé depuis l’environnement ; n’exécutez pas cargo login dans une étape de build.Si vous souhaitez simplement ajouter un registre privé sans remplacer crates.io, supprimez les sections [source.crates-io] et [source.private] et utilisez cargo install --registry private ou [dependencies] my-crate = { version = "1.0", registry = "private" } dans Cargo.toml.
Installez Ruby et configurez Bundler pour résoudre les gems depuis un serveur de gems privé.
GEM_SERVER_URL — URL de votre serveur de gems privé (par exemple, https://artifactory.example.com/artifactory/api/gems/gems-virtual)
BUNDLE_ARTIFACTORY__EXAMPLE__COM — username:password pour artifactory.example.com ; adaptez le nom de la variable à votre serveur de gems
Utilisez un GEM_SERVER_URL sans credential. Pour la variable de credential de Bundler, préfixez le hostname en majuscules par BUNDLE_, remplacez chaque point par __ et chaque tiret par ___.Patterns d’URL de gem server courants :
- Artifactory :
https://artifactory.example.com/artifactory/api/gems/gems-virtual
- Nexus :
https://nexus.example.com/repository/rubygems-proxy
- Gemfury :
https://gem.fury.io/<org>
Installez PHP et configurez Composer pour résoudre les packages depuis un registre Packagist ou Satis privé.
COMPOSER_REGISTRY_URL — URL de votre registre Composer privé (par exemple https://repo.packagist.com/<org>)
COMPOSER_AUTH — credentials JSON pour l’hôte du registre, par exemple {"http-basic":{"repo.packagist.com":{"username":"<user>","password":"<token>"}}}
Utilisez un COMPOSER_REGISTRY_URL sans credential.Formats d’URL courants pour un registre Composer :
- Artifactory :
https://artifactory.example.com/artifactory/api/composer/packagist-virtual
- Nexus :
https://nexus.example.com/repository/packagist-proxy
- Private Packagist :
https://repo.packagist.com/<org>
- Satis :
https://satis.corp.internal
Renouvellement du jeton AWS CodeArtifact
Les tokens AWS CodeArtifact expirent normalement au bout de 12 heures. Créez un script contenant des références littérales, puis sourcez-le explicitement dans la même commande shell que npm, pip ou Maven pour obtenir un token. Enregistrer le script dans un blueprint ne suffit pas à l’exécuter au démarrage de la session.awscli est préinstallé sur l’image de base de Devin. Seuls le rafraîchissement du token et la configuration du registre restent à votre charge.
AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY — credentials IAM disposant des autorisations codeartifact:GetAuthorizationToken et sts:GetServiceBearerToken
CA_DOMAIN — Le nom de votre domaine CodeArtifact
CA_DOMAIN_OWNER — ID de l’AWS account propriétaire du domaine
CA_REGION — Région AWS (par ex. us-east-1)
CA_NPM_REPO, CA_PYPI_REPO, CA_MAVEN_REPO — Noms des repositories pour chaque écosystème
Pour préchauffer un cache de dépendances dans le snapshot, ajoutez la commande source ... && appropriée en tant qu’étape de build ultérieure. Le token récupéré reste dans l’environnement de ce shell : ne le rendez pas persistant via aws codeartifact login, via npm config set avec un token développé, ni via un fichier pip.conf contenant des credentials.
Infrastructure Enterprise
Infrastructure au niveau des machines qui s’applique à l’ensemble des organisations et des dépôts. Définissez ces paramètres dans Settings > environnement de base de Devin (à l’échelle de l’entreprise) ou Settings > environnement > Blueprints > configuration à l’échelle de l’organisation (à l’échelle de l’organisation).
Certificat d’autorité de certification interne
Votre organisation utilise une autorité de certification privée pour ses services internes. Devin a besoin du certificat racine pour accéder aux dépôts et outils internes via HTTPS.
CORP_ROOT_CA_B64 — certificat PEM encodé en Base64 issu de votre autorité de certification d’entreprise. Générez-le avec : cat corp-root-ca.crt | base64 -w0
Ces entrées sont des certificats publics. openssl x509 n’écrit que le certificat analysé : une clé privée incluse par inadvertance n’est donc pas copiée dans le magasin de certificats de confiance. Fournissez chaque certificat d’autorité de certification séparément, comme dans l’exemple suivant. Plusieurs certificats d’autorité de certification
Si votre organisation utilise plusieurs certificats d’autorité de certification (par exemple, des autorités de certification distinctes pour différents services internes).
CORP_ROOT_CA_B64 — certificat principal d’autorité de certification encodé en Base64
CORP_INTERMEDIATE_CA_B64 — certificat intermédiaire d’autorité de certification encodé en Base64
Faites passer tout le trafic réseau par un proxy d’entreprise.
CORP_HTTP_PROXY — URL du proxy HTTP (p. ex., http://proxy.corp.example.com:8080)
CORP_HTTPS_PROXY — URL du proxy HTTPS
CORP_NO_PROXY — liste d’hôtes, séparés par des virgules, à ne pas faire passer par le proxy (p. ex., localhost,127.0.0.1,.corp.example.com)
Si votre proxy d’entreprise nécessite une authentification par nom d’utilisateur et mot de passe.
PROXY_USER — Nom d’utilisateur du proxy
PROXY_PASS — Mot de passe du proxy
PROXY_HOST — Nom d’hôte et port du proxy (par ex., proxy.corp.example.com:8080)
CORP_NO_PROXY — Hôtes à exclure du proxy
Encodez en pourcentage les caractères spéciaux du nom d’utilisateur et du mot de passe du proxy. Git et npm peuvent utiliser les variables d’environnement de proxy ; ne copiez pas une URL de proxy contenant des identifiants dans leur configuration persistante. certificat d’autorité de certification + proxy (combinés)
Configuration combinée pour les environnements nécessitant à la fois une autorité de certification d’entreprise et un proxy. Ce cas est fréquent dans les environnements d’entreprise où les services internes utilisent des certificats privés et où tout le trafic doit transiter par un proxy.
CORP_ROOT_CA_B64 — certificat d’autorité de certification d’entreprise encodé en Base64
CORP_HTTP_PROXY, CORP_HTTPS_PROXY — URL du proxy
CORP_NO_PROXY — hôtes à exclure du proxy
Vos registres privés, serveurs Git ou autres services internes ne sont accessibles que via un VPN. Installez le client VPN dans le blueprint. Établissez explicitement le tunnel pour les opérations qui en ont besoin, puis déconnectez-vous et supprimez les fichiers d’identifiants.
OpenVPN :
VPN_CONFIG_B64 — Fichier de configuration OpenVPN encodé en Base64 (.ovpn). Générez-le avec : cat corp.ovpn | base64 -w0
VPN_AUTH_USER (facultatif) — Nom d’utilisateur du VPN, si votre VPN nécessite une authentification par nom d’utilisateur et mot de passe
VPN_AUTH_PASS (facultatif) — Mot de passe du VPN
WireGuard :
WG_CONFIG_B64 — Fichier de configuration WireGuard encodé en Base64. Générez-le avec : cat wg0.conf | base64 -w0
OpenVPN :Exécutez ce block explicitement dans une session où les secrets du VPN sont disponibles. Remplacez la commande curl par le travail qui nécessite le tunnel. La configuration doit contenir en ligne les certificats et clés requis et utiliser dev tun0 ; n’activez pas de service VPN persistant.WireGuard :Exécutez ce block explicitement avec WG_CONFIG_B64 disponible, en remplaçant la commande curl par votre opération :Si un build du snapshot nécessite un accès VPN, regroupez tout le travail dépendant dans le même block afin que le nettoyage soit terminé avant la création de l’image. Déplacer simplement l’écriture des credentials vers maintenance ne les rend pas temporaires. Ne créez pas de snapshot d’un tunnel actif ou d’une configuration VPN privée. Résolution DNS personnalisée
Vos services internes utilisent des noms DNS privés qui ne sont pas résolubles via le DNS public.
Signature GPG des commits
Votre organisation exige que tous les commits Git soient signés et vous souhaitez que GitHub marque les commits de Devin comme Verified.
GPG_PRIVATE_KEY_B64 — clé privée GPG encodée en Base64. À générer avec : gpg --export-secret-keys <key-id> | base64 -w0
GPG_SIGNING_KEY — empreinte complète de la clé de signature
GIT_USER_NAME — nom de l’auteur Git (par exemple, Devin AI)
GIT_USER_EMAIL — adresse e-mail de l’auteur Git. Doit correspondre à un UID de la clé GPG, faute de quoi GitHub ne vérifiera pas la signature.
Téléversez également la clé publique correspondante sur le GitHub account dont Devin utilise les credentials pour pousser ses commits (dans GitHub Settings > SSH and GPG keys). GitHub ne marque les commits comme Verified que si la clé publique de signature est enregistrée sur le compte auteur du commit. N’importez pas de clés de signature privées pendant les builds de snapshots. Une fois les modifications voulues mises en staging, exécutez explicitement ce bloc dans une session où les secrets nommés sont disponibles. Il s’appuie sur un porte-clés temporaire et des paramètres Git valables uniquement pour ce commit :Si votre clé nécessite une phrase secrète, déroulez le flux GPG agent/pinentry approuvé pendant l’opération. N’enregistrez ni la phrase secrète ni le porte-clés dans le blueprint ou le snapshot. Reproduisez la configuration du porte-clés temporaire pour les commits ultérieurs ou les balises signées.
Configurez l’identité Git et les clés SSH de Devin pour accéder à des serveurs Git privés.Privilégiez les Git integrations pour les Git providers pris en charge. Pour un serveur qui exige une clé SSH explicite, gardez la clé privée hors du build du blueprint et utilisez-la uniquement pour l’opération de session décrite ci-dessous.
GIT_USER_NAME — nom de l’auteur Git
GIT_USER_EMAIL — adresse e-mail de l’auteur Git
SSH_PRIVATE_KEY_B64 — clé privée SSH encodée en Base64. À générer avec : cat ~/.ssh/id_ed25519 | base64 -w0
SSH_KNOWN_HOSTS_B64 — entrées known hosts encodées en Base64, vérifiées par rapport aux empreintes de clés d’hôte publiées par l’administrateur de votre serveur
Exécutez explicitement ce bloc dans la session, en remplaçant l’URL Git par celle de votre serveur et de votre repository :Si vous avez besoin d’options SSH personnalisées, ajoutez-les à cette invocation sans copier de clé privée dans un fichier de configuration SSH persistant ou dans le home directory. Reproduisez cette configuration à chaque opération.
Installez les packages système qui ne figurent pas dans l’image Devin par défaut (p. ex., des bibliothèques natives pour le traitement d’images ou la génération de PDF). Variables d’environnement personnalisées
Définissez des variables d’environnement persistantes et non secrètes qui doivent être disponibles dans chaque session. N’écrivez pas de valeurs secrètes ni de credentials dérivés dans $ENVRC.L’approche recommandée consiste à écrire des lignes KEY=VALUE dans le fichier $ENVRC. Les variables écrites dans $ENVRC sont automatiquement exportées pour toutes les étapes suivantes ainsi que pour la session Devin (comme avec le $GITHUB_ENV de GitHub Actions).Vous pouvez également définir des variables d’environnement dans des scripts /etc/profile.d/ afin de les rendre disponibles à l’échelle du système :Les deux approches fonctionnent. $ENVRC est plus simple et recommandé dans la plupart des cas. Paramètres régionaux et fuseau horaire
Les images de base par défaut peuvent avoir des paramètres régionaux incorrects. Configurez les paramètres régionaux et le fuseau horaire pour éviter les avertissements des outils de build, de Java, de Python et de Git. Limites de ressources (ulimits)
Les builds Java, Gradle et Node.js atteignent fréquemment la limite par défaut de 1 024 fichiers ouverts. Augmentez-la pour éviter les build failures. Remplacement du miroir APT
Dans les environnements en air gap ou restreints, remplacez les sources APT Ubuntu par défaut par un miroir interne.
APT_MIRROR_URL — URL de votre miroir APT interne (p. ex., https://artifactory.example.com/artifactory/ubuntu-remote)
Schémas d’URL courants pour les miroirs APT :
- Artifactory:
https://artifactory.example.com/artifactory/ubuntu-remote
- Nexus:
https://nexus.example.com/repository/ubuntu-proxy
Variables d’environnement avec direnv
L’environnement de base de Devin comprend direnv. Utilisez initialize pour créer des fichiers .envrc. Direnv les charge automatiquement.direnv est intégré d’emblée au shell de Devin, donc les variables .envrc se chargent automatiquement. Aucun chargement manuel n’est nécessaire.
Pour les variables d’environnement sensibles (API keys, jetons, mots de passe de base de données), utilisez les secrets du dépôt plutôt que des fichiers .envrc, et liez-les explicitement aux commandes de session qui en ont besoin. Développer un secret dans un fichier pendant un build peut malgré tout l’inscrire dans le snapshot. Sélection de la version de Node par dépôt
Utilisez nvm (préinstallé) pour changer de version de Node.js pour chaque dépôt via .nvmrc.nvm use lit .nvmrc à la racine du dépôt. Assurez-vous que votre dépôt en contient un (p. ex. avec 20).
Authentification dans le navigateur (Playwright)
Devin fournit un navigateur Chrome avec un endpoint CDP sur localhost:29229 pendant les sessions. Utilisez des scripts Playwright pour automatiser la connexion via le navigateur.Le navigateur n’est disponible que pendant les sessions, pas dans les builds du snapshot. Installez Playwright dans initialize et conservez les scripts de connexion dans votre repo.
Exemple de script de connexion (scripts/login.py) :Stockez les identifiants de connexion dans les secrets, pas dans le code source. Pour une authentification persistante, versionnez les scripts de connexion dans .agents/skills/ afin que Devin puisse se réauthentifier automatiquement.
Outils système personnalisés et PATH
Installez des packages système, des binaires personnalisés et configurez le PATH dans initialize. GitHub Actions pour configurer l’outil
Proxy inverse HTTPS en local pour plusieurs applications
Exécutez plusieurs services derrière des noms d’hôte plausibles via HTTPS, comme app.example.com, api.example.com et admin.example.com. Installez un seul proxy inverse dans initialize et faites pointer chaque nom d’hôte vers un port upstream local distinct.Caddy gère le routage et le TLS local dans un seul outil. Un Caddyfile associe chaque nom d’hôte à un upstream, et tls internal émet automatiquement, pour chaque nom d’hôte, un certificat approuvé à partir de l’autorité de certification intégrée à Caddy. caddy trust installe la racine de cette autorité dans le magasin de confiance du système, et l’ajout de cette même racine à la base de données NSS permet au navigateur de l’accepter.Importez votre Caddyfile via la section Pièces jointes de l’éditeur de blueprint ; il sera alors disponible sous la forme $FILE_CADDYFILE.Le bloc /etc/hosts permet à app.example.com de pointer vers 127.0.0.1 à l’intérieur de la session. Ajoutez une entrée pour chaque hostname que vous mettez dans le Caddyfile.
Pour ajouter un service, ajoutez un bloc de trois lignes au Caddyfile et une entrée au bloc /etc/hosts, puis accédez à son hostname en HTTPS. Caddy génère un certificat à la première requête ; aucune génération de certificat par application n’est donc nécessaire.
Ces exemples montrent comment les configurations Enterprise et celles au niveau de l’org se combinent. En pratique, vous les répartiriez entre plusieurs périmètres. Elles sont regroupées ici à titre de référence.
Stack complète pour entreprise (Artifactory)
Un environnement d’entreprise complet : certificat d’autorité de certification d’entreprise, proxy, Java (Maven), Python (pip/uv), Node.js (npm) et Docker, le tout pointant vers une seule instance Artifactory.
Réseau & confiance (échelle du compte) :
CORP_ROOT_CA_B64 — certificat d’autorité de certification d’entreprise encodé en Base64
CORP_HTTP_PROXY — URL du proxy HTTP
CORP_HTTPS_PROXY — URL du proxy HTTPS
CORP_NO_PROXY — hôtes à ne pas faire passer par le proxy
Identifiants du registre (échelle de l’organisation) :
ARTIFACTORY_USER — nom d’utilisateur Artifactory
ARTIFACTORY_TOKEN — jeton d’API Artifactory ou mot de passe
ARTIFACTORY_MAVEN_URL — URL du dépôt Maven (p. ex., https://artifactory.example.com/artifactory/maven-virtual)
ARTIFACTORY_PYPI_URL — URL du dépôt PyPI (p. ex., https://user:token@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple)
ARTIFACTORY_NPM_URL — URL du dépôt npm (p. ex., https://artifactory.example.com/artifactory/api/npm/npm-virtual)
ARTIFACTORY_DOCKER_URL — URL du registre Docker (p. ex., artifactory.example.com)
Cela serait généralement réparti en trois périmètres :
- À l’échelle du compte (
initialize) : certificat et proxy
- À l’échelle de l’organisation (
initialize) : Installation des runtimes de langage
- À l’échelle de l’organisation (
maintenance) : Configuration du registre contenant des références littérales
- Commandes de session : fournir explicitement les secrets, sourcer la configuration de l’environnement et se connecter pour chaque opération Docker
Présenté ici en version combinée pour référence :Dans cet exemple, tous les registres pointent vers la même instance Artifactory, mais utilisent des chemins d’URL différents. Chaque écosystème de packages a son propre format d’endpoint. Les URL Maven, PyPI, npm et Docker sont toutes différentes, même pour un même registre.
Plusieurs langages avec différents dépôts
Lorsque différents langages utilisent des registres privés différents (par ex. Maven via Nexus, npm via GitHub Packages, Python via Artifactory).
NEXUS_MAVEN_URL — URL du dépôt Maven Nexus
NEXUS_USER — nom d’utilisateur Nexus
NEXUS_PASS — mot de passe Nexus
GITHUB_PACKAGES_TOKEN — jeton d’accès personnel GitHub avec le périmètre read:packages
ARTIFACTORY_USER — nom d’utilisateur Artifactory
ARTIFACTORY_TOKEN — jeton d’API Artifactory
Connectez votre Git provider et accordez l’accès aux repositories qui hébergent les modules Go via les Git integrations. Environnement en air gap avec des miroirs privés
Dans un environnement totalement en air gap, Devin ne peut accéder à aucune URL publique. Tous les outils, environnements d’exécution et packages doivent provenir de miroirs internes.
Certificats :
CORP_ROOT_CA_B64 — certificat d’autorité de certification de l’entreprise encodé en Base64
Accès au miroir :
APT_MIRROR_URL — URL du miroir APT Ubuntu interne
MIRROR_USER — nom d’utilisateur d’authentification au miroir
MIRROR_PASS — mot de passe d’authentification au miroir
JDK_TARBALL_URL — URL pour télécharger l’archive tar du JDK depuis le miroir interne
NODE_TARBALL_URL — URL pour télécharger l’archive tar de Node.js depuis le miroir interne
Registres de packages :
INTERNAL_MAVEN_URL — URL du registre Maven interne
INTERNAL_NPM_URL — URL du registre npm interne
INTERNAL_PYPI_URL — URL du registre PyPI interne
Dans les environnements en air gap, tous les outils dont Devin a besoin (environnement d’exécution, outils CLI, etc.) doivent être disponibles sur vos miroirs internes. Les registres publics et les sites de téléchargement ne sont pas accessibles.
VPN + certificats + proxy + langages
Une configuration Enterprise complète combinant les outils VPN, des certificats, la configuration du proxy et la prise en charge multilingue. Le blueprint installe les outils et stocke la configuration avec des références littérales. Connectez explicitement le VPN lorsque vous exécutez des opérations nécessitant un accès interne.
VPN :
VPN_CONFIG_B64 — fichier de configuration OpenVPN encodé en Base64
Réseau & confiance :
CORP_ROOT_CA_B64 — certificat d’autorité de certification d’entreprise encodé en Base64
CORP_HTTP_PROXY — URL du proxy HTTP
CORP_HTTPS_PROXY — URL du proxy HTTPS
CORP_NO_PROXY — hôtes à ne pas faire passer par le proxy
Identifiants du registre :
MAVEN_REGISTRY_URL — URL du registre Maven
NPM_REGISTRY_URL — URL du registre npm
PYPI_REGISTRY_HOST — nom d’hôte du registre PyPI
REGISTRY_USER — nom d’utilisateur du registre (pour Maven et pip)
REGISTRY_PASS — mot de passe du registre (pour Maven et pip)
REGISTRY_TOKEN — jeton d’authentification npm
Un accès d’amorçage est requis. Le client OpenVPN doit être préinstallé ou installable avant l’établissement du tunnel. VPN_CONFIG_B64 doit contenir les certificats/clés en ligne, utiliser dev tun0 et se connecter sans authentification interactive. Les téléchargements des environnements d’exécution s’effectuent au sein d’un même cycle de vie du tunnel et chargent explicitement l’environnement du proxy. Répétez le bloc de configuration/nettoyage du VPN décrit dans Réseau et connectivité pour les opérations de session ; le blueprint ne reconnecte pas le VPN au début de la session.
Conseils pour rédiger de bons blueprints
- Testez d’abord les commandes dans une session. Exécutez-les manuellement dans une session Devin avant de les ajouter à votre blueprint. C’est plus rapide que d’attendre un cycle de build complet.
- Utilisez
initialize pour les outils à installer une seule fois, et maintenance pour les dépendances. Tout ce qui prend plusieurs minutes à installer (compilateurs, gros binaires, outils globaux) doit aller dans initialize. Les commandes de dépendances rapides (npm install, uv sync) vont dans maintenance.
- Veillez à ce que les commandes
maintenance restent rapides. Visez moins de 2 minutes. Elles s’exécutent pendant les builds et sont exposées à l’agent au démarrage de la session.
- Utilisez
$ENVRC pour les variables d’environnement non sensibles. N’écrivez pas de credentials ni de tokens dérivés dans $ENVRC, .bashrc ou .profile. Sourcez explicitement la configuration shell dépendant de secrets dans la commande qui en a besoin.
- Nommez vos étapes. La syntaxe développée avec des champs
name permet d’identifier beaucoup plus facilement les échecs dans les journaux de build.
- Utilisez des subshells pour les monorepos.
(cd packages/foo && npm install) s’exécute dans un subshell afin que les étapes suivantes ne soient pas affectées par le changement de répertoire.
- Utilisez
npm install, pas npm ci. npm ci supprime node_modules et réinstalle tout depuis zéro, ce qui est trop lent pour maintenance.
- Utilisez les secrets du repository pour les valeurs sensibles. Configurez-les dans l’onglet Secrets de l’éditeur de blueprint du repository plutôt que de les coder en dur dans les blueprints.
Pour les détails de syntaxe, consultez la référence Blueprint. Pour résoudre les échecs de build, consultez Configuration déclarative > Dépannage.