> ## 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 en blueprints

> Usa GitHub Actions para instalar lenguajes, herramientas y SDKs en tu entorno de Devin sin escribir scripts de shell.

En lugar de escribir scripts de shell para instalar herramientas, puedes hacer referencia directamente a GitHub Actions en las secciones `initialize` o `maintenance` de tu blueprint. Devin descarga y ejecuta la acción durante la compilación de instantánea, igual que los runners de CI de GitHub ejecutan los pasos de una acción.

Esto es especialmente útil para acciones de configuración de lenguajes como `setup-python`, `setup-node` y `setup-go`, que gestionan automáticamente las versiones y la configuración de PATH.

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

Agrega un paso `uses` a cualquier sección de tu blueprint:

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

| Campo  | Tipo              | Descripción                                                                             |
| ------ | ----------------- | --------------------------------------------------------------------------------------- |
| `name` | string (opcional) | Etiqueta legible para humanos que se muestra en los registros de compilación            |
| `uses` | string            | Referencia de GitHub Action (consulta el [formato](#action-reference-format) más abajo) |
| `with` | map (opcional)    | Parámetros de entrada que se pasan a la acción                                          |
| `env`  | map (opcional)    | Variables de entorno adicionales para el paso                                           |

<Info>
  Un paso debe especificar `run` (un comando de shell) **o** `uses` (una acción), no ambos.
</Info>

<div id="action-reference-format">
  ## Formato de referencia para acciones
</div>

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

El prefijo `github.com/` y el sufijo `@<ref>` son **obligatorios**. La ref suele ser una etiqueta de versión como `v5`.

**Ejemplos:**

| Referencia                                  | A qué corresponde                                                  |
| ------------------------------------------- | ------------------------------------------------------------------ |
| `github.com/actions/setup-python@v5`        | `actions/setup-python` en la etiqueta `v5`                         |
| `github.com/actions/setup-node@v4`          | `actions/setup-node` en la etiqueta `v4`                           |
| `github.com/gradle/actions/setup-gradle@v4` | repo `gradle/actions`, subdirectorio `setup-gradle`, etiqueta `v4` |

<div id="passing-inputs">
  ## Pasar parámetros de entrada
</div>

Usa el campo `with` para pasar parámetros de entrada a la acción. Todos los valores se tratan como cadenas, de acuerdo con el comportamiento de GitHub Actions:

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

<Warning>
  **Pon siempre entre comillas los números de versión** en los valores de `with`. YAML interpreta `3.10` sin comillas como el número decimal `3.1`, que no es lo deseado. En su lugar, escribe `python-version: "3.10"`.
</Warning>

<div id="setting-environment-variables">
  ## Configurar variables de entorno
</div>

Usa el campo `env` para definir variables de entorno con ámbito de un único paso de acción:

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

Las variables de entorno establecidas por una acción (mediante `GITHUB_ENV` o `GITHUB_PATH`) se propagan automáticamente a los pasos siguientes del blueprint.

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

<div id="python-project-with-a-specific-version">
  ### Proyecto en Python con una versión específica
</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">
  ### Proyecto multilingüe
</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">
  ### Combinar acciones y comandos de shell
</div>

Las acciones y los comandos de shell se pueden combinar libremente en la misma sección:

```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">
  ### Proyecto de 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">
  ### Acciones vs. scripts de shell
</div>

No es necesario usar acciones: los comandos de shell simples funcionan bien. Las acciones son prácticas cuando el script de shell equivalente sería largo o propenso a errores.

<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 de 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">
  ## Cómo funciona
</div>

Cuando Devin encuentra un paso `uses` durante una compilación de instantánea:

1. **Descarga** el repositorio de la acción (clonado superficial en la referencia fijada)
2. **Lee** los metadatos `action.yml` de la acción para determinar el entorno de ejecución y los puntos de entrada
3. **Construye** el entorno de ejecución con las variables `INPUT_*`, `GITHUB_*` y `RUNNER_*`
4. **Ejecuta** el paso `pre` de la acción (si está definido) y luego el punto de entrada `main`
5. **Propaga** los efectos secundarios: cualquier entrada que la acción escriba en `GITHUB_PATH` o `GITHUB_ENV` se aplica a los pasos posteriores del blueprint

<Info>
  Las acciones se ejecutan fuera de un workflow real de GitHub. Las variables de contexto como `github.repository` se rellenan con valores simulados. Las acciones que requieren acceso en tiempo real a la API de GitHub (p. ej., comentar en PR o crear versiones) no funcionarán en blueprints.
</Info>

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

* **Solo acciones de Node.js** — Solo se admiten GitHub Actions que usan un entorno de ejecución de Node.js (`node16`, `node20`, `node24`). No se admiten las acciones basadas en Docker ni las acciones compuestas.
* **Sin ciclo de vida `post`** — Devin ejecuta los pasos `pre` y `main`, pero omite los pasos de limpieza `post`, ya que las compilaciones se ejecutan en máquinas virtuales efímeras.
* **Contexto de GitHub simulado** — Es posible que las acciones que dependen de llamadas a la API de GitHub, datos de eventos del workflow o el contexto del repositorio no funcionen correctamente, porque estos valores son marcadores de posición en el entorno de compilación.
* **Fija tus versiones** — Haz referencia siempre a una etiqueta de versión específica (p. ej., `@v5`) en lugar de a un nombre de rama para lograr compilaciones reproducibles.

<div id="related-pages">
  ## Páginas relacionadas
</div>

* [Configuración declarativa de Environment](/es/onboard-devin/environment/blueprints)
* [Referencia de blueprint](/es/onboard-devin/environment/blueprint-reference)
* [Biblioteca de plantillas](/es/onboard-devin/environment/templates)