Anwendungen: CLI-Befehle

Packen Sie ein statisches Verzeichnis in ein deterministisches Archiv, ohne es hochzuladen.

app pack <directory> [--output FILE]

screenrig app pack ./lobby-board --output ./lobby-board.tgz

Der Umschlag meldet sha256, compressed_bytes, expanded_bytes, file_count, die Eintragsliste und ob die SDK-Laufzeit injiziert wurde. app upload packt das Verzeichnis selbst, greifen Sie also nur zu diesem Befehl, wenn Sie das Archiv zuerst inspizieren wollen. Er läuft lokal und benötigt keine Anmeldung.

Ein Paket enthält höchstens 5000 Dateien, 250 MiB entpackt und 100 MiB komprimiert, jede Datei höchstens 32 MiB, mit Pfaden von höchstens 16 Ebenen und 255 Bytes. Das Packen lässt Namen aus, die mit . beginnen, node_modules/, bower_components/, jspm_packages/, vendor/, venv/, __pycache__/, CVS/, Source Maps *.map, Schlüssel- und Zugangsdatendateien (*.pem, *.key, *.p12, *.pfx, *.crt, *.cer, id_rsa, id_dsa, id_ecdsa, id_ed25519, credentials.json, secrets.json), Swap- und Backup-Dateien von Editoren, Thumbs.db und desktop.ini. Eine Datei .screenrigignore im Stammverzeichnis ergänzt Muster im gitignore-Stil, eines pro Zeile, und kann eine eingebaute Ausnahme nicht aufheben. Symlinks, Hardlinks, Sparse-Dateien, Geräte, doppelte Pfade (auch ohne Beachtung der Groß-/Kleinschreibung verglichen), Dateien, die sich während des Packens ändern, und ein Verzeichnis ohne index.html im Stamm werden unter Nennung des Pfads abgelehnt: Der Befehl beendet sich mit Code 2 und sendet nichts.

Anwendungen laufen unter einer Content-Security-Policy, die Inline-Code blockiert. Packing verschiebt Inline-Style- und Script-Blöcke in _screenrig-inline-*-Dateien neben jedem HTML-Dokument und verlinkt sie. Inline-Event-Handler wie onclick= und javascript: URLs können nicht verschoben werden; Packing lehnt sie ab und nennt Datei und Zeile.

Schreiben Sie die TypeScript-Typen für window.screenrig in ein Verzeichnis.

app types [directory]

screenrig app types ./src

Der Umschlag meldet path, bytes, sha256 und written, das false ist, wenn die Datei bereits die aktuellen Typen enthielt. Die Datei passt zur Laufzeit, die app pack und app upload injizieren; führen Sie den Befehl daher nach einem Update der CLI erneut aus. Eine vorhandene screenrig.d.ts wird vollständig ersetzt; ein Verzeichnis oder ein Symlink an diesem Pfad wird abgelehnt, und der Befehl endet mit 2. Er läuft lokal und benötigt keine Anmeldung. TypeScript beschreibt, was die Typen deklarieren.

Stellen Sie ein Verzeichnis in einem lokalen Player-Harness bereit, um eine Anwendung vor dem Hochladen auszuprobieren.

app dev <directory> [--port PORT] [--open] [--no-reload] [--kv FILE | --kv-from APP_ID]

screenrig app dev ./lobby-board --open

Der Befehl stellt den Harness unter http://play.screenrig.localhost:18890 bereit und läuft, bis Sie ihn beenden. Er injiziert die Laufzeit wie app pack und meldet beim Bearbeiten, was das Packen ablehnt, mit Nennung von Datei und Zeile. Der Harness simuliert die Fähigkeiten, den Viewport, den Namen, die Zeitzone und die Parameter des Bildschirms, den Seitentimer, Pause, Anzeige und Verlassen, Geräteereignisse sowie serielle Ports, GPIO-Leitungen, Peripheriegeräte für Bluetooth LE und Drucker. Zeilen von emit und log werden im Terminal ausgegeben. Lokal entwickeln beschreibt die Steuerelemente.

Packen Sie ein Verzeichnis, veröffentlichen Sie es als neue Anwendungsfreigabe und warten Sie, bis die Veröffentlichung erfolgreich ist.

app upload <directory> [--name NAME] [--no-wait] [--poll-ms MS] [--timeout MS]

screenrig app upload ./lobby-board --name "Lobby board"

