Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

Au lieu d’écrire des scripts shell pour installer des outils, vous pouvez faire directement référence à des GitHub Actions dans les sections initialize ou maintenance de votre blueprint. Devin télécharge et exécute l’action pendant le build du snapshot, de la même manière que les runners CI de GitHub exécutent les étapes d’une action. C’est particulièrement utile pour les actions de configuration de langages comme setup-python, setup-node et setup-go, qui gèrent automatiquement les versions et la configuration du PATH.

​
Syntaxe

Ajoutez une étape uses à n’importe quelle section de votre blueprint : 
initialize:
  - name: Install Python 3.12
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
ChampTypeDescription
namestring (facultatif)Libellé compréhensible par un humain affiché dans les logs du build
usesstringRéférence de GitHub Action (voir le format ci-dessous)
withmap (facultatif)Paramètres d’entrée transmis à l’action
envmap (facultatif)Variables d’environnement supplémentaires pour l’étape
Une étape doit spécifier soit run (une commande shell), soit uses (une action), mais pas les deux.

​
Format de référence d’action

github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>
Le préfixe github.com/ et le suffixe @<ref> sont tous deux obligatoires. La ref est généralement un tag de version comme v5. Exemples :
RéférenceCe à quoi elle correspond
github.com/actions/setup-python@v5actions/setup-python au tag v5
github.com/actions/setup-node@v4actions/setup-node au tag v4
github.com/gradle/actions/setup-gradle@v4repo gradle/actions, sous-répertoire setup-gradle, tag v4

​
Transmission des paramètres d’entrée

Utilisez le champ with pour transmettre des paramètres d’entrée à l’action. Toutes les valeurs sont traitées comme des chaînes de caractères, conformément au comportement de GitHub Actions : 
initialize:
  - uses: github.com/actions/setup-java@v4
    with:
      java-version: "21"
      distribution: "temurin"
Mettez toujours les numéros de version entre guillemets dans les valeurs with. YAML interprète 3.10 sans guillemets comme le nombre à virgule flottante 3.1, ce qui n’est pas le résultat souhaité. Écrivez plutôt python-version: "3.10".

​
Définir des variables d’environnement

Utilisez le champ env pour définir des variables d’environnement dont le périmètre est limité à une seule étape d’action : 
initialize:
  - uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"
    env:
      RUNNER_DEBUG: "1"
Les variables d’environnement définies par une action (via GITHUB_ENV ou GITHUB_PATH) sont automatiquement transmises aux étapes suivantes du blueprint.

​
Exemples

​
Projet Python avec une version spécifique

initialize:
  - name: Install Python 3.12
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

maintenance: |
  pip install -r requirements.txt

knowledge:
  - name: test
    contents: pytest

​
Projet multilingue

initialize:
  - name: Install Node.js
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"
  - name: Install Python
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
  - name: Install Go
    uses: github.com/actions/setup-go@v5
    with:
      go-version: "1.22"

​
Mélanger des actions et des commandes shell

Les actions et les commandes shell peuvent être mélangées librement dans la même section : 
initialize:
  - name: Install Python
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
  - name: Install project tools
    run: pip install ruff pytest
  - name: Install Node.js
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"
  - name: Install frontend deps
    run: npm install -g pnpm

​
Projet Java avec Gradle

initialize:
  - name: Install JDK 21
    uses: github.com/actions/setup-java@v4
    with:
      java-version: "21"
      distribution: "temurin"
  - name: Install Gradle
    uses: github.com/gradle/actions/setup-gradle@v4

maintenance: |
  ./gradlew dependencies

knowledge:
  - name: build
    contents: ./gradlew build
  - name: test
    contents: ./gradlew test

​
Actions ou scripts shell

Vous n’avez pas besoin d’utiliser des actions — de simples commandes shell fonctionnent très bien. Les actions sont pratiques lorsque le script shell équivalent serait long ou source d’erreurs. 
initialize:
  - uses: github.com/actions/setup-go@v5
    with:
      go-version: "1.23"

​
Fonctionnement

Lorsque Devin rencontre une étape uses lors d’un build du snapshot :
  1. Télécharge le dépôt de l’action (clone superficiel de la référence épinglée)
  2. Lit les métadonnées action.yml de l’action afin de déterminer l’environnement d’exécution et les points d’entrée
  3. Construit l’environnement d’exécution avec les variables INPUT_*, GITHUB_* et RUNNER_*
  4. Exécute l’étape pre de l’action (si elle est définie), puis le point d’entrée main
  5. Propage les effets de bord — toutes les entrées écrites dans GITHUB_PATH ou GITHUB_ENV par l’action sont appliquées aux étapes de blueprint suivantes
Les actions s’exécutent en dehors d’un véritable workflow GitHub. Les variables de contexte comme github.repository sont renseignées avec des valeurs factices. Les actions qui nécessitent un accès direct à l’API GitHub (p. ex., commenter des pull requests, créer des releases) ne fonctionneront pas dans les blueprints.

​
Limitations

  • Actions Node.js uniquement — Seules les GitHub Actions qui utilisent un environnement d’exécution Node.js (node16, node20, node24) sont prises en charge. Les actions basées sur Docker et les actions composites ne sont pas prises en charge.
  • Pas de phase post — Devin exécute les étapes pre et main, mais ignore les étapes de nettoyage post, car les builds s’exécutent dans des VM temporaires.
  • Contexte GitHub simulé — Les actions qui s’appuient sur des appels d’API GitHub, des données d’événement de workflow ou le contexte du dépôt peuvent ne pas fonctionner correctement, car ces valeurs sont factices dans l’environnement de build.
  • Figez vos versions — Utilisez toujours un tag de version spécifique (p. ex., @v5) plutôt qu’un nom de branche afin d’obtenir des builds reproductibles.