Introducción a Workflows

UrraWorkflow es una plataforma independiente dedicada exclusivamente a crear y ejecutar workflows de automatización: pipelines de builds, pruebas, tareas programadas o integraciones propias. No aloja ni despliega ninguna aplicación de terceros; eso es responsabilidad de Web Hosting.

El modelo: jobs, steps y dependencias

Un workflow se organiza en jobs, y cada job en una secuencia de steps. Cada step ejecuta una Action (por ejemplo, clonar un repositorio o correr un comando) con sus propios parámetros (with:).

• Dentro de un job, los steps corren siempre en orden, uno tras otro.
• Los jobs sin dependencias entre sí corren en paralelo.
• Un job puede declarar needs: [otro_job] para esperar a que otro job termine con éxito antes de empezar. Esto forma un DAG (grafo acíclico de dependencias): UrraWorkflow rechaza cualquier definición con dependencias circulares antes de guardarla.
• Si un job falla o es cancelado, sus dependientes se marcan SKIPPED en cascada (la misma semántica que usan GitHub Actions o GitLab CI): nunca corren como si nada hubiera pasado.

Dos formas de definir un workflow

Puedes crear y editar un workflow de dos maneras, sincronizadas entre sí:

• YAML ("Workflow avanzado"): escribes la definición completa a mano, con control total sobre cada detalle.
• Editor visual ("Workflow sencillo"): arrastras, conectas y configuras bloques en un lienzo, al estilo de un editor de diagramas de flujo. Cada bloque es un step; conectar dos bloques define el orden de ejecución.

Puedes alternar entre ambos modos en cualquier momento sobre el mismo workflow: el editor visual compila automáticamente el diagrama a la definición YAML equivalente (y viceversa). Ver El editor visual para el detalle de cómo se traduce un diagrama a jobs y steps.

Ejecución: contenedores efímeros y endurecidos

UrraWorkflow separa el panel (lo que usas para definir y disparar workflows) del componente que realmente construye y corre contenedores:

flowchart TB
    D[Dashboard Flask] -->|red interna 'control'| O[Orquestador]
    O -->|Docker API acotada| P[docker-proxy-orchestrator]
    O --> S1[Contenedor efímero<br/>step: shell.run / docker.run]
    O --> S2[Contenedor efímero<br/>step: docker.build]
    P -.acceso Docker.-> S1
    P -.acceso Docker.-> S2

El dashboard nunca tiene acceso a Docker. Cada step de tipo shell.run, docker.build o docker.run corre en su propio contenedor efímero (se crea para ese step y se destruye al terminar), sin privilegios (cap_drop: ALL, no-new-privileges), con límites de CPU/memoria y sin red por defecto salvo que el step la solicite explícitamente.

Siguiente paso: Primeros pasos.