Applicazioni: comandi CLI

Impacchetta una cartella statica in un archivio deterministico senza caricarla.

app pack <directory> [--output FILE]

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

La busta riporta sha256, compressed_bytes, expanded_bytes, file_count, la lista delle voci e se il runtime SDK è stato iniettato. app upload impacchetta la cartella stessa, quindi usa questo comando solo se vuoi ispezionare prima l’archivio. Viene eseguito in locale e non richiede l’accesso.

Un pacchetto contiene al massimo 5000 file, 250 MiB decompressi e 100 MiB compressi, ogni file al massimo 32 MiB, con percorsi di al massimo 16 livelli e 255 byte. Il packing esclude i nomi che iniziano con ., node_modules/, bower_components/, jspm_packages/, vendor/, venv/, __pycache__/, CVS/, le source map *.map, i file di chiavi e credenziali (*.pem, *.key, *.p12, *.pfx, *.crt, *.cer, id_rsa, id_dsa, id_ecdsa, id_ed25519, credentials.json, secrets.json), i file temporanei e di backup degli editor, Thumbs.db e desktop.ini. Un file .screenrigignore nella radice della cartella aggiunge pattern in stile gitignore, uno per riga, e non può ripristinare un’esclusione integrata. Link simbolici, hardlink, file sparsi, dispositivi, percorsi duplicati (confrontati anche senza distinguere maiuscole e minuscole), file che cambiano durante il packing e una cartella senza index.html nella radice vengono rifiutati indicando il percorso: il comando termina con il codice 2 e non invia nulla.

Le applicazioni funzionano sotto una content security policy che blocca il codice inline. Il packing sposta gli stili e script inline in file _screenrig-inline-* accanto a ogni documento HTML e li collega. I gestori di eventi inline come onclick= e URL javascript: non possono essere spostati; il packing li rifiuta e indica file e riga.

Scrivi i tipi TypeScript di window.screenrig in una directory.

app types [directory]

screenrig app types ./src

La busta riporta path, bytes, sha256 e written, che vale false quando il file conteneva già i tipi attuali. Il file corrisponde al runtime che app pack e app upload iniettano, quindi esegui di nuovo il comando dopo aver aggiornato la CLI. Un screenrig.d.ts esistente viene sostituito per intero; una directory o un collegamento simbolico in quel percorso viene rifiutato e il comando termina con il codice 2. Viene eseguito in locale e non richiede l’accesso. TypeScript spiega cosa dichiarano i tipi.

Servi una directory in un harness Player locale per provare un’applicazione prima di caricarla.

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

screenrig app dev ./lobby-board --open

Il comando serve l’harness su http://play.screenrig.localhost:18890 e resta in esecuzione finché non lo fermi. Inietta il runtime come fa app pack, e segnala ciò che il packaging rifiuta, indicando file e riga, mentre modifichi. L’harness simula le capacità, la viewport, il nome dello schermo, il fuso orario e i parametri, il timer della pagina, la pausa, il display e l’uscita, gli eventi del dispositivo, e porte seriali, linee GPIO, periferiche Bluetooth LE e stampanti. Le righe emit e log vengono stampate nel terminale. Sviluppa in locale descrive i controlli.

Impacchetta una cartella, pubblicala come nuova release dell’applicazione e attendi il successo della pubblicazione.

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

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

Leggi tre campi: data.operation.state è succeeded, data.application.release_id è l’ID rel_ un primitivo application pin, e data.application.id è l’ID app_ che i comandi kv usano. Un’operazione riuscita, non un ID di rilascio da solo, indica che il rilascio è utilizzabile.

Ogni app upload crea una nuova applicazione e una prima release immutabile. Per pubblicare una release successiva della stessa app, usa app update. Una playlist continua a servire la release già fissata finché non modifichi quel primitivo.

Un trasferimento verso l’archiviazione interrotto viene ritentato fino a 4 volte finché il suo URL di caricamento è valido. Se continua a non riuscire, esegui di nuovo lo stesso comando per riprendere lo stesso caricamento.

Pubblica una nuova versione di un'applicazione esistente, preservando identità, nome e K/V dell'applicazione.

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

screenrig app update app_01EXAMPLEAPP00000000000 ./lobby-board

