Exemples à copier-coller pour configurer l’environnement de Devin à travers les couches entreprise, organisation et dépôt
Cette page fournit des exemples autonomes de environment.yaml pour des scénarios courants. Chaque exemple couvre un seul aspect — combinez-les pour créer votre configuration complète.Pour une introduction à la syntaxe et aux concepts de environment.yaml, consultez Configuration de l’environnement. Pour plus de détails sur la syntaxe, consultez la Référence YAML.
Secrets : Les exemples font référence aux secrets via $SECRET_NAME. Configurez-les dans Settings → Secrets avant d’utiliser un exemple. Chaque exemple inclut une section réductible “Secrets requis” qui indique précisément quels secrets configurer et les valeurs attendues. N’intégrez jamais d’identifiants en dur dans votre environment.yaml.
Les configurations d’environnement sont appliquées par couches. Chaque couche s’appuie sur la précédente :
1
échelle du compte (Enterprise)
Certificats, proxy, DNS, VPN, signature de commit, paramètres régionaux, limites de ressources, identité git, miroirs APT.
S’applique à toutes les orgs et tous les dépôts.
2
échelle de l’organisation
environnement d’exécution de langage, configuration du registre du gestionnaire de packages, registre de conteneurs, outils partagés.
S’applique à tous les dépôts au sein de l’org.
3
Spécifique au dépôt
Commandes de build, installation des dépendances, commandes de test/lint, notes spécifiques au projet pour Devin.
S’applique à un seul dépôt.
Ce qui est défini à l’échelle du compte s’exécute d’abord, puis ce qui est défini à l’échelle de l’organisation, puis ce qui est spécifique au dépôt. Configurez chaque exemple au périmètre approprié dans Settings.
Ces exemples configurent une infrastructure au niveau de la machine qui s’applique à toutes les orgs et à tous les dépôts. Définissez-les dans Enterprise Settings (pour l’échelle du compte) ou dans Settings > Environment > Configuration à l’échelle de l’organisation (pour l’échelle de l’organisation).
Certificat d’autorité de certification d’entreprise
Votre organisation utilise une autorité de certification privée pour ses services internes. Devin a besoin du certificat racine pour accéder aux registres et aux outils internes via HTTPS.
Secrets requis
CORP_ROOT_CA_B64 — Certificat PEM encodé en base64 provenant de votre AC d’entreprise. Générez-le avec : cat corp-root-ca.crt | base64 -w0
initialize: - name: Install corporate CA certificate run: | echo "$CORP_ROOT_CA_B64" | base64 -d \ | sudo tee /usr/local/share/ca-certificates/corp-root-ca.crt > /dev/null sudo update-ca-certificates # Permettre à Node.js de faire confiance à l'AC d'entreprise echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corp-root-ca.crt' \ | sudo tee /etc/profile.d/node-ca.sh > /dev/null
Certaines organisations ont des autorités de certification distinctes pour différents services internes (par exemple, une pour le registre d’artefacts, une autre pour un serveur Git interne).
Secrets requis
CA_CERT_REGISTRY_B64 — Certificat PEM encodé en Base64 pour l’autorité de certification du registre d’artefacts
CA_CERT_GIT_B64 — Certificat PEM encodé en Base64 pour l’autorité de certification du serveur Git
initialize: - name: Install corporate CA certificates run: | # Decode and install each certificate echo "$CA_CERT_REGISTRY_B64" | base64 -d \ | sudo tee /usr/local/share/ca-certificates/registry-ca.crt > /dev/null echo "$CA_CERT_GIT_B64" | base64 -d \ | sudo tee /usr/local/share/ca-certificates/git-ca.crt > /dev/null sudo update-ca-certificates # Node.js: combine certs into a single bundle cat /usr/local/share/ca-certificates/registry-ca.crt \ /usr/local/share/ca-certificates/git-ca.crt \ > /tmp/corp-ca-bundle.crt echo "export NODE_EXTRA_CA_CERTS=/tmp/corp-ca-bundle.crt" \ | sudo tee /etc/profile.d/node-ca.sh > /dev/null
Définissez CORP_NO_PROXY sur une liste d’hôtes, séparés par des virgules, qui doivent ignorer le proxy, par exemple localhost,127.0.0.1,.corp.internal,10.0.0.0/8.
La configuration de base la plus courante en entreprise consiste à installer un certificat d’AC d’entreprise et à configurer un proxy à l’échelle du système.
Secrets requis
CORP_ROOT_CA_B64 — Certificat PEM encodé en Base64 provenant de votre AC d’entreprise
CORP_HTTP_PROXY — URL du proxy HTTP
CORP_HTTPS_PROXY — URL du proxy HTTPS
CORP_NO_PROXY — Hôtes séparés par des virgules pour contourner le proxy
Vos registres privés, serveurs Git ou autres services internes ne sont accessibles que via un VPN. Ce module doit s’exécuter avant les autres modules qui nécessitent un accès réseau aux ressources internes.
Secrets requis
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 VPN, si votre VPN nécessite une authentification par nom d’utilisateur/mot de passe
VPN_AUTH_PASS(facultatif) — Mot de passe VPN
WireGuard :
WG_CONFIG_B64 — Fichier de configuration WireGuard encodé en Base64. Générez-le avec : cat wg0.conf | base64 -w0
OpenVPN
WireGuard
initialize: - name: Install and configure OpenVPN run: | sudo DEBIAN_FRONTEND=noninteractive apt-get update -qq sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openvpn # Écrire la configuration VPN sudo mkdir -p /etc/openvpn/client echo "$VPN_CONFIG_B64" | base64 -d \ | sudo tee /etc/openvpn/client/corp.conf > /dev/null # Si le VPN nécessite une authentification par nom d'utilisateur/mot de passe if [ -n "${VPN_AUTH_USER:-}" ] && [ -n "${VPN_AUTH_PASS:-}" ]; then printf '%s\n%s\n' "$VPN_AUTH_USER" "$VPN_AUTH_PASS" \ | sudo tee /etc/openvpn/client/auth.txt > /dev/null sudo chmod 600 /etc/openvpn/client/auth.txt echo "auth-user-pass /etc/openvpn/client/auth.txt" \ | sudo tee -a /etc/openvpn/client/corp.conf > /dev/null fi # Démarrer le tunnel VPN sudo systemctl daemon-reload sudo systemctl enable --now openvpn-client@corp # Attendre que le tunnel soit établi for i in $(seq 1 30); do if ip link show tun0 >/dev/null 2>&1; then break; fi sleep 1 done
Votre projet nécessite des packages système qui ne figurent pas dans l’image Devin par défaut (par ex., des bibliothèques natives pour le traitement d’images ou la génération de PDF).
Définissez des variables d’environnement persistantes qui doivent être disponibles dans chaque session.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 et pour la session Devin (comme avec le $GITHUB_ENV de GitHub Actions).
Les images de base par défaut peuvent avoir des paramètres régionaux mal configurés. Configurez les paramètres régionaux et le fuseau horaire afin d’éviter les avertissements des outils de build, de Java, de Python et de Git.
initialize: - name: Configure locale and timezone run: | sudo DEBIAN_FRONTEND=noninteractive apt-get update -qq sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq locales # Générer et définir la locale sudo sed -i 's/^# *en_US.UTF-8/en_US.UTF-8/' /etc/locale.gen sudo locale-gen sudo update-locale LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 cat << 'LOCALE' | sudo tee /etc/profile.d/locale.sh > /dev/null export LANG="en_US.UTF-8" export LC_ALL="en_US.UTF-8" LOCALE # Définir le fuseau horaire sudo timedatectl set-timezone UTC 2>/dev/null || \ sudo ln -sfn /usr/share/zoneinfo/UTC /etc/localtime
Ces exemples installent des environnements d’exécution de langage et configurent les gestionnaires de package pour utiliser des registres privés. Définissez-les dans Settings > Environment > Configuration à l’échelle de l’organisation.
Si votre registre privé utilise un certificat d’autorité de certification d’entreprise, assurez-vous d’abord que le certificat d’autorité de certification est installé au niveau Enterprise. La configuration au niveau de l’organisation ci-dessous suppose que la confiance HTTPS est déjà établie.
La configuration des identifiants doit se faire dans maintenance, et non dans initialize. Les étapes qui écrivent des secrets (mots de passe de registre, jetons d’authentification) dans des fichiers de configuration doivent utiliser maintenance afin que les identifiants soient actualisés à chaque session. Le fichier de secrets est supprimé avant l’enregistrement de l’image machine, de sorte que les fichiers de configuration écrits pendant initialize n’auront pas d’identifiants valides au démarrage des sessions.
Installez le JDK et configurez Maven pour faire transiter toute la résolution des dépendances via votre dépôt privé (par exemple, Artifactory ou Nexus).
Le JDK 17 est préinstallé sur l’image de base de Devin. Ignorez l’étape d’installation ci-dessous si l’OpenJDK 17 par défaut suffit — vous n’avez besoin que de l’installation de Maven et de la configuration du registre.
Secrets requis
MAVEN_REGISTRY_URL — URL de votre registre Maven (par exemple, 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
Node.js + npm avec un registre privé associé à un périmètre
Configurez npm pour récupérer les packages d’un périmètre donné (par ex., @myorg/*) depuis un registre privé comme GitHub Packages, tandis que les packages publics continuent de provenir du registre npm par défaut.
Secrets requis
GITHUB_PACKAGES_TOKEN — jeton d’accès personnel ou jeton GitHub App avec le périmètre read:packages
maintenance: - name: Configure npm scoped registry run: | npm config set @myorg:registry https://npm.pkg.github.com npm config set //npm.pkg.github.com/:_authToken $GITHUB_PACKAGES_TOKEN
Remplacez @myorg par votre périmètre npm. Voici des URL courantes de registres privés :
Configurez Yarn (Classic v1 ou Berry v2+) pour récupérer des packages à partir d’un registre privé.
Yarn Classic (v1) est préinstallé sur l’image de base de Devin. Passez l’étape d’installation si vous n’avez besoin que de v1.
Secrets requis
NPM_REGISTRY_URL — URL complète de votre registre npm/Yarn
REGISTRY_TOKEN — Jeton d’authentification pour le registre (Berry uniquement)
Yarn Classic (v1)
Yarn Berry (v2+)
initialize: - name: Install Yarn Classic run: npm install -g yarnmaintenance: - name: Configure Yarn for private registry run: | yarn config set registry "$NPM_REGISTRY_URL" # Pour les packages avec scope : # yarn config set @myorg:registry "https://npm.pkg.github.com"
maintenance: - name: Configure Yarn Berry for private registry run: | yarn config set npmRegistryServer "$NPM_REGISTRY_URL" yarn config set npmAuthToken "$REGISTRY_TOKEN" # Pour les packages avec scope : # yarn config set npmScopes.myorg.npmRegistryServer "https://npm.pkg.github.com" # yarn config set npmScopes.myorg.npmAuthToken "$GITHUB_PACKAGES_TOKEN"
Installez Rust et configurez Cargo pour récupérer des crates depuis un registre privé.
Rust (via rustup) et Cargo sont préinstallés sur l’image de base de Devin. Ignorez l’étape d’installation si la toolchain stable par défaut est suffisante — vous n’avez besoin que de la configuration du registre.
Secrets requis
CARGO_REGISTRY_INDEX — URL de l’index du registre privé (par ex., sparse+https://cargo.corp.internal/api/v1/crates/)
CARGO_REGISTRY_TOKEN — Jeton d’authentification pour le registre privé
Si vous devez seulement 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.
Les jetons AWS CodeArtifact expirent au bout de 12 heures. Utilisez maintenance pour renouveler le jeton au début de chaque session. Cet exemple configure npm, pip et Maven pour utiliser CodeArtifact.
awscli est préinstallé sur l’image de base de Devin. Seuls le renouvellement du jeton et la configuration du registre sont nécessaires.
Secrets requis
AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY — identifiants IAM disposant des autorisations codeartifact:GetAuthorizationToken et sts:GetServiceBearerToken
CA_DOMAIN — Nom de votre domaine CodeArtifact
CA_DOMAIN_OWNER — ID du compte AWS 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 dépôts pour chaque écosystème
Ces exemples configurent, pour chaque dépôt, les étapes de build, la gestion des dépendances et les entrées de Knowledge. Définissez-les dans Settings > Environment > [your repo].
Un projet Node.js typique avec des commandes de lint, de test et de build.
initialize: | npm install -g pnpmmaintenance: | pnpm installknowledge: - name: lint contents: | Run `pnpm lint` to check for errors. Run `pnpm lint --fix` to auto-fix. - name: test contents: | Run `pnpm test` for the full test suite. Run `pnpm test -- --watch` during development. - name: build contents: | Run `pnpm build` to create a production build. Output goes to the `dist/` directory.
Un projet Python qui utilise uv pour gérer les dépendances.
initialize: - name: Install uv run: curl -LsSf https://astral.sh/uv/install.sh | shmaintenance: - name: Sync dependencies run: uv syncknowledge: - name: lint contents: | Run `uv run ruff check .` to lint. Run `uv run ruff format .` to format. - name: test contents: | Run `uv run pytest` for the full test suite. Run `uv run pytest -x` to stop on first failure.
Un projet Java utilisant Maven pour gérer les dépendances.
maintenance: - name: Resolve dependencies run: mvn dependency:resolve -U -qknowledge: - name: build contents: | Run `mvn clean package` to build. Run `mvn clean package -DskipTests` to build without tests. - name: test contents: | Run `mvn test` for unit tests. Run `mvn verify` for integration tests. - name: lint contents: | Run `mvn checkstyle:check` for style checks. Run `mvn spotbugs:check` for bug detection.
maintenance: - name: Download dependencies run: go mod downloadknowledge: - name: build contents: | Run `go build ./...` to build all packages. Run `go build -o bin/app ./cmd/app` to build the main binary. - name: test contents: | Run `go test ./...` for all tests. Run `go test -race ./...` to include race detection. Run `go test -v ./pkg/... -run TestSpecific` for a specific test. - name: lint contents: | Run `golangci-lint run` for linting (if installed). Run `go vet ./...` for basic static analysis.
maintenance: - name: Fetch dependencies run: cargo fetchknowledge: - name: build contents: | Run `cargo build` for a debug build. Run `cargo build --release` for a release build. - name: test contents: | Run `cargo test` for all tests. Run `cargo test -- --test-threads=1` for sequential execution. - name: lint contents: | Run `cargo clippy -- -D warnings` for lint checks. Run `cargo fmt --check` to verify formatting.
Un monorepo Java dans lequel différents services nécessitent des versions de JDK différentes. Installez les deux JDK lors de la configuration, puis utilisez des entrées Knowledge pour indiquer à Devin quelle valeur de JAVA_HOME utiliser pour chaque service.
Si le projet inclut déjà pre-commit parmi ses dépendances de développement (par exemple dans pyproject.toml), ignorez l’étape initialize et utilisez plutôt uv run pre-commit install --install-hooks ou pipx run pre-commit install --install-hooks dans maintenance.
Documentez l’architecture, les conventions et les processus de votre projet dans des entrées knowledge.
knowledge: - name: architecture contents: | This is a microservices application: - `api-gateway/` — Express.js reverse proxy (port 3000) - `auth-service/` — JWT authentication service (port 3001) - `user-service/` — User CRUD service (port 3002) - `shared/` — Shared protobuf definitions and utilities Services communicate via gRPC. The API gateway is the only public-facing service. - name: conventions contents: | - All API responses use the `{ data, error, meta }` envelope format - Database migrations are in `migrations/` and run with `npm run migrate` - Environment-specific config is in `config/{env}.json` - Feature flags are managed via LaunchDarkly (SDK key in $LD_SDK_KEY) - name: testing contents: | Unit tests: `npm test` Integration tests: `npm run test:integration` (requires Docker for Postgres) E2E tests: `npm run test:e2e` (requires all services running) Coverage report: `npm run test:coverage` (must be > 80% for CI to pass) - name: deployment contents: | CI/CD runs on GitHub Actions. Merges to `main` auto-deploy to staging. Production deploys require a manual approval step in the Actions UI. Docker images are pushed to ECR: 123456789.dkr.ecr.us-east-1.amazonaws.com/
Ces exemples montrent comment les configurations à l’échelle de l’entreprise et au niveau de l’organisation se combinent. En pratique, vous les répartiriez entre différents périmètres — ils sont regroupés 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 — tous configurés pour pointer vers une seule instance Artifactory.
Secrets requis
Réseau et confiance (à l’é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 à exclure du proxy
Identifiants du registre (à l’échelle de l’organisation) :
ARTIFACTORY_USER — Nom d’utilisateur Artifactory
ARTIFACTORY_TOKEN — Jeton d’API ou mot de passe Artifactory
ARTIFACTORY_MAVEN_URL — URL du dépôt Maven (par ex., https://artifactory.example.com/artifactory/maven-virtual)
ARTIFACTORY_PYPI_URL — URL du dépôt PyPI (par ex., https://user:token@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple)
ARTIFACTORY_NPM_URL — URL du dépôt npm (par ex., https://artifactory.example.com/artifactory/api/npm/npm-virtual)
ARTIFACTORY_DOCKER_URL — URL du registre Docker (par ex., artifactory.example.com)
Cela serait généralement réparti sur trois périmètres :
À l’échelle du compte (initialize) : certificat et proxy
À l’échelle de l’organisation (initialize) : installation des environnement d’exécution de langage
À l’échelle de l’organisation (maintenance) : identifiants du registre (actualisés à chaque session)
Présenté ici de façon combinée à titre de 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.
Dans un environnement entièrement 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.
Secrets requis
Certificats :
CORP_ROOT_CA_B64 — certificat d’autorité de certification d’entreprise encodé en Base64
Accès au miroir :
APT_MIRROR_URL — URL du miroir APT Ubuntu interne
MIRROR_USER — nom d’utilisateur pour l’authentification au miroir
MIRROR_PASS — mot de passe pour l’authentification au miroir
JDK_TARBALL_URL — URL de téléchargement de l’archive JDK depuis le miroir interne
NODE_TARBALL_URL — URL de téléchargement de l’archive Node.js depuis le miroir interne
Registres de packages :
INTERNAL_MAVEN_URL — URL du registre Maven interne
Dans les environnements cloisonnés (air-gapped), tous les outils dont Devin a besoin (environnements d’exécution, outils CLI, etc.) doivent être disponibles sur vos miroirs internes. Les registres publics et les sites de téléchargement sont inaccessibles.
Une configuration d’entreprise complète combinant la connectivité VPN avec des certificats, un proxy et la prise en charge de plusieurs langages. Voici l’ordre des opérations recommandé.
Secrets requis
VPN:
VPN_CONFIG_B64 — Fichier de configuration OpenVPN encodé en Base64
Réseau et 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 à exclure du 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
initialize: # 1. VPN — doit être configuré en premier pour que les ressources internes soient accessibles - name: Establish VPN connection run: | sudo DEBIAN_FRONTEND=noninteractive apt-get update -qq sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openvpn sudo mkdir -p /etc/openvpn/client echo "$VPN_CONFIG_B64" | base64 -d \ | sudo tee /etc/openvpn/client/corp.conf > /dev/null sudo systemctl daemon-reload sudo systemctl enable --now openvpn-client@corp for i in $(seq 1 30); do if ip link show tun0 >/dev/null 2>&1; then break; fi sleep 1 done # 2. DNS — résoudre les noms d'hôtes internes - name: Configure DNS run: | sudo mkdir -p /etc/systemd/resolved.conf.d cat << 'DNS' | sudo tee /etc/systemd/resolved.conf.d/corp.conf > /dev/null [Resolve] DNS=10.0.0.53 Domains=corp.internal DNS sudo systemctl restart systemd-resolved || true # 3. Certificats — faire confiance aux autorités de certification internes - name: Install CA certificate run: | echo "$CORP_ROOT_CA_B64" | base64 -d \ | sudo tee /usr/local/share/ca-certificates/corp-root-ca.crt > /dev/null sudo update-ca-certificates echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corp-root-ca.crt' \ | sudo tee /etc/profile.d/node-ca.sh > /dev/null # 4. Proxy — acheminer le trafic via le proxy d'entreprise - name: Configure proxy run: | cat << 'PROXY' | sudo tee /etc/profile.d/proxy.sh > /dev/null export http_proxy="$CORP_HTTP_PROXY" export https_proxy="$CORP_HTTPS_PROXY" export no_proxy="$CORP_NO_PROXY" export HTTP_PROXY="$CORP_HTTP_PROXY" export HTTPS_PROXY="$CORP_HTTPS_PROXY" export NO_PROXY="$CORP_NO_PROXY" PROXY source /etc/profile.d/proxy.sh # 5. Environnements d'exécution - name: Install JDK 17 run: | sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-17-jdk-headless echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' \ | sudo tee /etc/profile.d/java.sh > /dev/null - name: Install Node.js tooling run: npm install -g pnpm - name: Install uv run: curl -LsSf https://astral.sh/uv/install.sh | shmaintenance: - name: Configure git proxy run: | git config --global http.proxy "$CORP_HTTP_PROXY" git config --global https.proxy "$CORP_HTTPS_PROXY" - name: Configure Maven run: | mkdir -p ~/.m2 cat > ~/.m2/settings.xml << EOF <settings> <mirrors> <mirror> <id>corp</id> <mirrorOf>*</mirrorOf> <url>$MAVEN_REGISTRY_URL</url> </mirror> </mirrors> <servers> <server> <id>corp</id> <username>$REGISTRY_USER</username> <password>$REGISTRY_PASS</password> </server> </servers> </settings> EOF - name: Configure npm run: | npm config set registry "$NPM_REGISTRY_URL" NPM_HOST=$(echo "$NPM_REGISTRY_URL" | sed 's|https\?://||;s|/.*||') npm config set "//${NPM_HOST}/:_authToken" "$REGISTRY_TOKEN" - name: Configure pip/uv run: | mkdir -p ~/.config/pip cat > ~/.config/pip/pip.conf << EOF [global] index-url = https://$REGISTRY_USER:$REGISTRY_PASS@${PYPI_REGISTRY_HOST}/simple EOF echo "export UV_INDEX_URL=https://$REGISTRY_USER:$REGISTRY_PASS@${PYPI_REGISTRY_HOST}/simple" \ | sudo tee /etc/profile.d/uv-registry.sh > /dev/null
L’ordre des étapes initialize est important. Le VPN doit être configuré en premier (pour que les hôtes internes soient accessibles), puis le DNS (pour que les noms se résolvent), puis les certificats (pour que HTTPS fonctionne), puis le proxy (pour que le trafic soit correctement acheminé), et enfin les environnements d’exécution (qui peuvent télécharger depuis des miroirs internes).
Testez d’abord les commandes dans une session — exécutez-les manuellement dans une session Devin avant de les ajouter à votre configuration. C’est plus rapide que d’attendre un cycle de build complet.
Utilisez initialize pour les outils à installer une seule fois, maintenance pour les dépendances — tout ce qui prend plusieurs minutes à installer (compilateurs, binaires volumineux, 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 au début de chaque session.
Utilisez $ENVRC pour les variables d’environnement — n’écrivez pas dans .bashrc ou .profile. $ENVRC est le mécanisme pris en charge pour définir des variables d’environnement d’une étape et d’une session à l’autre.
Nommez vos étapes — la forme développée avec des champs name permet de repérer bien plus facilement les échecs dans les journaux de build.
Utilisez des sous-shells pour les monorepos — (cd packages/foo && npm install) s’exécute dans un sous-shell afin que les étapes suivantes ne soient pas affectées par le changement de répertoire.
Pour en savoir plus sur la syntaxe et les détails d’exécution, consultez la Référence YAML. Pour résoudre les échecs de build, consultez Dépannage et FAQ.