UrraHostingDocs

Docs Workflows

Volver

Acciones disponibles

Catálogo de Actions incorporadas y sus parámetros (`with:`).

Cada step fija una Action y su versión con uses: <id>@<version> (por ejemplo docker.build@1). El editor visual construye el panel de propiedades de cada bloque a partir del mismo catálogo que ves aquí, así que los campos coinciden exactamente entre ambos modos.

Action Qué hace Corre en
git.checkout@1 Clona un repositorio público por HTTPS Contenedor efímero
shell.run@1 Ejecuta un comando de shell Contenedor efímero
docker.build@1 Construye una imagen desde el workspace de la ejecución Contenedor efímero
docker.run@1 Corre un contenedor a partir de una imagen ya construida Contenedor efímero
http.request@1 Hace una petición HTTP saliente Proceso del dashboard

git.checkout@1

Clona un repositorio público por HTTPS en el workspace de la ejecución. Los repositorios privados por SSH todavía no están soportados desde un workflow.

Campo Tipo Obligatorio Descripción
repository texto Sí URL HTTPS del repositorio
ref texto Sí Rama o tag a clonar

Solo se permiten hosts de la lista ALLOWED_GIT_HOSTS configurada por el operador de tu instancia (por defecto github.com, gitlab.com, bitbucket.org). Salidas: sha (commit clonado), path (subcarpeta del workspace donde quedó el código).

shell.run@1

Ejecuta un comando de shell dentro de un contenedor efímero endurecido.

Campo Tipo Obligatorio Descripción
command texto largo Sí Comando a ejecutar
workdir texto No Directorio de trabajo dentro de /workspace
network selección No "" (sin red) o "runtime"
timeout_seconds número No Por defecto 300s

También admite env (mapa de variables de entorno) aunque el editor visual todavía no expone un campo dedicado para este step; puedes agregarlo escribiendo la definición en YAML directamente. Salidas: exit_code, logs.

docker.build@1

Construye una imagen desde el workspace de la ejecución (típicamente el resultado de un git.checkout@1 previo).

Campo Tipo Obligatorio Descripción
tag texto Sí Tag de la imagen resultante
path texto No Ruta del contexto de build (raíz del workspace si se deja vacío)
dockerfile texto No Ruta del Dockerfile (por defecto Dockerfile)

El árbol a construir pasa por las mismas validaciones de seguridad que un despliegue de Web Hosting: se rechaza si contiene Docker Compose, symlinks u hooks Git. Salida: image (tag final de la imagen construida).

docker.run@1

Corre un contenedor efímero a partir de una imagen ya construida por esta misma plataforma (normalmente el image que devuelve un docker.build@1 previo en el mismo workflow).

Campo Tipo Obligatorio Descripción
image texto Sí Imagen a correr, ej. {{ steps.build.outputs.image }}
command lista No Comando a ejecutar (vacío usa el CMD de la imagen)
env mapa No Variables de entorno
network selección No "" (sin red) o "runtime"
timeout_seconds número No Por defecto 300s

Salidas: exit_code, logs.

http.request@1

Hace una petición HTTP saliente. Es la única Action que corre dentro del propio proceso del dashboard, no en un contenedor aparte, porque no necesita acceso a Docker.

Campo Tipo Obligatorio Descripción
url texto Sí URL completa (http:// o https://)
method selección No GET (por defecto), POST, PUT, PATCH, DELETE, HEAD
headers mapa No Cabeceras HTTP
body texto largo No Cuerpo de la petición
timeout_seconds número No Por defecto 30s

Por seguridad (protección SSRF), si el host de url resuelve a una dirección privada, de loopback o interna, la petición se rechaza salvo que ese host esté en la lista ALLOWED_HTTP_HOSTS que autoriza el operador de tu instancia. Salidas: status (código HTTP), body (respuesta, hasta 1 MB).

Referenciar salidas entre steps y jobs

  • Dentro del mismo job: {{ steps.<id_del_step>.outputs.<nombre> }}.
  • Desde otro job (que declare needs: sobre el primero): un job expone sus salidas con un bloque outputs: que las toma de sus propios steps, y otros jobs las leen con {{ jobs.<id_del_job>.outputs.<nombre> }}.

Siguiente paso: Triggers.