Referencia de scripts

Información adicional en resumen - Para referencia cuando sea necesario sobre los scripts de desarrollo para repositorios de aplicaciones construidos sobre Pankosmia

Tabla de contenidos

Configuración del ecosistema
Instalación de los clientes
Scripts
- Configuración
Notas al pie

Configuración del ecosistema

Este repositorio reúne varias bibliotecas y proyectos en una sola aplicación. Los proyectos están distribuidos en varios repositorios para permitir la reutilización modular. A continuación se proporcionan scripts para ayudar en la configuración, aunque todo también puede configurarse manualmente. Lo siguiente asume que los repositorios están instalados con la siguiente estructura de directorios.

Esto es un ejemplo. Los clientes en uso pueden variar. La configuración se gestiona mediante app_config.env y el script app_setup.

|-- repos
    |-- pankosmia
        |-- core-client-content repository
        |-- core-client-dashboard repository
        |-- core-client-i18n-editor repository
        |-- core-client-remote-repos repository
        |-- core-client-settings repository
        |-- core-client-workspace repository
        |-- [your-desktop-app-repo-name] (30 characters or less on windows!)
        |-- resource-core
        |-- webfonts-core

Instalación de los clientes

El local_server (pankosmia_web) sirve los archivos compilados desde el directorio build de cada cliente, por lo que cada cliente debe ser compilado.

Esto se gestiona mediante los scripts clone y build_clients, aunque todo también puede ejecutarse manualmente, lo cual es útil durante el desarrollo.

# ¡En cada repositorio de cliente, NO en este repositorio!
npm ci
npm run build

Ejecutar run, build_server o bundle_... copia la última compilación al entorno de build.

Scripts

Los scripts se encuentran en <os>/scripts/ y deben ejecutarse desde ese directorio (por ejemplo, cd linux/scripts/, cd windows\scripts\, cd macos/scripts/). Los scripts fallarán si se ejecutan desde otra ubicación. Extensiones de archivo por SO: Linux → .bsh, macOS → .zsh, Windows → .bat (salvo indicación contraria). Las rutas usan / en Linux/macOS y \ en Windows. ^[1]

Configuración

Los archivos de configuración deben coincidir con los clientes y assets utilizados. Se proporcionan scripts para generarlos, según app_config.env. Los archivos creados por el script app_setup son:

buildSpec.json
/globalBuildResources/i18nPatch.json
/globalBuildResources/product.json
/<os>/buildResources/setup/app_setup.json

Revise app_config.env y ajuste según sea necesario, luego ejecute uno de los scripts de configuración que siguen. Vuelva a ejecutar el script app_setup cada vez que se modifique app_config.env.

Scripts de configuración:

Ejecute desde la ubicación proporcionada:

Descripción	Script y argumentos cd `<os>/scripts/` Linux: `.bsh` `\|` macOS: `.zsh` `\|` Win: `.bat`
Usa app_config.env para generar/reconstruir/reemplazar app_setup.json, buildSpec.json, product.json e i18nPatch.json	`app_setup`

Scripts de configuración:

Ejecute desde la ubicación proporcionada:

Descripción	Script y argumentos cd `<os>/scripts/` Linux: `.bsh` `\|` macOS: `.zsh` `\|` Win: `.bat`
Clona todos los repositorios en /app_config.env si un directorio con ese nombre no existe ya	`clone` Clona por defecto vía HTTPS. Argumento opcional: `clone -s` Clona vía SSH.
Para cada repositorio de assets en `/app_config.env`: git checkout main, git pull Para cada repositorio de cliente en `/app_config.env`: `git checkout main`, `git pull`, `npm ci` y `npm run build`. *Los desarrolladores deben compilar manualmente al probar ramas.*	`build_clients` Argumentos opcionales: `build_clients [branch\|dev\|qa] [dev\|qa]` Donde “my-branch” no exista, el respaldo será “main” a menos que se especifique el siguiente argumento. Si se indica “dev”, se implica un respaldo “dev” → “qa” → “main”. Si se indica “qa”, se implica un respaldo “qa” → “main”. `build_clients -d` Elimina los logs anteriores sin preguntar. `build_clients -f` Omitir pull porque todos los repositorios son clones recientes.
Crear un visor Electronite para usar con el entorno de build de desarrollo local.	`build_viewer` Windows: usa `.ps1` (use una terminal PowerShell)

