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

> Use GitHub Actions para instalar linguagens, ferramentas e SDKs no ambiente do Devin sem escrever scripts de shell.

Em vez de escrever scripts de shell para instalar ferramentas, você pode usar GitHub Actions diretamente nas seções `initialize` ou `maintenance` do seu blueprint. O Devin baixa e executa a action durante a build do snapshot, da mesma forma que os runners de CI do GitHub executam etapas de action.

Isso é especialmente útil para actions de configuração de linguagens, como `setup-python`, `setup-node` e `setup-go`, que cuidam automaticamente do gerenciamento de versões e da configuração do PATH.

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

Adicione uma etapa `uses` em qualquer seção do seu blueprint:

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

| Campo  | Tipo              | Descrição                                                                       |
| ------ | ----------------- | ------------------------------------------------------------------------------- |
| `name` | string (optional) | Rótulo legível exibido nos logs de build                                        |
| `uses` | string            | Referência de GitHub Action (veja o [formato](#action-reference-format) abaixo) |
| `with` | map (optional)    | Parâmetros de entrada passados para a ação                                      |
| `env`  | map (optional)    | Variáveis de ambiente extras para a etapa                                       |

<Info>
  Uma etapa deve especificar `run` (um comando de shell) **ou** `uses` (uma ação), não ambos.
</Info>

<div id="action-reference-format">
  ## Formato de referência de ações
</div>

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

O prefixo `github.com/` e o sufixo `@<ref>` são **obrigatórios**. A ref normalmente é uma tag de versão, como `v5`.

**Exemplos:**

| Referência                                  | No que ela resulta                                           |
| ------------------------------------------- | ------------------------------------------------------------ |
| `github.com/actions/setup-python@v5`        | `actions/setup-python` na tag `v5`                           |
| `github.com/actions/setup-node@v4`          | `actions/setup-node` na tag `v4`                             |
| `github.com/gradle/actions/setup-gradle@v4` | repo `gradle/actions`, subdiretório `setup-gradle`, tag `v4` |

<div id="passing-inputs">
  ## Fornecendo entradas
</div>

Use o campo `with` para fornecer entradas para a GitHub Action. Todos os valores são tratados como strings, de acordo com o comportamento do GitHub Actions:

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

<Warning>
  Sempre **coloque os números de versão entre aspas** nos valores de `with`. O YAML interpreta `3.10` sem aspas como o número de ponto flutuante `3.1`, o que não é o desejado. Em vez disso, use `python-version: "3.10"`.
</Warning>

<div id="setting-environment-variables">
  ## Definir variáveis de ambiente
</div>

Use o campo `env` para definir variáveis de ambiente válidas apenas para uma única etapa de ação:

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

As variáveis de ambiente definidas por uma ação (via `GITHUB_ENV` ou `GITHUB_PATH`) são propagadas automaticamente para as etapas subsequentes do blueprint.

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

<div id="python-project-with-a-specific-version">
  ### Projeto em Python com uma versão 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">
  ### Projeto multilíngue
</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">
  ### Combinando ações com comandos de shell
</div>

Ações e comandos de shell podem ser combinados livremente na mesma seção:

```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">
  ### Projeto Java com 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. scripts de shell
</div>

Você não precisa usar actions — comandos de shell simples funcionam bem. Actions são mais convenientes quando o script de shell equivalente seria longo ou sujeito a erros.

<Tabs>
  <Tab title="Com 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">
  ## Como funciona
</div>

Quando o Devin encontra uma etapa `uses` durante uma build do snapshot:

1. **Baixa** o repositório da action (clone superficial na ref fixada)
2. **Lê** os metadados `action.yml` da action para determinar o runtime e os pontos de entrada
3. **Monta** o ambiente de execução com as variáveis `INPUT_*`, `GITHUB_*` e `RUNNER_*`
4. **Executa** a etapa `pre` da action (se definida) e, em seguida, o ponto de entrada `main`
5. **Propaga** os efeitos colaterais — todas as entradas gravadas em `GITHUB_PATH` ou `GITHUB_ENV` pela action são aplicadas às etapas subsequentes do blueprint

<Info>
  As actions são executadas fora de um workflow real do GitHub. Variáveis de contexto como `github.repository` são preenchidas com valores simulados. Actions que exigem acesso ativo à API do GitHub (por exemplo, comentar em PRs ou criar releases) não funcionarão em blueprints.
</Info>

<div id="limitations">
  ## Limitações
</div>

* **Apenas GitHub Actions em Node.js** — Somente GitHub Actions que usam um runtime Node.js (`node16`, `node20`, `node24`) são suportadas. Actions baseadas em Docker e actions compostas não são suportadas.
* **Sem ciclo de vida `post`** — O Devin executa as etapas `pre` e `main`, mas pula as etapas de limpeza `post`, já que os builds são executados em VMs descartáveis.
* **Contexto simulado do GitHub** — Actions que dependem de chamadas à API do GitHub, dados de eventos do workflow ou contexto do repositório podem não funcionar corretamente, porque esses valores são placeholders no ambiente de build.
* **Fixe suas versões** — Sempre faça referência a uma tag de versão específica (por exemplo, `@v5`) em vez de um nome de branch para builds reproduzíveis.

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

* [Configuração declarativa de ambiente](/pt-BR/onboard-devin/environment/blueprints)
* [Referência de blueprints](/pt-BR/onboard-devin/environment/blueprint-reference)
* [Biblioteca de templates](/pt-BR/onboard-devin/environment/templates)