Lese drei Felder: data.operation.state ist succeeded, data.application.release_id ist die rel_ ID, ein application Primitive pinnt, und data.application.id ist die app_ ID, die kv Befehle verwenden. Ein erfolgreicher Vorgang, nicht eine Release-ID allein, bedeutet, dass die Veröffentlichung nutzbar ist.

Jede app upload erstellt eine neue Anwendung und eine erste unveränderliche Version. Um eine spätere Version derselben App zu veröffentlichen, verwenden Sie app update. Eine Playlist bedient weiterhin die Version, die sie bereits festhält, bis Sie dieses Primitive bearbeiten.

Eine unterbrochene Übertragung zum Speicher wird bis zu 4-mal versucht, solange ihre Upload-URL gültig ist. Schlägt sie weiterhin fehl, führen Sie denselben Befehl erneut aus, um denselben Upload fortzusetzen.

Eine neue Version einer bestehenden Anwendung veröffentlichen und dabei Identität, Namen und Anwendungsschlüssel/Wert erhalten.

app update <id> <directory> [--expect-rev REVISION] [--no-wait] [--poll-ms MS] [--timeout MS]

screenrig app update app_01EXAMPLEAPP00000000000 ./lobby-board

Der Name bleibt erhalten; ändern Sie ihn mit app rename. Warten Sie auf data.operation.state: "succeeded" und verwenden Sie dann playlist replace-release, um die genaue Seite, das Primitive, die neue Version und die betroffenen Bildschirme zu überprüfen. Wenden Sie dies mit dem zurückgegebenen Impact-Token und einer optionalen Revisionssperre wie im Playlist-Workflow beschrieben an. Bestehende Playlist-Pins bleiben bis zur Anwendung unverändert. Bei einem Revisionskonflikt lesen Sie die App erneut, bevor Sie entscheiden, ob Sie es erneut versuchen; erstellen Sie keine Ersatzanwendung, nur um den Konflikt zu umgehen.

Anwendungen des Projekts auflisten.

app list

Keine Parameter.

screenrig app list

Den Anzeigenamen einer Anwendung ändern.

app rename <id> --name NAME [--expect-rev REVISION]

screenrig app rename app_01EXAMPLEAPP00000000000 --name "Lobby welcome"

Nur der Anzeigename ändert sich. Die Anwendungs-ID, ihre Versionen, ihre Schlüssel-Wert-Daten und die Playlists, die ihre Versionen anheften, bleiben unverändert, und es wird kein Verzeichnis hochgeladen. Eine Umbenennung auf den aktuellen Namen lässt die Revision unverändert. Namen dürfen sich wiederholen; sprechen Sie eine Anwendung über ihre ID an.

Eine Anwendung lesen.

app show <id>

screenrig app show app_01EXAMPLEAPP00000000000

latest_ready_release fehlt, bis eine erste Veröffentlichung bereit ist. Der Veröffentlichungsstatus lebt auf der Operation und der Version, nicht auf der Anwendung. last_used_at fehlt, bis ein Bildschirm die Anwendung zum ersten Mal abspielt.

Eine Anwendung und alle ihre Releases löschen.

app delete <id> [--expect-rev REVISION]

screenrig app delete app_01EXAMPLEAPP00000000000

Es gibt kein Löschverfahren pro Release. Solange ein Bildschirm eine der Releases der Anwendung zeigt, antwortet das Löschen mit application_in_use: Geben Sie diesen Bildschirmen zuerst andere Inhalte. Das Löschen prüft keine Playlists, die eine Release anheften, ohne sie anzuzeigen, aktualisieren oder löschen Sie daher auch diese Playlists.

Für eine Anwendung gespeicherte Schlüssel auflisten.

kv list --app-id ID

screenrig kv list --app-id app_01EXAMPLEAPP00000000000

Einen Schlüssel lesen.

kv get --app-id ID <key>

screenrig kv get --app-id app_01EXAMPLEAPP00000000000 menu

Die Antwort enthält den Wert in data.value_base64, auch JSON-Werte: Dekodieren Sie ihn und parsen Sie JSON nur, wenn data.content_type JSON angibt. kv list lässt Werte weg.

Schreiben Sie einen Schlüssel aus JSON, einer Datei oder Base64-Bytes.