Scripts de uso:

Nota: Se pueden aplicar múltiples argumentos en cualquier orden, por ejemplo, build_server -s dev debug es lo mismo que build_server debug dev -s

Descripción	Script y argumentos cd `<os>/scripts/` Linux: `.bsh` `\|` macOS: `.zsh` `\|` Win: `.bat`
Elimina el directorio de build y ejecuta `cargo clean` ^[4]	`clean` Argumento opcional: `clean -s` No preguntará si el servidor está apagado
Ejecuta cargo build y `node build.js`	`build_server` Argumentos opcionales: `build_server dev` Usa la versión “dev” en `/local_server.env` `build_server qa` Usa la versión “qa” en `/local_server.env` `build_server -s` No preguntará si el servidor está apagado `build_server [ critical \| normal (predeterminado) \| debug \| off ]` Reescribe el nivel de log en `Rocket.toml`
Ensambla el entorno de build (clientes) e inicia el servidor ^[2]	`run` Argumento opcional: `run -s` No preguntará si el servidor está apagado
Lanza el visor Electronite para usar con el entorno de desarrollo. (Requiere que el visor haya sido previamente creado mediante el script `build_viewer`.)	`viewer` Herramientas de desarrollo: Ctrl + Shift + I (macOS: Cmd + Option + I) Argumento opcional: `viewer [PORT#]` (por defecto 19119)
Elimina los últimos bundles y el contenido temporal del sistema operativo dado (si existen), luego en este repositorio ejecuta `git checkout main`, `git pull` y `npm ci`, ejecuta `app_setup` para asegurar la consistencia de versiones, ejecuta `node build.js`, y luego crea un bundle de release zip y un instalador independiente. *() (•)**	`bundle_viewer` Linux: Sin argumentos opcionales. Solo compila y empaqueta el visor. Haga todo lo demás manualmente o mediante otros scripts listados aquí. Windows: Usa `.ps1`. Argumento opcional: `bundle_viewer.ps1 -ServerOff "Y"` No preguntará si el servidor está apagado macOS: Argumento opcional: `bundle_viewer -s` No preguntará si el servidor está apagado
Elimina el último bundle de release si existe, luego en este repositorio ejecuta `git checkout main`, `git pull` y `npm ci`, ejecuta `app_setup` para asegurar la consistencia de versiones, ejecuta `node build.js`, y luego crea un bundle de release zip/tgz ^[2]	Linux: `bundle_tgz` Windows: `bundle_zip.ps1` macOS: `bundle_zip` Argumentos opcionales: Linux/macOS: `bundle_tgz -s` / `bundle_zip -s` No preguntará si el servidor está apagado `bundle_tgz -g` / `bundle_zip -g` Ejecutar desde GitHub Actions Windows: `bundle_zip.ps1 -ServerOff "Y"` o: “y”; No preguntará si el servidor está apagado `bundle_zip.ps1 -IsGHA "Y"` o: “y”; Ejecutar desde GitHub Actions

Scripts de mantenimiento:

Ejecute desde la ubicación proporcionada:

Descripción	Script y argumentos cd `<os>/scripts/` Linux: `.bsh` `\|` macOS: `.zsh` `\|` Win: `.bat`
Facilita la sincronización con el upstream excluyendo los archivos que se espera que difieran:	`sync` Argumento opcional: `sync -p` No preguntará si la última versión ya fue obtenida.

Notas al pie

[1] … Al ejecutar un script bat desde un símbolo del sistema, el .\ incluido en los ejemplos es opcional.

[2] … ¡Asegúrese de que el servidor local esté actualizado! Esto es el script build_server, o build_server dev o build_server qa si /local_server.env tiene versiones diferentes de panksomia_web en /local_server/Cargo.toml.

[3] … Requisito previo del entorno para ejecutar el build exe localmente: Instale Inno Setup - probado con v6.4.3

[4] … Consejos de limpieza específica:

Para limpiar solo el servidor local: vaya al directorio /local_server y ejecute cargo clean
Para limpiar solo el entorno de build, vaya al subdirectorio de su SO (es decir, /macos, /linux o /windows), luego elimine recursivamente su subdirectorio build.
(El script clean hace todo lo anterior.)