La CLI de Nibiru

Le binaire ./nibiru est un outil en ligne de commande compilé qui est inclus dans chaque projet Nibiru. Il génère des modules, des contrôleurs et des plugins, exécute les migrations, gère le cache et (avec le module CMS) crée et supprime des pages.

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

Tous les indicateurs

Drapeau	Ce qu’il fait
-m {nom}	Générer un nouveau module nommé {nom}. Ajouter -g pour connecter les accroches de journalisation Graylog.
-c {nom}	Générer un nouveau contrôleur {nom} ainsi que son modèle.
-p {nom} -m {module}	Générer un nouveau plugin {nom} à l’intérieur de {module}. Ajouter -g pour Graylog.
-cache-clear	Effacer application/view/templates_c/ et application/view/cache/.
-s	Initialiser les dossiers du framework et corriger les permissions. Exécuter une fois après l’installation.
-mi {env}	Exécuter les migrations depuis application/settings/config/database/ contre local, staging ou production.
-mi-reset {env}	Supprimer la table d’audit des migrations pour {env}. Destructif.
-mi-reset-file {fichier} {env}	Oublier qu’un seul fichier de migration a été exécuté pour {env}.
-ws {URL} -wp {PORT}	Se connecter à un WebSocket à {URL}:{PORT} (REPL interactif).
-new-cms-page {nom}	(Module CMS uniquement) Créer une nouvelle page CMS liée à un modèle existant.
-delete-cms-page {nom}	(Module CMS uniquement) Supprimer une page CMS.
-h	Afficher le texte d’aide.
-v / -version	Imprimer la version du binaire et la version du framework.

Commandes quotidiennes que vous utiliserez effectivement

# 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

Environnements

La plupart des commandes respectent APPLICATION_ENV :

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

L’argument {env} suivant -mi sélectionne la cible des migrations ; les deux doivent correspondre.

Sur quoi est basé le CLI

L’exécutable binaire est une compilation de C++ qui lie contre les bibliothèques clientes MySQL, PostgreSQL (libpq) et ODBC. La compilation conditionnelle signifie qu’un binaire construit sans libpq fonctionne toujours pour des déploiements exclusivement avec MySQL — une dégradation gracieuse plutôt qu’une dépendance dure.

Vous trouverez le binaire à la racine du projet à côté de index.php. Il est exécutable dès l’installation (chmod +x nibiru si nécessaire).

Intégration continue

Une étape simple d’Actions GitHub :

- 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 }}

Le CLI se termine avec un code différent de zéro si toute migration échoue, donc le CI détectera les erreurs SQL.