GitHub Actions dans les blueprints

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"

Champ	Type	Description
`name`	string (facultatif)	Libellé compréhensible par un humain affiché dans les logs du build
`uses`	string	Référence de GitHub Action (voir le format ci-dessous)
`with`	map (facultatif)	Paramètres d’entrée transmis à l’action
`env`	map (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érence	Ce à quoi elle correspond
`github.com/actions/setup-python@v5`	`actions/setup-python` au tag `v5`
`github.com/actions/setup-node@v4`	`actions/setup-node` au tag `v4`
`github.com/gradle/actions/setup-gradle@v4`	repo `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.

Avec GitHub Actions
Script shell équivalent

initialize:
  - uses: github.com/actions/setup-go@v5
    with:
      go-version: "1.23"

initialize: |
  GO_VERSION=1.23.5
  ARCH=$(dpkg --print-architecture)
  curl -fsSL "https://go.dev/dl/go${GO_VERSION}.linux-${ARCH}.tar.gz" \
    | sudo tar -xz -C /usr/local
  echo 'export PATH="/usr/local/go/bin:$HOME/go/bin:$PATH"' \
    | sudo tee /etc/profile.d/golang.sh > /dev/null

Fonctionnement

Lorsque Devin rencontre une étape uses lors d’un build du snapshot :

Télécharge le dépôt de l’action (clone superficiel de la référence épinglée)
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
Construit l’environnement d’exécution avec les variables INPUT_*, GITHUB_* et RUNNER_*
Exécute l’étape pre de l’action (si elle est définie), puis le point d’entrée main
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.

​Syntaxe

​Format de référence d’action

​Transmission des paramètres d’entrée

​Définir des variables d’environnement

​Exemples

​Projet Python avec une version spécifique

​Projet multilingue

​Mélanger des actions et des commandes shell

​Projet Java avec Gradle

​Actions ou scripts shell

​Fonctionnement

​Limitations

​Pages associées

Syntaxe

Format de référence d’action

Transmission des paramètres d’entrée

Définir des variables d’environnement

Exemples

Projet Python avec une version spécifique

Projet multilingue

Mélanger des actions et des commandes shell

Projet Java avec Gradle

Actions ou scripts shell

Fonctionnement

Limitations

Pages associées