Skip to main content

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.

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.

​
Sintaxe

Adicione uma etapa uses em qualquer seção do seu blueprint: 
initialize:
  - name: Install Python 3.12
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
CampoTipoDescrição
namestring (optional)Rótulo legível exibido nos logs de build
usesstringReferência de GitHub Action (veja o formato abaixo)
withmap (optional)Parâmetros de entrada passados para a ação
envmap (optional)Variáveis de ambiente extras para a etapa
Uma etapa deve especificar run (um comando de shell) ou uses (uma ação), não ambos.

​
Formato de referência de ações

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ênciaNo que ela resulta
github.com/actions/setup-python@v5actions/setup-python na tag v5
github.com/actions/setup-node@v4actions/setup-node na tag v4
github.com/gradle/actions/setup-gradle@v4repo gradle/actions, subdiretório setup-gradle, tag v4

​
Fornecendo entradas

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: 
initialize:
  - uses: github.com/actions/setup-java@v4
    with:
      java-version: "21"
      distribution: "temurin"
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".

​
Definir variáveis de ambiente

Use o campo env para definir variáveis de ambiente válidas apenas para uma única etapa de ação: 
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.

​
Exemplos

​
Projeto em Python com uma versão específica

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

​
Projeto multilíngue

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"

​
Combinando ações com comandos de shell

Ações e comandos de shell podem ser combinados livremente na mesma seção: 
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

​
Projeto Java com 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 vs. scripts de shell

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. 
initialize:
  - uses: github.com/actions/setup-go@v5
    with:
      go-version: "1.23"

​
Como funciona

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

​
Limitações

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