CI/CD

La integración continua de ixiclinic se reparte entre GitHub Actions (releases de los binarios nativos) y Vercel (despliegue continuo de las apps web).

GitHub Actions

Los workflows viven en .github/workflows/. Actualmente hay dos, ambos dedicados a publicar releases de los componentes nativos disparados por tags.

Release de ixiclinic Connect — connect-release.yml

• Disparador: push de un tag connect-v* (p. ej. connect-v0.1.0), o ejecución manual desde la pestaña Actions (workflow_dispatch).
• Qué hace: compila el agente ixiclinic Connect (carpeta bridge/) a un binario único con el cross-compiler de Bun, para Linux x64, Windows x64 y macOS (Apple Silicon e Intel), todo desde un solo runner Ubuntu.
• Salida: sube los binarios como artefactos y los adjunta al GitHub Release del tag.

# Disparar un release de Connect
git tag connect-v0.1.0
git push origin connect-v0.1.0

Release de ixiclinic Desktop — desktop-release.yml

• Disparador: push de un tag desktop-v* (p. ej. desktop-v0.1.0), o ejecución manual.
• Qué hace: construye la app de escritorio ixiclinic Desktop (Tauri) con una matriz para macOS (Apple Silicon + Intel) y Windows. Antes de empaquetar, descarga el binario de ixiclinic Connect correspondiente desde su release y lo incrusta como sidecar.
• Salida: publica los instaladores (.dmg / .msi / .exe) en el GitHub Release del tag.

# Disparar un release de Desktop
git tag desktop-v0.1.0
git push origin desktop-v0.1.0

Auto-deploy de Vercel

Las apps Next.js (admin, console, portal, landing, docs) no dependen de GitHub Actions: se despliegan en Vercel con auto-deploy en cada push a main. El merge a main basta para construir y publicar. Ver Despliegue.

Pipeline de calidad (CI)

El workflow .github/workflows/ci.yml corre en cada push y pull request contra main la batería de calidad del monorepo, con pnpm install --frozen-lockfile y luego:

pnpm typecheck
pnpm lint
pnpm --filter @ixiclinic/api test   # vitest (concentrado en el API)
pnpm build

Usa pnpm/action-setup (9.15.9) + actions/setup-node (Node 20, cache de pnpm) y cancela ejecuciones en curso de la misma rama. Es la puerta de calidad antes de mergear.

Nota: la cobertura de lint es parcial (las apps con script lint: admin, console, portal, landing). Ampliarla al resto es un siguiente paso — ver Known issues.

Esto daría una puerta de calidad antes del merge, especialmente útil porque el auto-deploy de Vercel publica directamente desde main. Ver Testing para el estado actual de las pruebas.