Comandi
Utilizzo
Tutti i comandi devono essere eseguiti nella cartella della tua app con il progetto Capacitor correttamente inizializzato
Init
npx @capgo/cli@latest init [apikey]
Questo metodo serve per guidarti passo dopo passo
Aggiungerà la tua app a Capgo Aggiungerà il codice alla tua app per validare l’aggiornamento Inoltre, compilerà la tua app Successivamente, caricherà la tua app su Capgo E ti aiuterà a verificare se l’aggiornamento funziona
Login
npx @capgo/cli login [apikey]
Questo metodo serve a memorizzare l’apikey
per te
Opzionalmente puoi fornire:
--local
Questo memorizzerà la tua apikey nel repository locale e la ignorerà in git
Doctor
npx @capgo/cli doctor
Comando per verificare se sei aggiornato con i pacchetti Capgo
Questo comando sarà utile anche per le segnalazioni di bug
App
Add
npx @capgo/cli app add [appId]
[appId]
il tuo ID app il formato comtestapp
è spiegato qui
💡 Tutte le opzioni verranno dedotte dalla tua configurazione se non fornite
Opzionalmente, puoi fornire:
--icon [/path/to/my/icon]
per avere un’icona personalizzata visualizzata nell’app web Capgo--name [test]
per avere un nome personalizzato nella lista--apikey [key]
chiave API da collegare al tuo account--retention [retention]
periodo di conservazione del bundle dell’app in giorni, 0 di default = infinito
Esempio di capacitorconfigjson
per appId e AppName, l’icona viene cercata nella cartella resources
{ "appId": "eeforgrcapacitor_go", "appName": "Capgo", "webDir": "dist"}
Set
npx @capgo/cli app set [appId]
[appId]
è il tuo ID app, il formato è spiegato qui
Opzionalmente, puoi fornire:
--icon [/path/to/my/icon]
per avere un’icona personalizzata visualizzata nell’app web Capgo--name [test]
per avere un nome personalizzato nella lista--retention [retention]
periodo di conservazione del bundle dell’app in giorni, 0 di default = infinito--apikey [key]
chiave API da collegare al tuo account
List
npx @capgo/cli app list [appId]
[appId]
il tuo ID app il formato comtestapp
è spiegato qui
Opzionalmente, puoi fornire:
--apikey [key]
chiave API da collegare al tuo account
Delete
npx @capgo/cli app delete [appId]
[appId]
il tuo ID app il formato comtestapp
è spiegato qui
Opzionalmente, puoi fornire:
--apikey [key]
chiave API da collegare al tuo account--bundle
con il numero di versione eliminerà solo questa versione
Debug
npx @capgo/cli app debug [appId]
[appId]
il tuo ID app il formato comtestapp
è spiegato qui
Opzionalmente, puoi fornire:
--apikey [key]
chiave API da collegare al tuo account--device
con il dispositivo specifico che vuoi debuggare
Setting
npx @capgo/cli app setting [path]
Modifica la configurazione di Capacitor
[path]
- percorso dell’impostazione che vorresti modificare Per esempio, per modificare l’appId
, fornisci appId
Se desideri disabilitare l’aggiornamento automatico in capacitor-updater
fornisci pluginsCapacitorUpdaterautoUpdate
DEVI fornire o --string
o --bool
!
Opzioni:
--string <string>
- imposta l’impostazione come stringa--bool <true | false>
- imposta l’impostazione come booleano
Bundle
Upload
npx @capgo/cli bundle upload [appId]
[appId]
è il tuo ID app, il formato è spiegato qui
Opzionalmente, puoi fornire:
--apikey <apikey>
chiave API da collegare al tuo account--path <path>
Percorso della cartella da caricare--channel <channel>
Canale da collegare--external <url>
Collega a URL esterno invece di caricare su Capgo Cloud--iv-session-key <key>
Imposta la IV e la chiave di sessione per l’URL del bundle esterno--s3-endpoint <s3Endpoint>
URL dell’endpoint S3 Non funziona con il caricamento parziale o l’opzione external--s3-region <region>
Regione per il tuo bucket S3--s3-apikey <apikey>
Chiave API per il tuo endpoint S3--s3-apisecret <apisecret>
Segreto API per il tuo endpoint S3--s3-bucket-name <bucketName>
Nome per il tuo bucket AWS S3--s3-port <port>
Porta per il tuo endpoint S3--no-s3-ssl
Disabilita SSL per il caricamento S3--key <key>
Percorso personalizzato per la chiave di firma pubblica (sistema v1)--key-data <keyData>
Chiave di firma pubblica (sistema v1)--key-v2 <key>
Percorso personalizzato per la chiave di firma privata (sistema v2)--key-data-v2 <keyData>
Chiave di firma privata (sistema v2)--bundle-url
Stampa l’URL del bundle nello stdout--no-key
Ignora la chiave di firma e invia l’aggiornamento in chiaro--no-code-check
Ignora il controllo se notifyAppReady() è chiamato nel codice sorgente e index presente nella cartella root--display-iv-session
Mostra nella console la IV e la chiave di sessione utilizzate per crittografare l’aggiornamento--bundle <bundle>
Numero di versione del bundle da caricare--min-update-version <minUpdateVersion>
Versione minima richiesta per aggiornare a questa versione Usato solo se l’aggiornamento automatico è disabilitato nei metadati del canale--auto-min-update-version
Imposta la versione minima di aggiornamento basata sui pacchetti nativi--ignore-metadata-check
Ignora il controllo dei metadati (node_modules) durante il caricamento--ignore-checksum-check
Ignora il controllo del checksum durante il caricamento--timeout <timeout>
Timeout per il processo di caricamento in secondi--partial
Non carica file parziali su Capgo cloud--tus
Carica il bundle usando il protocollo tus--multipart
Usa il protocollo multipart per caricare dati su S3, Deprecato, usa TUS invece--encrypted-checksum <encryptedChecksum>
Un checksum crittografato (firma) Usato solo quando si carica un bundle esterno--package-json <packageJson>
Un percorso verso packagejson Utile per i monorepo--auto-set-bundle
Imposta il bundle in capacitorconfigjson--node-modules <nodeModules>
Una lista di percorsi verso node_modules Utile per i monorepo (separati da virgola es: //node_modules,/node_modules)
⭐️ L’opzione external aiuta a sbloccare 2 casi: aziende con preoccupazioni sulla privacy, non inviano il codice a terze parti e app più grandi di 200 MB Con questa impostazione, Capgo memorizza solo il link allo zip e invia il link a tutte le app
👀 Capgo cloud non guarda mai cosa c’è nel link (per l’opzione external), o nel codice quando è memorizzato
🔑 Puoi aggiungere un secondo livello di sicurezza usando la crittografia, quindi Capgo non sarà in grado di guardare o modificare nulla, diventa “trustless”
Esempio di packagejson
per la versione
{ "version": "102"}
⛔ La versione deve essere maggiore di “000”
💡 Non dimenticare di aggiornare il numero di versione ogni volta che ne invii uno, il numero di versione non può essere sovrascritto o riutilizzato dopo l’eliminazione per motivi di sicurezza
List
npx @capgo/cli bundle list [appId]
[appId]
il tuo ID app il formato comtestapp
è spiegato qui
Opzionalmente, puoi fornire:
--apikey [key]
chiave API da collegare al tuo account
Delete
npx @capgo/cli bundle delete [appId]
[appId]
il tuo ID app il formato comtestapp
è spiegato qui
Opzionalmente, puoi fornire:
--apikey [key]
chiave API da collegare al tuo account--bundle
con il numero di versione eliminerà solo questa versione
Cleanup
in un intervallo SemVer per una versione major su Cloud
npx @capgo/cli bundle cleanup [appId] --bundle=[majorVersion] --keep=[numberToKeep]
[appId]
il tuo ID app il formato comtestapp
è spiegato qui
Opzionalmente, puoi fornire:
--apikey [key]
chiave API da collegare al tuo account--bundle [majorVersion]
una versione per cui desideri rimuovere i pacchetti precedenti, manterrà l’ultimo +numberToKeep
*--keep [numberToKeep]
il numero di pacchetti che desideri mantenere (predefinito 4)
Per esempio: Se hai 10 versioni da 1001 a 10011, e usi npx @capgo/cli cleanup [appId] --bundle=1000
rimuoverà da 1001 a 1006 mentre 1007 fino a 10011 verranno mantenuti
Se hai 20 versioni in totale, e non fornisci un numero di bundle come questo: npx @capgo/cli cleanup [appId] --keep=2
Rimuoverà 18 versioni e manterrà le ultime 2
Questo comando chiederà conferma, mostra una tabella di ciò che manterrà e rimuoverà
Encrypt
Attenzione: Questo comando è deprecato e verrà rimosso nella prossima versione maggiore. Si prega di utilizzare il nuovo sistema di crittografia
npx @capgo/cli bundle encrypt [path/to/zip]
Questo comando viene utilizzato quando si usa una fonte esterna per memorizzare il codice o per scopi di test
Opzionalmente, puoi fornire:
--key [/path/to/my/private_key]
il percorso della tua chiave privata
--key-data [privateKey]
i dati della chiave privata, se vuoi usarla inline
Il comando stamperà il tuo ivSessionKey
e genererà uno zip crittografato, da utilizzare con il comando upload o decrypt
Encrypt V2
npx @capgo/cli bundle encryptV2 [path/to/zip] [checksum]
Questo comando viene utilizzato quando si usa una fonte esterna per memorizzare il codice o per scopi di test Il checksum è lo sha256 del bundle (generato da —key-v2), viene utilizzato per verificare l’integrità del file dopo la decrittografia Verrà crittografato con la chiave privata e inviato insieme al bundle Nella crittografia v2 il checksum viene aggiornato per diventare una “firma” del bundle
Opzionalmente, puoi fornire:
--key [/path/to/my/private_key]
il percorso della tua chiave privata
--key-data [privateKey]
i dati della chiave privata, se vuoi usarla inline
--json
per output info come json
Il comando stamperà il tuo ivSessionKey
e genererà uno zip crittografato, da utilizzare con il comando upload o decrypt
Decrypt
npx @capgo/cli bundle decrypt [path/to/zip] [ivSessionKey]
Opzionalmente, puoi fornire:
--key [/path/to/my/private_key]
il percorso della tua chiave privata
--key-data [privateKey]
i dati della chiave privata, se vuoi usarla inline
Questo comando è principalmente utilizzato per scopi di test, decrittograferà lo zip e stamperà la chiave di sessione decrittografata in base64 nella console
Decrypt V2
npx @capgo/cli bundle decryptV2 [path/to/zip] [ivSessionKey]
Opzionalmente, puoi fornire:
--key [/path/to/my/private_key]
il percorso della tua chiave privata
--key-data [privateKey]
i dati della chiave privata, se vuoi usarla inline
Questo comando è principalmente utilizzato per scopi di test, decrittograferà lo zip e stamperà la chiave di sessione decrittografata in base64 nella console
--checksum [checksum]
il checksum del file, verificherà il checksum dopo la decrittografia
Zip
npx @capgo/cli bundle zip [appId]
[appId]
è il tuo ID app, il formato è spiegato qui
Opzionalmente, puoi fornire:
--path [/path/to/my/bundle]
per caricare una cartella specifica--bundle [100]
per impostare il numero di versione del bundle del filename--name [myapp]
per sovrascrivere il nome del file--json
per output info come json--no-code-check
per ignorare il controllo del codice e inviare comunque il bundle--key-v2
per utilizzare il nuovo sistema di crittografia Questo è necessario poiché il nuovo sistema di crittografia utilizza checksum migliori per verificare l’integrità del file
Compatibility
npx @capgo/cli bundle compatibility [appId] -c [channelId]
[appId]
è il tuo ID app, il formato è spiegato qui
[channelId]
il nome del tuo nuovo canale
Opzionalmente, puoi fornire:
--apikey [key]
chiave API per collegare al tuo account--text
usa testo invece di emoji nella tabella--channel [channel]
il canale per verificare la compatibilità--package-json <packageJson>
Un percorso verso packagejson Utile per monorepos--node-modules <nodeModules>
Una lista di percorsi verso node_modules Utile per monorepos (separati da virgola es: //node_modules,/node_modules)
Channel
Add
npx @capgo/cli channel add [channelId] [appId]
[channelId]
il nome del tuo nuovo canale [appId]
il tuo ID app il formato comtestapp
è spiegato qui
Delete
npx @capgo/cli channel delete [channelId] [appId]
[channelId]
il nome del canale che vuoi eliminare [appId]
il tuo ID app il formato comtestapp
è spiegato qui
List
npx @capgo/cli channel list [appId]
[appId]
il tuo ID app il formato comtestapp
è spiegato qui
Opzionalmente, puoi fornire:
--apikey [key]
chiave API per collegare al tuo account
Set
npx @capgo/cli channel set [channelId] [appId]
[appId]
è il tuo ID app, il formato è spiegato qui
Opzionalmente, puoi fornire:
--bundle [123]
il tuo bundle app già inviato al cloud, per collegarlo a un canale--latest
ottiene la versione del bundle dapackagejson:version
, non può essere usato con--bundle
--state [ normal | default ]
imposta lo stato del canale, può esserenormal
odefault
Un canale deve esseredefault
--downgrade
permette al canale di inviare versioni precedenti ai dispositivi--no-downgrade
non permette al canale di inviare versioni precedenti ai dispositivi--upgrade
permette al canale di inviare aggiornamenti (major) ai dispositivi--no-upgrade
non permette al canale di inviare aggiornamenti (major) ai dispositivi--ios
permette al canale di inviare versioni ai dispositivi iOS--no-ios
non permette al canale di inviare versioni ai dispositivi iOS--android
permette al canale di inviare versioni ai dispositivi android--no-android
non permette al canale di inviare versioni ai dispositivi android--self-assign
permette ai dispositivi di auto-assegnarsi a questo canale--no-self-assign
non permette ai dispositivi di auto-assegnarsi a questo canale--disable-auto-update STRATEGY
Disabilita la strategia di auto aggiornamento per questo canale Le opzioni possibili sono: major, minor, metadata, none--apikey [key]
chiave API per collegare al tuo account
Strategia di disabilitazione aggiornamenti
Ci sono diversi modi per gestire la disabilitazione degli aggiornamenti per versioni troppo vecchie
Capgo non può aggiornare il codice nativo quindi un aggiornamento da una versione con il vecchio codice nativo a una versione con il codice nativo aggiornato non dovrebbe essere possibile
Ci sono un paio di modi per ottenere questo
Prima, la strategia major
Impedisce un aggiornamento da 000
-> 100
Il major è il numero evidenziato (100 e 000)
Seconda è la strategia minor
Impedisce un aggiornamento da 000
-> 110
o un aggiornamento da 110
a 120
ATTENZIONE questa strategia non impedisce un aggiornamento da 010
-> 110
Terza, la strategia patch
È stata aggiunta in capgo come modalità molto rigorosa Non è raccomandato usarla a meno che non si comprenda completamente come funziona
Affinché accetti un aggiornamento devono essere soddisfatte le seguenti condizioni:
- Il major è lo stesso tra la nuova e la vecchia versione
- Il minor è lo stesso tra la nuova e la vecchia versione
- Il patch della nuova versione è maggiore del patch della vecchia versione
Ecco un esempio di quali scenari l’aggiornamento è consentito o negato
- 00311 -> 00314 ✅
- 000 -> 00314 ✅
- 00316 -> 00314 ❌
- 01312 -> 00314 ❌
- 10312 -> 00314 ❌
Infine la strategia più complicata La strategia metadata
Prima devi sapere che inizialmente dopo averla abilitata gli aggiornamenti FALLIRANNO poiché il canale manca dei metadata richiesti
Se il canale manca di metadata vedrai un messaggio come questo:

Se vedi qualcosa del genere sai che devi andare al bundle corrente per il canale che sta fallendo e impostare i metadata
Prima, scopri quale canale sta fallendo Puoi farlo guardando la colonna misconfigured

Quindi vai al canale con errori e clicca su Bundle number
. Questo ti porterà alla pagina del bundle

Una volta lì, compila il campo Minimal update version
. Deve essere un semver
Se il valore che inserisci non è un semver riceverai un errore, ma se tutto va correttamente dovresti vedere qualcosa del genere:

Ora, probabilmente non vuoi impostare questi dati manualmente ogni volta che aggiorni. Fortunatamente, la CLI ti impedirà di inviare un aggiornamento senza questi metadati

Per caricare correttamente un bundle quando si usa l’opzione metadata
devi passare --min-update-version
con un semver valido. Qualcosa del genere:

--min-update-version
non è l’UNICO modo per gestire la compatibilità.
Esiste anche --auto-min-update-version
. Ecco come funziona:
- Prima, controlla la versione attualmente caricata sul canale. Verifica la compatibilità come farebbe il comando
bundle compatibility
- Secondo, se la nuova versione è compatibile al 100% riutilizza il
min_update_version
dall’ultima versione nel canale Se non lo è, imposta ilmin_update_version
al numero del bundle della versione appena caricata
Riceverai sempre un’informazione su quale sia il min_update_version
quando usi questa opzione. Apparirà qualcosa del genere:

Se la nuova versione non è compatibile dovrebbe apparire qualcosa del genere:

Crittografia end-to-end (Trustless)
Capgo supporta la crittografia end-to-end, questo significa che il tuo bundle (codice) viene crittografato prima di essere inviato al cloud e decrittografato sul dispositivo. Per questo, devi generare una coppia di chiavi RSA, puoi usare il seguente comando per generarla
Il sistema di crittografia è una combinazione di RSA e AES, la chiave RSA viene usata per crittografare la chiave AES, e la chiave AES viene usata per crittografare il file
Vedi sotto per maggiori informazioni sul sistema di crittografia

Schema di crittografia
Crea una chiave per la tua app
npx @capgo/cli key create
Opzionalmente, puoi usare: --force
per sovrascrivere la chiave esistente. Questo comando creerà per te una coppia di chiavi nella tua app, e ti chiederà di salvare la chiave privata in un posto sicuro. Si raccomanda di non committare su git la chiave privata e di non condividerla con nessuno
Dopo il test locale, rimuovi la chiave dal file di configurazione e aggiungila nel passo CI con
key save
Salva la chiave nella configurazione della tua app
npx @capgo/cli key save
Opzionalmente, puoi usare:
--key [/path/to/my/private_key]
il percorso della tua chiave privata
--key-data [privateKey]
i dati della chiave privata, se vuoi usarla inline. Questo comando è utile se hai seguito la raccomandazione e non hai committato la chiave nella tua app e nella configurazione
Integrazione CI
Per automatizzare il tuo lavoro, ti consiglio di far fare il lavoro di push al nostro server tramite GitHub action
La nostra app demo
Non dimenticare di configurare la variabile d’ambiente CI con la tua API key