kv set --app-id ID <key> --json-value JSON [--expect-rev REVISION]
kv set --app-id ID <key> --file FILE [--content-type TYPE] [--expect-rev REVISION]
kv set --app-id ID <key> --value-base64 BASE64 [--content-type TYPE] [--expect-rev REVISION]

screenrig kv set --app-id app_01EXAMPLEAPP00000000000 menu --json-value '{"soup":"lentil"}'

Einen Schlüssel löschen.

kv delete --app-id ID <key> [--expect-rev REVISION]

screenrig kv delete --app-id app_01EXAMPLEAPP00000000000 menu

Einen Webhook erstellen, der einen Schlüssel einer Anwendung oder mit --card das Datendokument einer Karte schreibt, und seine URL und sein Secret einmalig erhalten.

kv webhook create <key> --app-id ID [--description TEXT]
kv webhook create --card CARD_ID [--description TEXT] [--map FILE|-] [--key-template TEMPLATE] [--signing]
                  [--verify VENDOR [--verify-secret-file FILE|-] [--verify-header NAME] [--verify-encoding hex|base64]
                   [--verify-timestamp-header NAME] [--verify-tolerance SECONDS]] [--handshake VENDOR]

screenrig kv webhook create menu --app-id app_01EXAMPLEAPP00000000000 --description "Point of sale menu feed"
screenrig kv webhook create --card crd_01EXAMPLEBOARD0000000000 --map alert-map.json --description "CMS alerts"

--map, --key-template, --signing, --verify mit seinen Optionen und --handshake gelten nur für einen Karten-Webhook.

Der Umschlag ist der Webhook: data.id (kvw_…), data.key oder, bei einer Karte, data.card_id, data.url (https://api.screenrig.ai/api/applications/<app_id>/kv-webhooks/<id>/write oder https://api.screenrig.ai/api/cards/<card_id>/kv-webhooks/<id>/write) und data.secret (srkw_…). Ein signierender Karten-Webhook enthält außerdem data.signing_secret (whsec_…). Tragen Sie die URL und die Secrets jetzt im sendenden System ein. Kein späterer Befehl zeigt sie erneut an. Nach einer unterbrochenen oder mehrdeutigen Erstellung führen Sie denselben Befehl innerhalb von 24 Stunden erneut aus: Er verwendet den gespeicherten Idempotenzschlüssel, und der Server liefert denselben Webhook und dieselben Secrets zurück, statt einen neuen zu erstellen.

Die Webhooks einer Anwendung oder einer Karte auflisten, die ältesten zuerst.

kv webhook list (--app-id ID | --card CARD_ID)

screenrig kv webhook list --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook list --card crd_01EXAMPLEBOARD0000000000

Jedes Element hat id, key, description, url, created_at und, sobald es geschrieben wurde, last_used_at. Das Element eines Karten-Webhooks hat card_id anstelle von key, dazu mapping (null, wenn das gesendete Objekt das Dokument ist), enabled, signing und, falls gesetzt, key_template, verify und handshake. Eine Liste enthält niemals ein Secret.

Einen Webhook löschen. Seine URL funktioniert sofort nicht mehr; der Schlüssel oder das Dokument der Karte behält seinen Wert.

kv webhook delete <webhook_id> (--app-id ID | --card CARD_ID)

screenrig kv webhook delete kvw_01EXAMPLEWEBHOOK00000 --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook delete kvw_01EXAMPLEWEBHOOK00000 --card crd_01EXAMPLEBOARD0000000000

Geheimnis eines Webhooks ersetzen und das neue einmal erhalten.

kv webhook rotate-secret <webhook_id> (--app-id ID | --card CARD_ID) [--signing]

screenrig kv webhook rotate-secret kvw_01EXAMPLEWEBHOOK00000 --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook rotate-secret kvw_01EXAMPLEWEBHOOK00000 --card crd_01EXAMPLEBOARD0000000000 --signing

Der Umschlag enthält das neue Secret in data.secret. Das alte Secret funktioniert sofort nicht mehr, tragen Sie das neue also im sendenden System ein. Mit --signing enthält der Umschlag stattdessen das neue Signatur-Secret in data.signing_secret, und das srkw_-Secret des Webhooks bleibt bestehen. Nach einer unterbrochenen oder mehrdeutigen Rotation führen Sie denselben Befehl erneut aus: Er verwendet den gespeicherten Idempotenzschlüssel, und der Server liefert die bereits erfolgte Rotation zurück, statt erneut zu rotieren.