egutierrez
8aa1146b45
Antes forzaba --api "" (binding SQLite directo), lo que desactivaba el WebSocket del Monitor tab. Ademas no exportaba FN_REGISTRY_ROOT, por lo que la tab Work no encontraba el binario dev_console y caia a un placeholder. Ahora pasa --api http://127.0.0.1:8484 con registry.db como segundo argumento de fallback (el binario cae a SQLite directo si el servicio no responde) y exporta FN_REGISTRY_ROOT. El resultado es la app completa con un solo comando, con degradacion elegante cuando sqlite_api no esta arriba.
66 lines
3.0 KiB
Bash
Executable File
66 lines
3.0 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Lanza registry_dashboard en Linux en modo completo, conectando a sqlite_api
|
|
# (HTTP + WebSocket), stageando el ejecutable a ~/fn_apps/registry_dashboard/ para que todos los
|
|
# artefactos de runtime (imgui.ini, app_settings.ini, layouts.db, logs) queden
|
|
# contenidos en esa carpeta y no se mezclen con el arbol de build ni con el
|
|
# escritorio.
|
|
#
|
|
# Por que stagear: fn::run_app guarda local_files/ JUNTO al ejecutable
|
|
# (fn::exe_dir() resuelve /proc/self/exe, asi que un symlink no basta — apunta
|
|
# al binario real en cpp/build). Copiando el binario a su propia carpeta de
|
|
# despliegue, local_files/ se crea alli.
|
|
#
|
|
# Modo de datos: se pasa --api http://127.0.0.1:8484 (datos por HTTP mas el
|
|
# stream en vivo del Monitor tab por WebSocket) y, como segundo argumento, el
|
|
# path a registry.db. Si sqlite_api no responde, el binario cae automaticamente
|
|
# a ese SQLite local, asi que el lanzamiento funciona con o sin el servicio
|
|
# arriba: con servicio se obtiene el Monitor en tiempo real; sin el, datos
|
|
# estaticos del registry.db.
|
|
#
|
|
# Ademas se exporta FN_REGISTRY_ROOT para que la tab Work localice el binario
|
|
# dev_console (apps/dev_console/dev_console), que alimenta su panel de issues,
|
|
# flows y KPIs de DoD. Sin esa variable la tab Work cae a un placeholder.
|
|
set -euo pipefail
|
|
|
|
# Raiz del repo: este script vive en projects/fn_monitoring/apps/registry_dashboard/,
|
|
# cuatro niveles por debajo de la raiz de fn_registry.
|
|
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
ROOT="$(cd "$SCRIPT_DIR/../../../.." && pwd)"
|
|
|
|
BIN_SRC="$ROOT/cpp/build/apps/registry_dashboard/registry_dashboard"
|
|
ASSETS_SRC="$ROOT/cpp/build/apps/registry_dashboard/assets"
|
|
DB="$ROOT/registry.db"
|
|
APP_HOME="$HOME/fn_apps/registry_dashboard"
|
|
|
|
if [ ! -x "$BIN_SRC" ]; then
|
|
echo "Binario no encontrado: $BIN_SRC" >&2
|
|
echo "Compila primero:" >&2
|
|
echo " cmake -S $ROOT/cpp -B $ROOT/cpp/build -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF" >&2
|
|
echo " cmake --build $ROOT/cpp/build --target registry_dashboard -j\$(nproc)" >&2
|
|
exit 1
|
|
fi
|
|
|
|
if [ ! -f "$DB" ]; then
|
|
echo "registry.db no encontrado: $DB" >&2
|
|
echo "Regenera el indice: (cd $ROOT && ./fn index)" >&2
|
|
exit 1
|
|
fi
|
|
|
|
# Stage del ejecutable + assets a su carpeta de despliegue. -u copia solo si la
|
|
# fuente es mas nueva, asi que tras un rebuild se actualiza automaticamente.
|
|
# local_files/ NO se toca: persiste config y layouts entre lanzamientos.
|
|
mkdir -p "$APP_HOME"
|
|
cp -u "$BIN_SRC" "$APP_HOME/registry_dashboard"
|
|
if [ -d "$ASSETS_SRC" ]; then
|
|
mkdir -p "$APP_HOME/assets"
|
|
cp -ru "$ASSETS_SRC/." "$APP_HOME/assets/"
|
|
fi
|
|
|
|
# Lanzar desde APP_HOME → fn::exe_dir() apunta aqui → local_files/ vive aqui.
|
|
# --api http://127.0.0.1:8484 activa HTTP + WebSocket (Monitor en vivo); el path
|
|
# a registry.db queda como fallback si sqlite_api no responde. FN_REGISTRY_ROOT
|
|
# permite que la tab Work localice el binario dev_console.
|
|
export FN_REGISTRY_ROOT="$ROOT"
|
|
cd "$APP_HOME"
|
|
exec "$APP_HOME/registry_dashboard" --api "http://127.0.0.1:8484" "$DB"
|