> ## 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 nei blueprint

> Usa GitHub Actions per installare linguaggi, strumenti e SDK nel tuo ambiente Devin senza dover scrivere script shell.

Invece di scrivere script shell per installare strumenti, puoi fare riferimento direttamente a GitHub Actions nelle sezioni `initialize` o `maintenance` del tuo blueprint. Devin scarica ed esegue l'action durante la snapshot build, proprio come i runner CI di GitHub eseguono i passaggi delle action.

Questo è particolarmente utile per le action di configurazione dei linguaggi come `setup-python`, `setup-node` e `setup-go`, che gestiscono automaticamente la gestione delle versioni e la configurazione del PATH.

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

Aggiungi un passaggio `uses` a una qualsiasi sezione del tuo blueprint:

```yaml theme={null}
initialize:
  - name: Install Python 3.12
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
```

| Campo  | Tipo                 | Descrizione                                                                             |
| ------ | -------------------- | --------------------------------------------------------------------------------------- |
| `name` | string (facoltativo) | Etichetta leggibile dall'utente visualizzata nei log di build                           |
| `uses` | string               | Riferimento a una GitHub Action (vedi il [formato](#action-reference-format) qui sotto) |
| `with` | map (facoltativo)    | Parametri di input passati all'azione                                                   |
| `env`  | map (facoltativo)    | Variabili d'ambiente aggiuntive per il passaggio                                        |

<Info>
  Un passaggio deve specificare `run` (un comando shell) **oppure** `uses` (un'azione), non entrambi.
</Info>

<div id="action-reference-format">
  ## Formato di riferimento per le azioni
</div>

```
github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>
```

Il prefisso `github.com/` e il suffisso `@<ref>` sono entrambi **obbligatori**. Il ref è in genere un tag di versione come `v5`.

**Esempi:**

| Riferimento                                 | A cosa corrisponde                                             |
| ------------------------------------------- | -------------------------------------------------------------- |
| `github.com/actions/setup-python@v5`        | `actions/setup-python` al tag `v5`                             |
| `github.com/actions/setup-node@v4`          | `actions/setup-node` al tag `v4`                               |
| `github.com/gradle/actions/setup-gradle@v4` | repo `gradle/actions`, sottodirectory `setup-gradle`, tag `v4` |

<div id="passing-inputs">
  ## Passare input
</div>

Usa il campo `with` per passare input alla action. Tutti i valori vengono trattati come stringhe, in linea con il comportamento di GitHub Actions:

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

<Warning>
  **Racchiudi sempre tra virgolette i numeri di versione** nei valori `with`. YAML interpreta `3.10` senza virgolette come il numero in virgola mobile `3.1`, che non è ciò che vuoi. Scrivi invece `python-version: "3.10"`.
</Warning>

<div id="setting-environment-variables">
  ## Impostare le variabili d'ambiente
</div>

Usa il campo `env` per impostare variabili d'ambiente nell'ambito di un singolo passaggio della action:

```yaml theme={null}
initialize:
  - uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"
    env:
      RUNNER_DEBUG: "1"
```

Le variabili d'ambiente impostate da una action (tramite `GITHUB_ENV` o `GITHUB_PATH`) vengono propagate automaticamente ai passaggi successivi del blueprint.

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

<div id="python-project-with-a-specific-version">
  ### Progetto Python con una versione specifica
</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">
  ### Progetto 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">
  ### Combinare azioni e comandi shell
</div>

Azioni e comandi shell possono essere combinati liberamente nella stessa sezione:

```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">
  ### Progetto Java con 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 vs. script shell
</div>

Non è necessario usare le actions: anche i semplici comandi shell funzionano benissimo. Le actions sono comode quando lo script shell equivalente sarebbe lungo o soggetto a errori.

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

  <Tab title="Script shell equivalente">
    ```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">
  ## Come funziona
</div>

Quando Devin incontra un passaggio `uses` durante una snapshot build:

1. **Scarica** la repository della action (clone shallow del ref bloccato)
2. **Legge** i metadati `action.yml` della action per determinare il runtime e i punti di ingresso
3. **Crea** l'ambiente di esecuzione con le variabili `INPUT_*`, `GITHUB_*` e `RUNNER_*`
4. **Esegue** il passaggio `pre` della action (se definito) e poi il punto di ingresso `main`
5. **Propaga** gli effetti collaterali: tutte le voci scritte dalla action in `GITHUB_PATH` o `GITHUB_ENV` vengono applicate ai passaggi successivi del blueprint

<Info>
  Le action vengono eseguite al di fuori di un vero flusso di lavoro GitHub. Le variabili di contesto come `github.repository` vengono popolate con valori fittizi. Le action che richiedono accesso in tempo reale all'API di GitHub (ad es. commentare le pull request (PR) o creare release) non funzioneranno nei blueprint.
</Info>

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

* **Solo GitHub Actions Node.js** — Sono supportate solo le GitHub Actions che usano un runtime Node.js (`node16`, `node20`, `node24`). Le action basate su Docker e quelle composite non sono supportate.
* **Nessun ciclo di vita `post`** — Devin esegue i passaggi `pre` e `main`, ma salta i passaggi di pulizia `post`, poiché le build vengono eseguite in VM temporanee.
* **Contesto GitHub fittizio** — Le action che dipendono da chiamate API di GitHub, dai dati degli eventi del flusso di lavoro o dal contesto del repository potrebbero non funzionare correttamente, perché questi valori sono segnaposto nell'ambiente di build.
* **Blocca le versioni** — Fai sempre riferimento a un tag di versione specifico (ad es. `@v5`) anziché al nome di un branch, per ottenere build riproducibili.

<div id="related-pages">
  ## Pagine correlate
</div>

* [Configurazione dichiarativa dell'ambiente](/it/onboard-devin/environment/blueprints)
* [Riferimento del blueprint](/it/onboard-devin/environment/blueprint-reference)
* [Libreria dei template](/it/onboard-devin/environment/templates)