Il nome resta invariato; modificalo con app rename. Attendere data.operation.state: "succeeded", quindi usare playlist replace-release per rivedere la pagina esatta, il primitivo, la nuova versione e gli schermi interessati. Applicare con il token di impatto restituito e una facoltativa protezione di revisione come descritto nel flusso di lavoro della playlist. I pin esistenti della playlist rimangono invariati fino all’applicazione. In caso di conflitto di revisione, leggere nuovamente l’app prima di decidere se riprovare; non creare un’applicazione sostitutiva solo per bypassare il conflitto.

Elenca le applicazioni del progetto

app list

Nessun parametro.

screenrig app list

Cambia il nome visualizzato di un’app.

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

screenrig app rename app_01EXAMPLEAPP00000000000 --name "Lobby welcome"

Cambia solo il nome visualizzato. L’ID dell’app, le sue release, i suoi dati chiave/valore e le playlist che fissano le sue release restano invariati e non viene caricata alcuna cartella. Rinominare con il nome attuale lascia invariata la revisione. I nomi possono ripetersi; indirizza un’app tramite il suo ID.

Leggi un’applicazione.

app show <id>

screenrig app show app_01EXAMPLEAPP00000000000

latest_ready_release è assente fino a quando una prima pubblicazione non raggiunge lo stato pronto. Lo stato di pubblicazione vive sull’operazione e sulla release, non sull’app. last_used_at è assente fino a quando uno schermo riproduce l’app per la prima volta.

Elimina un’app e tutte le sue release.

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

screenrig app delete app_01EXAMPLEAPP00000000000

Non esiste un’eliminazione per release. Mentre uno schermo mostra una delle release dell’applicazione, l’eliminazione risponde application_in_use: assegna prima altri contenuti a quegli schermi. L’eliminazione non controlla playlist che fissano una release senza mostrarla, quindi aggiorna o elimina anche quelle playlist.

Elenca le chiavi archiviate per un’applicazione

kv list --app-id ID

screenrig kv list --app-id app_01EXAMPLEAPP00000000000

Leggi una chiave.

kv get --app-id ID <key>

screenrig kv get --app-id app_01EXAMPLEAPP00000000000 menu

La risposta contiene il valore in data.value_base64, compresi i valori JSON: decodificalo e interpreta JSON solo quando data.content_type indica JSON. kv list omette i valori.

Scrivi una chiave da JSON, un file o byte 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"}'

Elimina una chiave.

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

screenrig kv delete --app-id app_01EXAMPLEAPP00000000000 menu

Crea un webhook che scrive una chiave di un’applicazione o, con --card, il documento dati di una scheda, e ricevi il suo URL e segreto una sola volta.

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 le sue opzioni e --handshake valgono solo per un webhook di scheda.

La busta è il webhook: data.id (kvw_…), data.key oppure, per una scheda, 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) e data.secret (srkw_…). Un webhook di scheda che firma contiene anche data.signing_secret (whsec_…). Inserisci ora l’URL e i segreti nel sistema mittente. Nessun comando successivo li mostra di nuovo. Dopo una creazione interrotta o ambigua, riesegui lo stesso comando entro 24 ore: riutilizza la chiave di idempotenza salvata e il server restituisce lo stesso webhook e gli stessi segreti invece di crearne un altro.

Elenca i webhook di un’applicazione o di una scheda, i più vecchi per primi.

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

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

Ogni elemento ha id, key, description, url, created_at e, una volta scritto, last_used_at. L’elemento di un webhook di scheda ha card_id al posto di key, più mapping (null quando l’oggetto inviato è il documento), enabled, signing e, se impostati, key_template, verify e handshake. Una lista non contiene mai un segreto.

Elimina un webhook. Il suo URL smette di funzionare immediatamente e la chiave o il documento della scheda mantiene il suo valore.

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

Sostituisci il segreto di un webhook e ricevi quello nuovo una volta sola.

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

La busta contiene il nuovo segreto in data.secret. Il vecchio segreto smette di funzionare subito, quindi inserisci il nuovo nel sistema mittente. Con --signing, la busta contiene invece il nuovo segreto di firma in data.signing_secret, e il segreto srkw_ del webhook resta. Dopo una rotazione interrotta o ambigua, riesegui lo stesso comando: riutilizza la chiave di idempotenza salvata e il server restituisce la rotazione già avvenuta invece di ruotare di nuovo.