Applications : commandes CLI

Emballez un répertoire statique dans une archive déterministe sans la téléverser.

app pack <directory> [--output FILE]

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

L’enveloppe rapporte sha256, compressed_bytes, expanded_bytes, file_count, la liste des entrées, et si le runtime SDK a été injecté. app upload emballe le répertoire lui-même, donc utilisez cette commande seulement si vous voulez inspecter d’abord l’archive. Elle s’exécute localement et ne demande aucune connexion.

Un paquet contient au plus 5000 fichiers, 250 Mio décompressés et 100 Mio compressés, chaque fichier d’au plus 32 Mio, avec des chemins d’au plus 16 niveaux et 255 octets. L’empaquetage écarte les noms qui commencent par ., node_modules/, bower_components/, jspm_packages/, vendor/, venv/, __pycache__/, CVS/, les cartes sources *.map, les fichiers de clés et d’identifiants (*.pem, *.key, *.p12, *.pfx, *.crt, *.cer, id_rsa, id_dsa, id_ecdsa, id_ed25519, credentials.json, secrets.json), les fichiers temporaires et de sauvegarde d’éditeur, Thumbs.db et desktop.ini. Un fichier .screenrigignore à la racine du répertoire ajoute des motifs de style gitignore, un par ligne, et ne peut pas rétablir une exclusion intégrée. Les liens symboliques, les liens physiques, les fichiers creux, les périphériques, les chemins en double (comparés aussi sans tenir compte de la casse), les fichiers qui changent pendant l’empaquetage et un répertoire sans index.html à la racine sont refusés avec le chemin indiqué : la commande se termine avec le code 2 et n’envoie rien.

Les applications s’exécutent sous une politique de sécurité de contenu qui bloque le code en ligne. L’empaquetage déplace les blocs de style et script en ligne dans des fichiers _screenrig-inline-* placés à côté de chaque document HTML et les lie. Les gestionnaires d’événements en ligne tels que onclick= et javascript: URLs ne peuvent pas être déplacés ; l’empaquetage les refuse et nomme le fichier et la ligne.

Écrivez les types TypeScript de window.screenrig dans un répertoire.

app types [directory]

screenrig app types ./src

L’enveloppe rapporte path, bytes, sha256 et written, qui vaut false lorsque le fichier contenait déjà les types actuels. Le fichier correspond au runtime qu’injectent app pack et app upload; relancez donc la commande après avoir mis à jour la CLI. Un screenrig.d.ts existant est remplacé en entier; un répertoire ou un lien symbolique à cet emplacement est refusé, et la commande se termine avec le code 2. Elle s’exécute localement et ne demande aucune connexion. TypeScript couvre ce que déclarent les types.

Servez un répertoire dans un banc d’essai Player local pour essayer une application avant de la téléverser.

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

screenrig app dev ./lobby-board --open

La commande sert le banc d’essai à http://play.screenrig.localhost:18890 et s’exécute jusqu’à ce que vous l’arrêtiez. Elle injecte le runtime comme le fait app pack, et signale ce que l’empaquetage refuse, en nommant le fichier et la ligne, pendant que vous modifiez. Le banc d’essai simule les capacités, la fenêtre d’affichage, le nom, le fuseau horaire et les params de l’écran, le minuteur de page, la pause, l’affichage et la sortie, les événements de l’appareil, ainsi que des ports série, lignes GPIO, périphériques Bluetooth LE et imprimantes. Les lignes emit et log s’affichent dans le terminal. Développer en local décrit les contrôles.

Emballez un répertoire, publiez-le comme nouvelle version d’application, et attendez que la publication réussisse.

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

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

Lire trois champs : data.operation.state est succeeded, data.application.release_id est l’ID rel_ un application primitif pins, et data.application.id est l’ID app_ que les commandes kv utilisent. Une opération réussie, pas un ID de version seul, signifie que la version est utilisable.

Chaque app upload crée une nouvelle application et une première version immuable. Pour publier une version ultérieure de la même application, utilisez app update. Une playlist continue de servir la version qu’elle épingle déjà jusqu’à ce que vous modifiiez ce primitif.

Un transfert vers le stockage interrompu est tenté jusqu’à 4 fois tant que son URL de téléversement est valide. S’il échoue encore, relancez la même commande pour reprendre le même téléversement.

Publier une nouvelle version d’une application existante, en conservant l’identité, le nom et les K/V de l’application.

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

screenrig app update app_01EXAMPLEAPP00000000000 ./lobby-board

