Voltar ao blog
X24LABS

Primeiros passos com o Stitch Agent (v1)

O guia de setup original do v1: dois jobs de CI, uma imagem Docker e um punhado de variáveis de ambiente. Mantido para referência histórica.

Post histórico. Este guia descreve o Stitch v1, que rodava dentro do seu pipeline de CI e era distribuído via imagem Docker. Se você está instalando o Stitch hoje, siga Primeiros passos com o Stitch 2.0. Os jobs stitch-monitor / stitch-heal e a imagem ghcr.io/x24labs/stitch não são mais mantidos.

Configurar o Stitch leva menos de cinco minutos. Você adiciona dois jobs à sua configuração de CI e o Stitch cuida do resto. Sem servidores, sem API keys para gerenciar, sem dashboard para monitorar.

Pré-requisitos

Setup no GitLab CI

Adicione estes dois jobs ao seu .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

O job stitch-monitor ativa quando qualquer job upstream falha. Ele lê os logs e identifica a falha. O stitch-heal pega o diagnóstico e gera uma correção.

Ambos os jobs usam o stage .post, então rodam depois de todos os stages regulares do seu pipeline. Só disparam com on_failure, ou seja, custam zero tempo de compute quando seu pipeline passa.

Setup no GitHub Actions

Adicione um arquivo de workflow em .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 dispara quando seu workflow de CI falha. Ele faz checkout do código, roda o monitor e aplica a correção.

O que acontece a seguir

Quando seu pipeline falha:

  1. Stitch lê os logs da falha
  2. Identifica o tipo do erro e os arquivos afetados
  3. Gera um patch direcionado
  4. Valida a correção re-executando as checagens que falharam
  5. Se a correção passa, ele faz push de um commit em um branch de fix e abre um merge request

Você revisa o MR como qualquer outra mudança de código. Por padrão, auto-merge é desligado. Você decide quando a correção entra.

Configuração

Stitch funciona com zero configuração. Para times que querem mais controle, você pode definir opções via variáveis de ambiente:

Verificando o setup

Faça um commit que quebra uma regra de lint ou um teste de propósito. Veja o pipeline falhar, depois veja o Stitch pegar a falha. Você deve ver um novo branch e merge request em poucos minutos.

Se algo não funciona, confira os logs do job do Stitch. Eles contêm o diagnóstico completo e qualquer erro encontrado na tentativa de correção.

Próximos passos

Voltar ao blog