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 la section initialize 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 à la section initialize 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.

Les étapes uses ne sont pas prises en charge dans maintenance. Une étape maintenance contenant uses fait échouer le build du snapshot avec l’erreur 'uses' steps are not supported in maintenance sections ... Actions can only run during initialize. Placez les actions dans initialize et réservez maintenance aux étapes run. Les étapes post-build au niveau de l’organisation et de l’enterprise peuvent également utiliser des actions.

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 le type d’action (runs.using) et les points d’entrée
Construit l’environnement d’exécution avec les variables INPUT_*, GITHUB_* et RUNNER_*
Exécute l’action selon son type :
- Actions Node.js — exécute le script pre (s’il est défini), puis main
- Actions composites — exécute chaque étape de runs.steps dans l’ordre, y compris les étapes run et uses imbriquées
- Actions Docker — construit l’image à partir du Dockerfile de l’action (ou récupère une image docker://), puis exécute le container, y compris pre-entrypoint s’il est défini
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

Types d’actions pris en charge — Les blueprints prennent en charge ces types d’actions (runs.using) :
Type d’action Pris en charge
Node.js (node16, node20, node24) Oui
Composite (composite) Oui
Docker (docker) Builds Linux uniquement. Non pris en charge sur les builds Windows.
Pas dans maintenance — Les étapes uses s’exécutent dans initialize et post-build, mais ne peuvent pas s’exécuter dans maintenance. Voir Syntaxe.
Pas de phase post — Devin exécute les étapes pre et main (ainsi que le pre-entrypoint d’une action Docker), mais ignore les étapes de nettoyage post (post et post-entrypoint), 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.

Type d’action	Pris en charge
Node.js (`node16`, `node20`, `node24`)	Oui
Composite (`composite`)	Oui
Docker (`docker`)	Builds Linux uniquement. Non pris en charge sur les builds Windows.

​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