Skip to main content
Em vez de escrever scripts de shell para instalar ferramentas, você pode usar GitHub Actions diretamente na seção initialize do seu blueprint. O Devin baixa e executa a GitHub Action durante a build do snapshot, da mesma forma que os runners de CI do GitHub executam etapas de GitHub Action. Isso é especialmente útil para GitHub 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 na seção initialize do seu blueprint:
Uma etapa deve especificar run (um comando de shell) ou uses (uma GitHub Action), não ambos.
Etapas uses não são suportadas em maintenance. Uma etapa de maintenance com uses faz o build do snapshot falhar com 'uses' steps are not supported in maintenance sections ... Actions can only run during initialize. Coloque as GitHub Actions em initialize e mantenha maintenance apenas com etapas run. Etapas de post-build no nível de organização e de enterprise também podem usar GitHub Actions.

​
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 GitHub Action (clone superficial na ref fixada)
  2. Lê os metadados action.yml da GitHub Action para determinar o tipo de GitHub Action (runs.using) e os pontos de entrada
  3. Monta o ambiente de execução com as variáveis INPUT_*, GITHUB_* e RUNNER_*
  4. Executa a GitHub Action conforme seu tipo:
    • GitHub Actions em Node.js — executa o script pre (se definido) e, em seguida, o main
    • GitHub Actions compostas — executa cada etapa de runs.steps em ordem, incluindo etapas run e uses aninhadas
    • GitHub Actions em Docker — cria a imagem a partir do Dockerfile da GitHub Action (ou baixa uma imagem docker://) e então executa o contêiner, incluindo o pre-entrypoint, se definido
  5. Propaga os efeitos colaterais — todas as entradas gravadas em GITHUB_PATH ou GITHUB_ENV pela GitHub Action são aplicadas às etapas subsequentes do blueprint
As GitHub Actions são executadas fora de um workflow real do GitHub. Variáveis de contexto como github.repository são preenchidas com valores simulados. GitHub Actions que exigem acesso ativo à API do GitHub (por exemplo, comentar em PRs ou criar releases) não funcionarão em blueprints.

​
Limitações

  • Tipos de GitHub Action suportados — Blueprints suportam estes tipos de GitHub Action (runs.using):
  • Não em maintenance — Etapas uses são executadas em initialize e post-build, mas não podem ser executadas em maintenance. Veja Sintaxe.
  • Sem ciclo de vida post — O Devin executa as etapas pre e main (e o pre-entrypoint de uma GitHub Action Docker), mas pula as etapas de limpeza post (post e post-entrypoint), já que os builds são executados em VMs descartáveis.
  • Contexto simulado do GitHub — 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.