Die Nibiru CLI

Jedes Flag, jeder Unterbefehl des `./nibiru` Binaries.

Stable Reading time ~ 2 min Edit on GitHub

Die ./nibiru-Binärdatei ist ein kompiliertes Befehlszeilentool, das in jedem Nibiru-Projekt enthalten ist. Es erstellt Module, Controller und Plugins, führt Migrationen durch, verwaltet den Cache und (mit dem CMS-Modul) erstellt und löscht Seiten.

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

Alle Flags

Flag	Was es macht
`-m {name}`	Erstellt ein neues Modul mit dem Namen `{name}`. Fügen Sie `-g` hinzu, um Graylog-Protokollierungshooks zu verbinden.
`-c {name}`	Erstellt einen neuen Controller `{name}` zusammen mit seiner Vorlage.
`-p {name} -m {module}`	Erstellt ein neues Plugin `{name}` innerhalb von `{module}`. Fügen Sie `-g` für Graylog hinzu.
`-cache-clear`	Löscht `application/view/templates_c/` und `application/view/cache/`.
`-s`	Bootstrap-Framework-Ordner erstellen und Berechtigungen reparieren. Führen Sie einmal nach der Installation aus.
`-mi {env}`	Führt Migrationen aus `application/settings/config/database/` für `local`, `staging` oder `production` durch.
`-mi-reset {env}`	Löscht die Migrations-Audit-Tabelle für `{env}`. Zerstörend.
`-mi-reset-file {file} {env}`	Vergisst, dass eine einzelne Migrationsdatei für `{env}` ausgeführt wurde.
`-ws {URL} -wp {PORT}`	Verbindet sich mit einem WebSocket an `{URL}:{PORT}` (interaktive REPL).
`-new-cms-page {name}`	(Nur CMS-Modul) Erstellt eine neue CMS-Seite, die einer vorhandenen Vorlage gebunden ist.
`-delete-cms-page {name}`	(Nur CMS-Modul) Löscht eine CMS-Seite.
`-h`	Zeigt den Hilfetext an.
`-v` / `-version`	Gibt die Version des Binaries und der Framework-Version aus.

Tägliche Befehle, die Sie tatsächlich verwenden werden

# 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

Umgebungen

Die meisten Befehle beachten APPLICATION_ENV:

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

Der nachfolgende {env}-Argument für -mi wählt das Ziel der Migrationen aus; beide müssen übereinstimmen.

Auf was die Befehlszeilenschnittstelle (CLI) aufbaut

Die ausführbare Datei ist eine kompilierte C++-Anwendung, die gegen die MySQL-, PostgreSQL (libpq)- und ODBC-Clients-Bibliotheken verlinkt. Die konditionale Kompilierung bedeutet, dass eine mit libpq gebaute Binärdatei auch für MySQL-einzige Bereitstellungen funktioniert – ein sanfter Abstieg anstatt einer festen Abhängigkeit.

Sie finden die ausführbare Datei im Projektstamm neben index.php. Sie ist direkt ausführbar (chmod +x nibiru, falls erforderlich).

CI-Integration

Ein einfacher Schritt in 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 }}

Die CLI beendet sich mit einem Nicht-null-Ausgabestatus, wenn eine Migration fehlschlägt, sodass CI SQL-Fehler erfasst.