Volver al blog
X24LABS

Empezando con Stitch Agent (v1)

La guía de setup original de v1: dos jobs de CI, una imagen Docker y un puñado de variables de entorno. Se conserva como referencia histórica.

Post histórico. Esta guía describe Stitch v1, que corría dentro de tu pipeline de CI y se distribuía mediante una imagen Docker. Si estás instalando Stitch hoy, seguí Empezando con Stitch 2.0 en su lugar. Los jobs stitch-monitor / stitch-heal y la imagen ghcr.io/x24labs/stitch ya no tienen mantenimiento.

Configurar Stitch toma menos de cinco minutos. Agregás dos jobs a tu configuración de CI y Stitch se encarga del resto. Sin servidores, sin API keys que manejar, sin dashboard que monitorear.

Requisitos previos

Setup en GitLab CI

Agregá estos dos jobs a tu .gitlab-ci.yml:

stitch-monitor:
  stage: .post
  image: ghcr.io/x24labs/stitch:latest
  script:
    - stitch monitor
  when: on_failure

stitch-heal:
  stage: .post
  image: ghcr.io/x24labs/stitch:latest
  script:
    - stitch heal
  needs: ["stitch-monitor"]
  when: on_failure

El job stitch-monitor se activa cuando cualquier job aguas arriba falla. Lee los logs e identifica el fallo. El job stitch-heal toma el diagnóstico y genera un arreglo.

Ambos jobs usan el stage .post, así que corren después de todos tus stages regulares. Solo se disparan con on_failure, o sea que no consumen compute cuando tu pipeline pasa.

Setup en GitHub Actions

Agregá un archivo de workflow en .github/workflows/stitch.yml:

name: Stitch
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  heal:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/x24labs/stitch:latest
    steps:
      - uses: actions/checkout@v4
      - run: stitch monitor && stitch heal

Este workflow se dispara cuando tu workflow de CI falla. Hace checkout del código, corre el monitor y aplica el arreglo.

Qué pasa después

Cuando tu pipeline falla:

  1. Stitch lee los logs del fallo
  2. Identifica el tipo de error y los archivos afectados
  3. Genera un parche puntual
  4. Valida el arreglo re-ejecutando las verificaciones que fallaron
  5. Si el arreglo pasa, empuja un commit a una rama de fix y abre un merge request

Revisás el MR como cualquier otro cambio de código. Por defecto, el auto-merge está apagado. Vos decidís cuándo aterriza el arreglo.

Configuración

Stitch funciona con cero configuración. Para equipos que quieren más control, podés ajustar opciones vía variables de entorno:

Verificar el setup

Empujá un commit que rompa a propósito una regla de lint o un test. Mirá el pipeline fallar, después mirá a Stitch tomarlo. Deberías ver una nueva rama y un merge request en pocos minutos.

Si algo no funciona, revisá los logs del job de Stitch. Contienen el diagnóstico completo y cualquier error encontrado durante el intento de arreglo.

Próximos pasos

Volver al blog