Aplicaciones: comandos CLI

Empaque un directorio estático en un archivo determinista sin subirlo.

app pack <directory> [--output FILE]

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

El sobre informa sha256, compressed_bytes, expanded_bytes, file_count, la lista de entradas y si se inyectó el tiempo de ejecución del SDK. app upload empaqueta el directorio mismo, así que use este comando solo cuando quiera inspeccionar primero el archivo. Se ejecuta localmente y no requiere iniciar sesión.

Un paquete contiene como máximo 5000 archivos, 250 MiB descomprimidos y 100 MiB comprimidos, cada archivo de hasta 32 MiB, con rutas de hasta 16 niveles y 255 bytes. El empaquetado omite los nombres que empiezan por ., node_modules/, bower_components/, jspm_packages/, vendor/, venv/, __pycache__/, CVS/, los mapas de código *.map, los archivos de claves y credenciales (*.pem, *.key, *.p12, *.pfx, *.crt, *.cer, id_rsa, id_dsa, id_ecdsa, id_ed25519, credentials.json, secrets.json), los archivos temporales y de copia de seguridad del editor, Thumbs.db y desktop.ini. Un archivo .screenrigignore en la raíz del directorio añade patrones al estilo gitignore, uno por línea, y no puede recuperar una exclusión integrada. Los enlaces simbólicos, los enlaces duros, los archivos dispersos, los dispositivos, las rutas duplicadas (comparadas también sin distinguir mayúsculas), los archivos que cambian durante el empaquetado y un directorio sin index.html en la raíz se rechazan indicando la ruta: el comando termina con el código 2 y no envía nada.

Las aplicaciones se ejecutan bajo una política de seguridad de contenido que bloquea código en línea. El empaquetado mueve bloques de estilo y script en línea a archivos _screenrig-inline-* junto a cada documento HTML y los enlaza. Los manejadores de eventos en línea como onclick= y URLs javascript: no pueden moverse; el empaquetado los rechaza y nombra el archivo y la línea.

Escriba los tipos de TypeScript de window.screenrig en un directorio.

app types [directory]

screenrig app types ./src

El sobre informa path, bytes, sha256 y written, que es false cuando el archivo ya contenía los tipos actuales. El archivo coincide con el tiempo de ejecución que inyectan app pack y app upload, así que vuelva a ejecutar el comando después de actualizar la CLI. Un screenrig.d.ts existente se reemplaza por completo; un directorio o un enlace simbólico en esa ruta se rechaza y el comando termina con el código 2. Se ejecuta localmente y no requiere iniciar sesión. TypeScript explica qué declaran los tipos.

Sirva un directorio en un entorno de pruebas local del Player para probar una aplicación antes de subirla.

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

screenrig app dev ./lobby-board --open

El comando sirve el entorno de pruebas en http://play.screenrig.localhost:18890 y se ejecuta hasta que lo detenga. Inyecta el runtime como lo hace app pack, e informa de lo que rechaza el empaquetado, indicando el archivo y la línea, mientras edita. El entorno de pruebas simula las capacidades, la ventana gráfica, el nombre de la pantalla, la zona horaria y los params, el temporizador de página, la pausa, la pantalla y la salida de la página, los eventos del dispositivo, y puertos serie, líneas GPIO, periféricos Bluetooth LE e impresoras. Las líneas emit y log se imprimen en la terminal. Desarrollar localmente explica los controles.

Empaque un directorio, publíquelo como una nueva versión de la aplicación y espere a que la publicación tenga éxito.

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

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

Leer tres campos: data.operation.state es succeeded, data.application.release_id es el id rel_ un application primitivo pins, y data.application.id es el id app_ que toman los comandos kv. Una operación exitosa, no un id de lanzamiento por sí solo, significa que el lanzamiento es utilizable.

Cada app upload crea una nueva aplicación y un primer lanzamiento inmutable. Para publicar un lanzamiento posterior de la misma app, use app update. Una lista de reproducción sigue sirviendo el lanzamiento que ya fija hasta que edite ese primitivo.

Una transferencia al almacenamiento que se interrumpe se intenta hasta 4 veces mientras su URL de subida sea válida. Si sigue fallando, ejecute de nuevo el mismo comando para reanudar la misma subida.

Publicar una nueva versión de una aplicación existente, preservando identidad, nombre y K/V de la aplicación.

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

screenrig app update app_01EXAMPLEAPP00000000000 ./lobby-board

