Skip to main content
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.

Démarrage rapide

Blueprints minimaux pour les configurations les plus courantes. Copiez-en un, collez-le dans l’éditeur de blueprints, et le tour est joué.

Blueprints du dépôt

É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].

Python

Configuration recommandée pour les projets Python qui utilisent uv pour la gestion des dépendances.

Node.js

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.

Go

Configuration Go standard avec modules.

Java

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.

Ruby on Rails

Configuration de Rails avec PostgreSQL.

Rust

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.

Monorepos

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.

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.

Registres Node.js

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>

Registres Python

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

Registres JVM

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>

Autres registres

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
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).

Réseau et connectivité

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.
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.
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.
Pour plus d’informations sur la configuration du VPN, consultez Configuration du VPN.
Vos services internes utilisent des noms DNS privés qui ne sont pas résolubles via le DNS public.

Identité et sécurité

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.

Configuration du système

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).
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.
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.
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.
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

Patterns avancés

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.
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).
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.
Installez des packages système, des binaires personnalisés et configurez le PATH dans initialize.
Devin prend en charge l’exécution de GitHub Actions directement dans la section initialize d’un blueprint. Cela est utile pour installer des versions spécifiques d’outils via les mêmes actions que celles utilisées par votre CI.
Des actions comme setup-node et setup-python modifient le PATH et les variables d’environnement. Les binaires installés par une action sont disponibles dans toutes les étapes suivantes et dans maintenance. Les actions Node.js et composites sont prises en charge ; les actions Docker ne le sont que sur les builds Linux. Les étapes uses ne peuvent pas s’exécuter dans maintenance. Voir les limites des GitHub Actions.
Vous n’avez pas besoin de GitHub Actions pour la configuration de base des outils. Des commandes shell directes (nvm install 20, curl ... | sh, apt-get install) fonctionnent tout aussi bien et sont souvent plus simples. Les GitHub Actions sont surtout utiles si vous voulez reproduire exactement votre configuration CI ou bénéficier de la praticité d’actions comme setup-java, qui gèrent plusieurs distributions.
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.
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.

Exemples full-stack

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.
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.
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.
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.
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.