Skip to main content
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:
Uma etapa deve especificar run (um comando de shell) ou uses (uma ação), não ambos.

​
Formato de referência de ações

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

​
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:
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:
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

​
Projeto multilíngue

​
Combinando ações com comandos de shell

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

​
Projeto Java com Gradle

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

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