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

# GitHub Actions dans les blueprints

> Utilisez GitHub Actions pour installer des langages, des outils et des SDK dans votre environnement Devin sans écrire de scripts shell.

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.

<div id="syntax">
  ## Syntaxe
</div>

Ajoutez une étape `uses` à n’importe quelle section de votre blueprint :

```yaml theme={null}
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](#action-reference-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                             |

<Info>
  Une étape doit spécifier soit `run` (une commande shell), **soit** `uses` (une action), mais pas les deux.
</Info>

<div id="action-reference-format">
  ## Format de référence d’action
</div>

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

<div id="passing-inputs">
  ## Transmission des paramètres d’entrée
</div>

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 :

```yaml theme={null}
initialize:
  - uses: github.com/actions/setup-java@v4
    with:
      java-version: "21"
      distribution: "temurin"
```

<Warning>
  **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"`.
</Warning>

<div id="setting-environment-variables">
  ## Définir des variables d’environnement
</div>

Utilisez le champ `env` pour définir des variables d’environnement dont le périmètre est limité à une seule étape d’action :

```yaml theme={null}
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.

<div id="examples">
  ## Exemples
</div>

<div id="python-project-with-a-specific-version">
  ### Projet Python avec une version spécifique
</div>

```yaml theme={null}
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
```

<div id="multi-language-project">
  ### Projet multilingue
</div>

```yaml theme={null}
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"
```

<div id="mixing-actions-with-shell-commands">
  ### Mélanger des actions et des commandes shell
</div>

Les actions et les commandes shell peuvent être mélangées librement dans la même section :

```yaml theme={null}
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
```

<div id="java-project-with-gradle">
  ### Projet Java avec Gradle
</div>

```yaml theme={null}
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
```

<div id="actions-vs-shell-scripts">
  ### Actions ou scripts shell
</div>

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.

<Tabs>
  <Tab title="Avec GitHub Actions">
    ```yaml theme={null}
    initialize:
      - uses: github.com/actions/setup-go@v5
        with:
          go-version: "1.23"
    ```
  </Tab>

  <Tab title="Script shell équivalent">
    ```yaml theme={null}
    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
    ```
  </Tab>
</Tabs>

<div id="how-it-works">
  ## Fonctionnement
</div>

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

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

<div id="limitations">
  ## Limitations
</div>

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

<div id="related-pages">
  ## Pages associées
</div>

* [Configuration déclarative de l’environnement](/fr/onboard-devin/environment/blueprints)
* [Référence Blueprint](/fr/onboard-devin/environment/blueprint-reference)
* [Bibliothèque de modèles](/fr/onboard-devin/environment/templates)