# BDT CLI (`bdt`)

Shell de operaciones de la plataforma BDT: clona los repositorios desde el GitLab del banco, compila los servicios, construye sus imágenes Docker y los levanta con docker compose. Incluye menú interactivo y asistente guiado de construcción.

## Requisitos

- bash 3.2+ (macOS o Linux)
- git
- Docker + Docker Compose v2
- Java 21 (JDK) — para compilar gateway / service-bus
- Node.js 20 — para el frontend (solo si se compila fuera de Docker)

## Instalación

```bash
git clone https://git.dcgeeks.net/BDT/bdt-cli.git
cd bdt-cli
./bdt.sh setup        # instala el comando global 'bdt' + autocompletado + alias
```

O descarga directa del script:

```bash
curl -fsSL https://git.dcgeeks.net/BDT/bdt-cli/raw/branch/main/bdt.sh -o bdt.sh
chmod +x bdt.sh
./bdt.sh setup
```

> `setup` guarda la raíz del proyecto en `~/.bdt/project-root`. Ejecutalo desde el directorio donde van a vivir los repositorios de la plataforma (el script clona `backend/`, `frontend/`, `infrastructure/`, etc. relativo a esa raíz).

## Configuración

El script lee `~/.bdt/config` al arrancar (las variables de entorno tienen prioridad):

```bash
# GitLab del banco
GITLAB_URL=http://gitlab.bicentenariobu.com.ve
GITLAB_GROUP=dcgeeks

# Ambiente por defecto (desarrollo|calidad|demo|produccion)
DEFAULT_ENV=desarrollo

# Servidor de deploy remoto (comando server-deploy)
DEPLOY_SERVER=<ip-del-servidor>
DEPLOY_USER=<usuario-ssh>
```

Credenciales git (para que `clone`/`pull` no pidan contraseña):

```bash
bdt git-auth <usuario-gitlab>
```

## Uso rápido

```bash
bdt                  # menú interactivo
bdt construir        # asistente: elegir servicio + rama → git → build → docker → up
bdt deploy           # pipeline completo: pull → compilar → imágenes → up → health
bdt status           # estado de servicios y contenedores
bdt health           # health check completo
bdt logs gateway -f  # seguir logs de un servicio
bdt help             # ayuda completa
bdt self-update      # en el server: git pull bdt-cli + reinstalar enlace
bdt deploy-jar gateway   # JAR en /tmp → docker build → up (server)
```

### Actualizar el shell en el server del banco

El script vive en su propio repo git (`bdt-cli`), separado del monorepo de aplicaciones:

```bash
# Primera vez (o migrar desde la copia suelta /opt/bdt-platform/bdt.sh):
bdt self-update

# Después de cada release publicado con `bdt publish`:
bdt self-update
```

`self-update` clona o hace `git pull` en `/opt/bdt-platform/bdt-cli` (configurable con
`BDT_CLI_DIR` en `~/.bdt/config`), reinstala `/usr/local/bin/bdt` y arregla permisos de logs.

Repos:
- Gitea: `https://git.dcgeeks.net/BDT/bdt-cli`
- GitLab banco (VPN): `http://gitlab.bicentenariobu.com.ve/dcgeeks/bdt-cli`

Publicar una versión nueva desde desarrollo:

```bash
# En el monorepo BDT, después de editar bdt.sh:
./bdt.sh publish    # commit + push a Gitea y GitLab del banco
```

### Asistente `construir` (opción `0` del menú)

Flujo guiado para construir y desplegar **un** servicio:

1. Pregunta qué servicio construir (frontend, gateway, service-bus, canales-admin-web, canales-worker) mostrando rama por defecto y estado del contenedor.
2. Pregunta la rama (Enter = rama por defecto del servicio).
3. Muestra el plan y pide confirmación.
4. Ejecuta: descarga de la rama desde el GitLab del banco → `gradle bootJar` (solo servicios Java) → `docker build` → `docker compose up -d --force-recreate` → health check.

Si hay cambios locales sin commitear, ofrece guardarlos en stash antes de cambiar de rama.

## Servicios gestionados

| Servicio | Stack | Rama default | Puerto |
|---|---|---|---|
| frontend | Next.js | develop | 59002 |
| gateway | Spring Boot | develop | 58050 |
| service-bus | Spring Boot | develop | 58060 |
| canales-admin-web | Next.js (pnpm) | master | 58180 |
| canales-worker | Node (pnpm) | master | 59091 |

Infraestructura (postgres, redis, redpanda, keycloak, mailpit, prometheus, grafana) se levanta con `bdt up infra`.

## Notas

- Los servicios Java se compilan con `gradle bootJar` **antes** del `docker build` (el Dockerfile copia `build/libs/*.jar`). Frontend y canales compilan dentro del Docker build (multi-stage).
- El nombre del remote que apunta al GitLab del banco puede variar por repositorio; el script lo detecta automáticamente por URL.
- Logs de compilación en `<raíz>/logs/`.