Le nom reste tel quel ; changez-le avec app rename. Attendre data.operation.state: "succeeded", puis utiliser playlist replace-release pour examiner la page exacte, le primitif, la nouvelle version et les écrans affectés. Appliquer avec le jeton d’impact retourné et une garde de révision optionnelle comme décrit dans le flux de travail de la liste de lecture. Les épingles existantes de la liste de lecture restent inchangées jusqu’à l’application. En cas de conflit de révision, relire l’application avant de décider de réessayer ; ne pas créer une application de remplacement juste pour contourner le conflit.

Lister les applications du projet.

app list

Aucun paramètre.

screenrig app list

Changer le nom d’affichage d’une application.

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

screenrig app rename app_01EXAMPLEAPP00000000000 --name "Lobby welcome"

Seul le nom d’affichage change. L’identifiant de l’application, ses versions, ses données clé/valeur et les listes de lecture qui épinglent ses versions restent tels quels, et aucun répertoire n’est téléversé. Renommer vers le nom actuel laisse la révision inchangée. Les noms peuvent se répéter ; adressez une application par son identifiant.

Lire une application.

app show <id>

screenrig app show app_01EXAMPLEAPP00000000000

latest_ready_release est absent jusqu’à ce qu’une première publication soit prête. L’état de publication vit sur l’opération et la version, pas sur l’application. last_used_at est absent jusqu’à ce qu’un écran joue l’application pour la première fois.

Supprimer une application et chacune de ses versions.

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

screenrig app delete app_01EXAMPLEAPP00000000000

Il n’y a pas de suppression par version. Tant qu’un écran affiche une des versions de l’application, la suppression répond application_in_use : donnez d’abord un autre contenu à ces écrans. La suppression ne vérifie pas les playlists qui épinglent une version sans l’afficher, donc mettez à jour ou supprimez aussi ces playlists.

Lister les clés stockées pour une application.

kv list --app-id ID

screenrig kv list --app-id app_01EXAMPLEAPP00000000000

Lire une clé.

kv get --app-id ID <key>

screenrig kv get --app-id app_01EXAMPLEAPP00000000000 menu

La réponse contient la valeur dans data.value_base64, y compris les valeurs JSON : décodez-la, et analysez le JSON seulement quand data.content_type indique du JSON. kv list omet les valeurs.

Écrivez une clé depuis JSON, un fichier ou des octets base64.

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

Supprimer une clé.

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

screenrig kv delete --app-id app_01EXAMPLEAPP00000000000 menu

Créer un webhook qui écrit une clé d’une application, ou, avec --card, le document de données d’une carte, et recevoir son URL et son secret une seule fois.

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 avec ses options et --handshake s’appliquent uniquement à un webhook de carte.

L’enveloppe est le webhook : data.id (kvw_…), data.key ou, pour une carte, data.card_id, data.url (https://api.screenrig.ai/api/applications/<app_id>/kv-webhooks/<id>/write, ou https://api.screenrig.ai/api/cards/<card_id>/kv-webhooks/<id>/write) et data.secret (srkw_…). Un webhook de carte qui signe contient aussi data.signing_secret (whsec_…). Saisissez maintenant l’URL et les secrets dans le système expéditeur. Aucune commande ultérieure ne les affiche à nouveau. Après une création interrompue ou ambiguë, relancez la même commande dans les 24 heures : elle réutilise la clé d’idempotence enregistrée, et le serveur renvoie le même webhook et les mêmes secrets au lieu d’en créer un autre.

Lister les webhooks d’une application ou d’une carte, les plus anciens d’abord.

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

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

Chaque élément possède id, key, description, url, created_at et, une fois écrit, last_used_at. L’élément d’un webhook de carte a card_id à la place de key, plus mapping (null quand l’objet posté est le document), enabled, signing et, s’ils sont définis, key_template, verify et handshake. Une liste ne contient jamais de secret.

Supprimer un webhook. Son URL cesse de fonctionner immédiatement, et la clé ou le document de la carte conserve sa valeur.

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

Remplacer le secret d’un webhook et recevoir le nouveau une fois.

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

L’enveloppe contient le nouveau secret dans data.secret. L’ancien secret cesse de fonctionner immédiatement : saisissez donc le nouveau dans le système expéditeur. Avec --signing, l’enveloppe contient à la place le nouveau secret de signature dans data.signing_secret, et le secret srkw_ du webhook reste. Après une rotation interrompue ou ambiguë, relancez la même commande : elle réutilise la clé d’idempotence enregistrée, et le serveur renvoie la rotation déjà effectuée au lieu d’en refaire une.