El editor visual

Bloques y conexiones

En el editor visual, cada bloque es un step: representa una Action con sus parámetros ya configurados. Conectar la salida de un bloque con la entrada de otro define el orden de ejecución entre ambos.

• + Bloque agrega un nuevo step al lienzo; elige la Action desde el catálogo (ver Acciones).
• Arrastra un bloque para moverlo; arrastra desde su conector de salida hasta el conector de entrada de otro bloque para conectarlos.
• Haz clic en un bloque para abrir su panel de propiedades a la derecha: ahí configuras cada campo de with: (texto, número, lista de variables de entorno, etc.), el ID del step y puedes eliminarlo.

Cómo se traducen los bloques a jobs

UrraWorkflow guarda workflows como jobs con steps y dependencias needs: entre jobs (no entre steps sueltos). El editor visual traduce tu diagrama de steps a esa estructura automáticamente, siguiendo una regla simple:

Una cadena de bloques conectados uno a uno, sin ramificarse, se compila en un único job con varios steps. En cuanto un bloque tiene más de una conexión de salida (se ramifica) o más de una de entrada (varias ramas confluyen en él), ese punto se convierte en una frontera entre jobs, y la dependencia se expresa con needs:.

Ejemplo: cadena simple -> un job

flowchart LR
    A[checkout] --> B[build] --> C[test]

Se compila en un solo job con tres steps, en el mismo orden:

jobs:
  job-checkout:
    steps:
      - {id: checkout, uses: git.checkout@1, with: {...}}
      - {id: build, uses: docker.build@1, with: {...}}
      - {id: test, uses: docker.run@1, with: {...}}

Ejemplo: ramificación -> varios jobs

flowchart LR
    A[checkout] --> B[build-linux]
    A --> C[build-windows]

Como checkout se ramifica hacia dos bloques, cada rama pasa a ser su propio job, y ambos declaran needs: [job-checkout]:

jobs:
  job-checkout:
    steps: [{id: checkout, uses: git.checkout@1, with: {...}}]
  job-build-linux:
    needs: [job-checkout]
    steps: [{id: build-linux, uses: docker.build@1, with: {...}}]
  job-build-windows:
    needs: [job-checkout]
    steps: [{id: build-windows, uses: docker.build@1, with: {...}}]

Esto significa que build-linux y build-windows corren en paralelo en cuanto checkout termina con éxito. Lo mismo aplica al revés: si dos bloques confluyen en uno solo (fan-in), ese bloque de destino pasa a ser un job aparte que declara needs: sobre los jobs de ambas ramas.

Cambiar entre YAML y Diagrama

El botón YAML / Diagrama en la parte superior del editor cambia de modo sobre el mismo workflow:

• Al pasar de YAML a Diagrama, UrraWorkflow valida tu YAML primero; si tiene errores, te los muestra y no cambia de modo (para no perder ni ocultar la definición mientras la corriges).
• Al pasar de Diagrama a YAML, se genera la definición equivalente a partir del diagrama actual.

Siguiente paso: Acciones disponibles.