La CLI de Nibiru

El binario ./nibiru es una herramienta de línea de comandos compilada que se incluye en cada proyecto Nibiru. Genera módulos, controladores y complementos, ejecuta migraciones, administra la caché, y (con el módulo CMS) crea y elimina páginas.

  _   _ _ _     _              ______                                          _
 | \ | (_) |   (_)            |  ____|                                        | |
 |  \| |_| |__  _ _ __ _   _  | |__ _ __ __ _ _ __ ___   _____      _____  _ _| | __
 | . ` | | '_ \| | '__| | | | |  __| '__/ _` | '_ ` _ \ / _ \ \ /\ / / _ \| '__| |/ /
 | |\  | | |_) | | |  | |_| | | |  | | | (_| | | | | | |  __/\ V  V / (_) | |  |   <
 |_| \_|_|_.__/|_|_|   \__,_| |_|  |_|  \__,_|_| |_| |_|\___| \_/\_/ \___/|_|  |_|\_\

Todos los indicadores

Flag	What it does
-m {name}	Generate a new module named {name}. Add -g to wire Graylog logging hooks.
-c {name}	Generate a new controller {name} plus its template.
-p {name} -m {module}	Generate a new plugin {name} inside {module}. Add -g for Graylog.
-cache-clear	Clear application/view/templates_c/ and application/view/cache/.
-s	Bootstrap framework folders and fix permissions. Run once after install.
-mi {env}	Run migrations from application/settings/config/database/ against local, staging or production.
-mi-reset {env}	Drop the migrations audit table for {env}. Destructive.
-mi-reset-file {file} {env}	Forget that a single migration file ran for {env}.
-ws {URL} -wp {PORT}	Connect to a WebSocket at {URL}:{PORT} (interactive REPL).
-new-cms-page {name}	(CMS module only) Create a new CMS page bound to an existing template.
-delete-cms-page {name}	(CMS module only) Delete a CMS page.
-h	Show the help text.
-v / -version	Print the binary’s version and the framework version.

Comandos diarios que realmente usarás

# create a controller + view
./nibiru -c products

# create a module with Graylog hooks
./nibiru -m billing -g

# create a plugin inside that module
./nibiru -p invoices -m billing

# run migrations
./nibiru -mi local

# clear the Smarty cache after a deploy
./nibiru -cache-clear

# show framework version
./nibiru -v

Entornos

La mayoría de los comandos respetan APPLICATION_ENV:

APPLICATION_ENV=production ./nibiru -mi production
APPLICATION_ENV=staging    ./nibiru -mi staging

El argumento {env} que sigue a -mi selecciona el destino de las migraciones; ambos deben coincidir.

¿Sobre lo que está construido el CLI?

El binario es un ejecutable compilado en C++ que se vincula contra las bibliotecas de cliente MySQL, PostgreSQL (libpq) y ODBC. La compilación condicional significa que un binario construido sin libpq aún funciona para implementaciones exclusivas de MySQL — una degradación grácil en lugar de una dependencia dura.

Lo encontrarás en la raíz del proyecto junto a index.php. Es ejecutable de inmediato (chmod +x nibiru si es necesario).

Integración continua

Un paso sencillo de GitHub Actions:

- name: Run migrations
  run: |
    APPLICATION_ENV=production ./nibiru -mi production
  env:
    DB_HOST: ${{ secrets.DB_HOST }}
    DB_USER: ${{ secrets.DB_USER }}
    DB_PASS: ${{ secrets.DB_PASS }}

El CLI sale con un código no cero si cualquier migración falla, por lo que el CI capturará los errores de SQL.