El nombre se mantiene; cámbielo con app rename. Espere data.operation.state: "succeeded", luego use playlist replace-release para revisar la página exacta, el primitivo, la nueva versión y las pantallas afectadas. Aplique con el token de impacto devuelto y una protección de revisión opcional como se describe en el flujo de trabajo de la playlist. Los pines existentes de la playlist permanecen sin cambios hasta aplicar. En caso de conflicto de revisión, lea la aplicación nuevamente antes de decidir si reintentar; no cree una aplicación de reemplazo solo para evitar el conflicto.

Listar las aplicaciones del proyecto.

app list

Sin parámetros.

screenrig app list

Cambiar el nombre visible de una aplicación.

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

screenrig app rename app_01EXAMPLEAPP00000000000 --name "Lobby welcome"

Solo cambia el nombre visible. El ID de la aplicación, sus lanzamientos, sus datos clave/valor y las listas de reproducción que fijan sus lanzamientos se mantienen como están, y no se sube ningún directorio. Renombrar al nombre actual deja la revisión sin cambios. Los nombres pueden repetirse; dirija una aplicación por su ID.

Lea una aplicación.

app show <id>

screenrig app show app_01EXAMPLEAPP00000000000

latest_ready_release está ausente hasta que una primera publicación alcanza listo. El estado de publicación vive en la operación y el lanzamiento, no en la aplicación. last_used_at está ausente hasta que una pantalla reproduce la aplicación por primera vez.

Eliminar una aplicación y todas sus versiones.

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

screenrig app delete app_01EXAMPLEAPP00000000000

No hay eliminación por lanzamiento. Mientras una pantalla muestra una de las versiones de la aplicación, la eliminación responde application_in_use: primero dé a esas pantallas otro contenido. La eliminación no verifica listas de reproducción que fijan una versión sin mostrarla, así que actualice o elimine esas listas también.

Listar las claves almacenadas para una aplicación.

kv list --app-id ID

screenrig kv list --app-id app_01EXAMPLEAPP00000000000

Lea una clave.

kv get --app-id ID <key>

screenrig kv get --app-id app_01EXAMPLEAPP00000000000 menu

La respuesta lleva el valor en data.value_base64, incluidos los valores JSON: descodifíquelo y analice JSON solo cuando data.content_type indique JSON. kv list omite los valores.

Escriba una clave desde JSON, un archivo o bytes 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"}'

Eliminar una clave.

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

screenrig kv delete --app-id app_01EXAMPLEAPP00000000000 menu

Crear un webhook que escriba una clave de una aplicación o, con --card, el documento de datos de una tarjeta, y recibir su URL y secreto una vez.

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 con sus opciones y --handshake se aplican solo a un webhook de tarjeta.

El sobre es el webhook: data.id (kvw_…), data.key o, para una tarjeta, data.card_id, data.url (https://api.screenrig.ai/api/applications/<app_id>/kv-webhooks/<id>/write, o https://api.screenrig.ai/api/cards/<card_id>/kv-webhooks/<id>/write) y data.secret (srkw_…). Un webhook de tarjeta que firma incluye también data.signing_secret (whsec_…). Introduzca ahora la URL y los secretos en el sistema remitente. Ningún comando posterior los vuelve a mostrar. Tras una creación interrumpida o ambigua, vuelva a ejecutar el mismo comando dentro de 24 horas: reutiliza la clave de idempotencia guardada, y el servidor devuelve el mismo webhook y los mismos secretos en lugar de crear otro.

Listar los webhooks de una aplicación o de una tarjeta, los más antiguos primero.

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

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

Cada elemento tiene id, key, description, url, created_at y, una vez que ha escrito, last_used_at. El elemento de un webhook de tarjeta tiene card_id en lugar de key, además de mapping (null cuando el objeto enviado es el documento), enabled, signing y, si están definidos, key_template, verify y handshake. Una lista nunca contiene un secreto.

Eliminar un webhook. Su URL deja de funcionar de inmediato y la clave o el documento de la tarjeta mantiene su valor.

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

Reemplazar el secreto de un webhook y recibir el nuevo una vez.

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

El sobre contiene el nuevo secreto en data.secret. El secreto anterior deja de funcionar de inmediato, así que introduzca el nuevo en el sistema remitente. Con --signing, el sobre contiene en su lugar el nuevo secreto de firma en data.signing_secret, y el secreto srkw_ del webhook permanece. Tras una rotación interrumpida o ambigua, vuelva a ejecutar el mismo comando: reutiliza la clave de idempotencia guardada, y el servidor devuelve la rotación que ya se hizo en lugar de rotar de nuevo.