Verificando na CI

eidos check dá a mesma revisão num notebook, a partir de um agente e num pipeline. Rode-o em cada merge request e o que está errado em qualquer leitura nunca chega à branch padrão: um link quebrado, um id faltando ou duplicado (duas branches podem tirar o mesmo), uma variant que a coleção não declara, um frontmatter que não é analisável.

O que falha e o que só aparece

Um erro faz o job falhar. Está errado, seja qual for a intenção de quem escreveu.
Um aviso nunca o faz falhar, a menos que a raiz seja estrita. Uma seção faltando ou fora de ordem, uma propriedade ausente: sair de um template costuma ser deliberado, então um build vermelho por isso é ruído. O aviso aparece no merge request sobre o arquivo que nomeia, como anotação do GitHub ou no relatório de Code Quality do GitLab, para quem revisa avaliar.
Quem decide é a raiz, não o pipeline. Uma raiz cujos responsáveis fizeram os avisos falharem (eidos setup --strict on, salvo em .eidos/plugins/eidosmd/settings.yaml) falha por eles na CI como falha num notebook. O job não acrescenta nenhuma política própria.

Um só comando

eidos ci --write github    # .github/workflows/eidos-check.yml
eidos ci --write gitlab    # um job eidos-check em .gitlab-ci.yml
eidos ci                   # imprime os dois e não escreve nada

O arquivo é escrito no topo do repositório Git, e o job roda a verificação com --root apontando para a pasta da raiz a partir dali, então uma raiz numa subpasta (docs/Blueprints) funciona do jeito que está. O job instala a CLI com npx, fixada na versão que o escreveu; depois de atualizar a CLI, rode o comando de novo para mover essa versão.

Uma segunda execução atualiza o que a primeira escreveu em vez de acrescentar outro. No .gitlab-ci.yml o job fica entre # eidos:ci:start e # eidos:ci:end, e todas as outras linhas do arquivo ficam como estavam. Um workflow nesse caminho que o eidos ci não escreveu, ou um job eidos-check seu fora das marcas, é deixado como está e o comando avisa.

GitHub

name: Eidos check
on: pull_request
permissions:
  contents: read
jobs:
  eidos-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npx --yes eidosmd@latest check --root Blueprints --format github

--format github imprime um comando de workflow por achado (::error file=Blueprints/specs/login.md,line=12::link-broken: …), que o GitHub desenha como anotação nos arquivos do pull request e lista no resumo da execução.

GitLab

eidos-check:
  image: node:22
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - npx --yes eidosmd@latest check --root Blueprints --format codequality > gl-code-quality-report.json
  artifacts:
    when: always
    reports:
      codequality: gl-code-quality-report.json

--format codequality imprime um relatório de Code Quality: um erro é major e um aviso minor, cada um com seu arquivo, sua linha e uma impressão digital que não muda de uma execução para outra, então o merge request mostra o que introduziu e o que resolveu. Os achados também vão para o log do job. when: always guarda o relatório quando um erro faz o job falhar.

Os formatos sozinhos

eidos check --format github
eidos check --format codequality > gl-code-quality-report.json

Os dois mantêm o código de saída do eidos check: 0 sem erros, 1 com algum (ou com um aviso numa raiz estrita), 2 quando a verificação não pôde rodar. Os caminhos são relativos ao topo do repositório Git, ou ao diretório de trabalho fora de um repositório. Um achado que conhece a sua linha (um link quebrado, um título) aponta para ela; qualquer outro aponta para a primeira linha do arquivo. O --json não muda e traz a mesma line quando ela existe.

eidos check → · eidos ci →