Skip to main content
En lugar de escribir scripts de shell para instalar herramientas, puedes hacer referencia directamente a GitHub Actions en la sección initialize 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.

​
Sintaxis

Agrega un paso uses a la sección initialize de tu blueprint:
Un paso debe especificar run (un comando de shell) o uses (una acción), no ambos.
Los pasos uses no son compatibles en maintenance. Un paso de maintenance con uses hace que falle la compilación de instantánea con 'uses' steps are not supported in maintenance sections ... Actions can only run during initialize. Coloca las acciones en initialize y limita maintenance a pasos run. Los pasos post-build de nivel de organización y de nivel Enterprise también pueden usar acciones.

​
Formato de referencia para acciones

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

​
Pasar parámetros de entrada

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

​
Configurar variables de entorno

Usa el campo env para definir variables de entorno con ámbito de un único paso de acción:
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.

​
Ejemplos

​
Proyecto en Python con una versión específica

​
Proyecto multilingüe

​
Combinar acciones y comandos de shell

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

​
Proyecto de Java con Gradle

​
Acciones vs. scripts de shell

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.

​
Cómo funciona

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 tipo de acción (runs.using) y los puntos de entrada
  3. Construye el entorno de ejecución con las variables INPUT_*, GITHUB_* y RUNNER_*
  4. Ejecuta la acción según su tipo:
    • Acciones de Node.js: ejecuta el script pre (si está definido) y luego main
    • Acciones compuestas: ejecuta cada paso de runs.steps en orden, incluidos los pasos anidados run y uses
    • Acciones de Docker: compila la imagen a partir del Dockerfile de la acción (o descarga una imagen docker://) y luego ejecuta el contenedor, incluido pre-entrypoint si está definido
  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
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.

​
Limitaciones

  • Tipos de acción admitidos — Los blueprints admiten estos tipos de acción (runs.using):
  • No en maintenance — Los pasos uses se ejecutan en initialize y post-build, pero no pueden ejecutarse en maintenance. Consulta Sintaxis.
  • Sin ciclo de vida post — Devin ejecuta los pasos pre y main (y el pre-entrypoint de una acción de Docker), pero omite los pasos de limpieza post (post y post-entrypoint), 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.