UrraHostingDocs

Docs Casos de uso

Volver

Caso de uso: pipeline de build, pruebas y notificación

Clonar un repositorio, construir su imagen, probarla y notificar el resultado por webhook con UrraWorkflow.

Objetivo

Automatizar un pipeline típico de integración continua: al llegar un cambio, clonar el repositorio, construir la imagen Docker de la aplicación, correr sus pruebas dentro de esa misma imagen y avisar el resultado a un canal externo (por ejemplo, un webhook de Slack o Discord).

El workflow

version: "1"
workflow:
  name: Build y notificación de despliegue
  description: Clona el repositorio, construye la imagen, la prueba y notifica el resultado.

jobs:
  build:
    steps:
      - id: checkout
        uses: git.checkout@1
        with:
          repository: "https://github.com/mi-organizacion/mi-app.git"
          ref: main

      - id: build
        uses: docker.build@1
        with:
          tag: "mi-app:{{ execution.id }}"

      - id: test
        uses: docker.run@1
        with:
          image: "{{ steps.build.outputs.image }}"
          command: ["npm", "test"]
    outputs:
      image: "{{ steps.build.outputs.image }}"

  notify:
    needs: [build]
    steps:
      - id: notify
        uses: http.request@1
        with:
          url: "https://hooks.example.com/mi-canal"
          method: POST
          headers:
            Content-Type: application/json
          body: '{"text": "Imagen {{ jobs.build.outputs.image }} construida y probada correctamente."}'

El mismo flujo, como diagrama

flowchart LR
    subgraph build["Job: build"]
        direction LR
        C["checkout<br/>git.checkout@1"] --> B["build<br/>docker.build@1"] --> T["test<br/>docker.run@1"]
    end
    subgraph notify["Job: notify"]
        N["notify<br/>http.request@1"]
    end
    build -->|needs| notify

Si armaras este mismo pipeline en el editor visual, conectarías los tres bloques de build en línea recta (una sola cadena, por lo que se compilan en un único job) y luego un cuarto bloque notify conectado a la salida de test; como ese es el único punto donde termina la cadena de build, el editor lo coloca en un job aparte con needs: [build] (ver El editor visual para el detalle de esta regla de compilación).

Por qué está dividido en dos jobs

  • build agrupa una cadena estrictamente secuencial: no tiene sentido ejecutar test antes de que exista la imagen, ni notificar antes de probarla.
  • notify depende de build (needs: [build]) en vez de ser un cuarto step del mismo job, para que solo se ejecute si build termina en SUCCESS: si el checkout, el build o las pruebas fallan, notify se marca SKIPPED en cascada y nunca se llega a avisar un resultado incorrecto como si fuera exitoso.

Disparar el pipeline automáticamente

Para que este workflow corra en cada push, crea un trigger de tipo webhook (ver Triggers) y apunta el webhook de tu proveedor Git (GitHub, GitLab, etc.) a la URL que te entrega.

Referencias