Comprobar en la CI

eidos check da la misma revisión en un portátil, desde un agente y en un pipeline. Ejecútalo en cada merge request y lo que está mal se mire como se mire nunca llega a la rama por defecto: un enlace roto, un id ausente o duplicado (dos ramas pueden sacar el mismo), una variant que la colección no declara, un frontmatter que no se puede analizar.

Qué falla y qué solo se muestra

Un error hace fallar el job. Está mal, quisiera lo que quisiera quien lo escribió.
Un aviso nunca lo hace fallar, salvo que la raíz sea estricta. Una sección ausente o desordenada, una propiedad que falta: apartarse de un template suele ser deliberado, así que un build en rojo por eso es ruido. El aviso aparece en el merge request sobre el archivo que nombra, como anotación de GitHub o en el informe de Code Quality de GitLab, para que quien revisa lo valore.
Decide la raíz, no el pipeline. Una raíz cuyos responsables hicieron que los avisos fallen (eidos setup --strict on, guardado en .eidos/plugins/eidosmd/settings.yaml) falla por ellos en la CI igual que en un portátil. El job no añade ninguna política propia.

Un solo comando

eidos ci --write github    # .github/workflows/eidos-check.yml
eidos ci --write gitlab    # un job eidos-check en .gitlab-ci.yml
eidos ci                   # imprime los dos y no escribe nada

El archivo se escribe en la raíz del repositorio Git, y el job ejecuta la comprobación con --root apuntando a la carpeta de la raíz desde ahí, así que una raíz en una subcarpeta (docs/Blueprints) funciona tal cual. El job instala la CLI con npx, fijada a la versión que lo escribió; después de actualizar la CLI, vuelve a ejecutar el comando para mover esa versión.

Una segunda ejecución actualiza lo que escribió la primera en lugar de añadir otro. En .gitlab-ci.yml el job va entre # eidos:ci:start y # eidos:ci:end, y el resto del archivo se queda como estaba. Un workflow en esa ruta que eidos ci no escribió, o un job eidos-check tuyo fuera de las marcas, se deja en paz y el comando lo dice.

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 un comando de workflow por hallazgo (::error file=Blueprints/specs/login.md,line=12::link-broken: …), que GitHub dibuja como anotación sobre los archivos del pull request y lista en el resumen de la ejecución.

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 un informe de Code Quality: un error es major y un aviso minor, cada uno con su archivo, su línea y una huella que no cambia de una ejecución a otra, así que el merge request muestra lo que introdujo y lo que resolvió. Los hallazgos también van al log del job. when: always conserva el informe cuando un error hace fallar el job.

Los formatos por sí solos

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

Los dos mantienen el código de salida de eidos check: 0 sin errores, 1 con alguno (o con un aviso en una raíz estricta), 2 cuando la comprobación no pudo ejecutarse. Las rutas son relativas a la raíz del repositorio Git, o al directorio de trabajo fuera de un repositorio. Un hallazgo que conoce su línea (un enlace roto, un encabezado) apunta a ella; cualquier otro apunta a la primera línea del archivo. --json no cambia y lleva la misma line cuando la hay.

eidos check → · eidos ci →