Saltare al contenuto

Comandi

Tutti i comandi dovrebbero essere eseguiti nella cartella del tuo progetto con capacitor acceso correttamente.

npx @capgo/cli@latest init [apikey]

Questo metodo è qui per guidarti passo dopo passo.

Aggiungerà il tuo progetto a Capgo. Aggiungerà code al tuo progetto per validare l'aggiornamento. Inoltre, costruirà il tuo progetto. Inoltre, caricherà il tuo progetto su Capgo. E ti aiuterà a verificare se l'aggiornamento funziona.

npx @capgo/cli login [apikey]

Questo metodo è qui per ricordare i apikey per te.

Facoltativamente puoi dare:

--local Questo salverà il tuo apikey nel repository locale e lo ignorerà in git.

npx @capgo/cli doctor

Comando per verificare se sei aggiornato con Capgo pacchetti.

Questo comando sarà anche utile per i rapporti di bug.

npx @capgo/cli app add [appId]

[appId] il tuo ID app nel formato com.test.app è spiegato qui.

💡 Tutte le opzioni verranno dedotte nella tua configurazione se non fornite.

Facoltativamente, puoi fornire:

  • --icon [/path/to/my/icon] to have a custom icon display in Capgo web app.
  • --name [test] per avere un nome personalizzato nella lista.
  • --apikey [key] API chiave per collegare il tuo account.
  • --retention [retention] periodo di conservazione del pacchetto app in giorni, 0 di default = infinito.

Esempio di capacitor.config.json per appId e AppName, l'icona viene cercata nella cartella risorse

{
"appId": "ee.forgr.capacitor_go",
"appName": "Capgo",
"webDir": "dist"
}

npx @capgo/cli app set [appId]

[appId] è il tuo ID app, il formato viene spiegato qui.

Facoltativamente, puoi fornire:

  • --icon [/path/to/my/icon] to have a custom icon display in Capgo web app.
  • --name [test] per avere un nome personalizzato nella lista.
  • --retention [retention] periodo di conservazione del bundle dell'app in giorni, 0 per impostazione predefinita = infinito.
  • --apikey [key] API chiave per collegarti al tuo account.

npx @capgo/cli app list [appId]

[appId] il tuo ID dell'applicazione nel formato com.test.app è spiegato qui.

Facoltativamente, puoi fornire:

  • --apikey [key] API chiave per collegare il tuo account.

npx @capgo/cli app delete [appId]

[appId] il tuo ID dell'applicazione nel formato com.test.app è spiegato qui.

Facoltativamente, puoi fornire:

  • --apikey [key] chiave API per collegarsi al proprio account.
  • --bundle con il numero di versione eliminerà solo questa versione.

npx @capgo/cli app debug [appId]

[appId] il proprio ID dell'applicazione nel formato com.test.app è spiegato qui.

Facoltativamente, si può fornire:

  • --apikey [key] chiave API per collegarsi al proprio account.
  • --device con il dispositivo specifico che si desidera debuggare

npx @capgo/cli app setting [path]

Modifica il Capacitor config.

[path] - percorso della impostazione che desideri modificare. Ad esempio, per modificare il appId, fornisce appId. Se desideri disabilitare l'aggiornamento automatico nel capacitor-updater, fornisce plugins.CapacitorUpdater.autoUpdate con --string off.

DEVI fornire o --string Opzioni: --bool!

- imposta l'impostazione a una stringa

  • --string <string> - imposta l'impostazione a un booleano
  • --bool <true | false> Bundle

npx @capgo/cli bundle upload [appId]

[appId] è il tuo ID dell'applicazione, il formato è spiegato qui.

Opzionalmente, puoi fornire:

  • --apikey <apikey> chiave API per collegarsi al tuo account.
  • --path <path> Percorso del folder da caricare.
  • --channel <channel> Canale da collegare.
  • --external <url> Collega a un URL esterno al posto di caricare su Capgo Cloud.
  • --iv-session-key <key> Imposta la chiave di cifratura e la chiave di sessione per l'URL del bundle esterno.
  • --s3-endpoint <s3Endpoint> URL del punto di fine endpoint S3. Non funziona con le opzioni di upload delta o esterno.
  • --s3-region <region> Regione per il tuo bucket S3.
  • --s3-apikey <apikey> API chiave per il tuo endpoint S3.
  • --s3-apisecret <apisecret> API segreto per il tuo endpoint S3.
  • --s3-bucket-name <bucketName> Nome per il tuo bucket S3 AWS.
  • --s3-port <port> Porta per il tuo endpoint S3.
  • --no-s3-ssl Disabilita SSL per l'upload 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 pacchetto nella console.
  • --no-key Ignora la chiave di firma e invia l'aggiornamento chiaro.
  • --no-code-check Ignora la verifica se notifyAppReady() viene chiamata nella sorgente code e l'indice presente nella cartella radice.
  • --display-iv-session Mostra nella console la chiave IV e di sessione utilizzate per cifrare l'aggiornamento.
  • --bundle <bundle> Numero di versione del bundle da caricare.
  • --min-update-version <minUpdateVersion> Versione minima richiesta per aggiornarsi a questa versione. Utilizzato solo se l'aggiornamento automatico è disabilitato nel canale tramite metadati.
  • --auto-min-update-version Imposta la versione minima di aggiornamento basata sui pacchetti nativi.
  • --ignore-metadata-check Ignora la verifica dei metadati (node_modules) quando si carica.
  • --ignore-checksum-check Ignora la verifica del checksum quando si carica.
  • --timeout <timeout> Timeout per il processo di caricamento in secondi.
  • --delta Carica i file Delta (manifest) insieme al bundle completo.
  • --delta-only Carica solo gli aggiornamenti Delta (manifest), saltando il bundle completo.
  • --no-delta Disabilita i caricamenti Delta (manifest) (utile se è abilitato il modo di applicazione istantanea ma si desidera un bundle completo). autoUpdate Disabilita i caricamenti Delta (manifest) (utile se è abilitato il modo di applicazione istantanea ma si desidera un bundle completo).
  • --tus Carica il bundle utilizzando il protocollo tus.
  • --multipart Utilizza il protocollo multipart per caricare i dati su S3, Obsoleto, utilizza TUS al suo posto.
  • --encrypted-checksum <encryptedChecksum> Un calcolo crittografato (firma). Utilizzato solo quando si carica un bundle esterno.
  • --package-json <packageJson> Un percorso per package.json. Utile per i monorepos.
  • --auto-set-bundle Imposta il bundle in capacitor.config.json.
  • --node-modules <nodeModules> Una lista di percorsi per node_modules. Utile per i monorepos (separati da virgole, ad esempio: ../../node_modules,./node_modules)

⭐️ L'opzione esterna aiuta a sbloccare 2 casi: aziende con preoccupazioni sulla privacy, non inviare il code a un terzo partito e app più grandi di 200 MB. Con questa impostazione, Capgo memorizza solo il collegamento al file zip e invia il collegamento a tutte le app.

👀 Il cloud di Capgo non guarda mai cosa c'è nel collegamento (per l'opzione esterna), o in code quando memorizzato.

🔑 Puoi aggiungere un secondo strato di sicurezza utilizzando la crittografia, quindi Capgo non potrà più guardare o modificare nulla, diventa “senza fiducia”.

Esempio di package.json per versione

{
"version": "1.0.2"
}

⛔ La versione dovrebbe essere maggiore di “0.0.0”.

💡 Non dimenticare di aggiornare il numero di versione ogni volta che lo invii, il numero di versione non può essere sovrascritto o riutilizzato dopo la cancellazione per motivi di sicurezza.

npx @capgo/cli bundle list [appId]

[appId] il tuo ID dell'applicazione nel formato com.test.app è spiegato qui.

Opzionalmente, puoi fornire:

  • --apikey [key] API chiave per collegarsi al tuo account.

npx @capgo/cli bundle delete [appId]

[appId] il tuo ID dell'applicazione nel formato com.test.app è spiegato qui.

Facoltativamente, puoi fornire:

  • --apikey [key] la chiave API per collegare il tuo account.
  • --bundle con il numero di versione cancellerà solo questa versione.

in un intervallo SemVer per una versione maggiore su Cloud

npx @capgo/cli bundle cleanup [appId] --bundle=[majorVersion] --keep=[numberToKeep]

[appId] il tuo ID app nel formato com.test.app è spiegato qui.

Facoltativamente, puoi fornire:

  • --apikey [key] chiave API per collegarsi al tuo account.
  • --bundle [majorVersion] una versione che desideri rimuovere le precedenti versioni dei pacchetti, terrà l'ultima + numberToKeep.
  • --keep [numberToKeep] il numero di pacchetti da mantenere (di default 4).

Ad esempio: se hai 10 versioni da 10.0.1 a 10.0.11, e utilizzi npx @capgo/cli cleanup [appId] --bundle=10.0.0 rimuoverà 10.0.1 a 10.0.6. 10.0.7 fino a 10.0.11 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 terrà le ultime 2.

Questa operazione richiederà conferma, mostra una tabella di cosa terrà e rimuoverà.

Avviso: 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 utilizza una fonte esterna per memorizzare il tuo code o per scopi di test.

Facoltativamente, puoi fornire:

--key [/path/to/my/private_key] la percorso della tua chiave privata. --key-data [privateKey] i dati della chiave privata, se desideri utilizzare inline. Il comando stampa il tuo ivSessionKeyy e genera un file zip crittografato, da utilizzare con il comando di caricamento o il comando di decrittografia.

npx @capgo/cli bundle encrypt [path/to/zip] [checksum]

Questo comando viene utilizzato quando si utilizza una fonte esterna per memorizzare il tuo code 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. In crittografia v2 il checksum viene aggiornato per diventare una “firma” del bundle.

--key [/path/to/my/private_key] la strada del tuo chiave privata. --key-data [privateKey] i dati della chiave privata, se desideri utilizzare inline. --json per stampare info in formato JSON. Il comando stampa il tuo ivSessionKeyy e genera un zip crittografato, per utilizzarlo con il comando di upload o il comando di decrittografia.

npx @capgo/cli bundle decrypt [path/to/zip] [ivSessionKey]

Facoltativamente, puoi fornire:

--key [/path/to/my/private_key] la strada del tuo chiave privata.

--key-data [privateKey] i dati della chiave privata, se desideri utilizzare inline. Questo comando è principalmente utilizzato per scopi di test, decrittografa il zip e stampa la chiave di sessione decrittografata in base64 nella console.

npx @capgo/cli bundle decryptV2 [path/to/zip] [ivSessionKey]

Facoltativamente, puoi fornire:

--key [/path/to/my/private_key] la via della tua chiave privata. --key-data [privateKey] i dati della chiave privata, se desideri utilizzare inline. Questo comando è principalmente utilizzato per scopi di test, decifrerà il zip e stampa la chiave di sessione base64 decifrata nella console. --checksum [checksum] il checksum del file, verificherà il checksum dopo la decifrazione.

npx @capgo/cli bundle zip [appId]

[appId] è il tuo ID app, il formato è spiegato qui.

Opzionalmente, puoi dare:

  • --path [/path/to/my/bundle] per caricare una cartella specifica.
  • --bundle [1.0.0] per impostare il numero di versione del pacchetto del nome del file.
  • --name [myapp] per sovrascrivere il nome del file.
  • --json per visualizzare le informazioni come JSON.
  • --no-code-check per ignorare il controllo code e inviare comunque il pacchetto.
  • --key-v2 per utilizzare il nuovo sistema di crittografia. Ciò è richiesto poiché il nuovo sistema di crittografia utilizza checksum migliori per verificare l'integrità del file.

npx @capgo/cli bundle compatibility [appId] -c [channelName]

[appId] è il tuo ID app, il formato è spiegato qui. [channelName] il nome del canale da verificare.

Opzionalmente, puoi fornire:

  • --apikey [key] chiave API per collegarsi al tuo account.
  • --text utilizzare il testo al posto degli emoji nella tabella
  • --channel [channel] il canale da verificare la compatibilità con.
  • --package-json <packageJson> Un percorso per package.json. Utile per i monorepos
  • --node-modules <nodeModules> A lista di percorsi per node_modules. Utile per i monorepos (separati da virgole ad esempio: ../../node_modules,./node_modules)

npx @capgo/cli channel add [channelName] [appId]

[channelName] il nome del tuo nuovo canale, ad esempio production o beta. [appId] il tuo ID dell'applicazione nel formato com.test.app è spiegato qui.

npx @capgo/cli channel delete [channelName] [appId]

[channelName] il nome del canale che desiderate cancellare. [appId] il vostro ID dell'applicazione nel formato com.test.app è spiegato qui.

npx @capgo/cli channel list [appId]

[appId] il vostro ID dell'applicazione nel formato com.test.app è spiegato qui.

Facoltativamente, potete inserire:

  • --apikey [key] la chiave API per collegare il vostro account.

npx @capgo/cli channel set [channelName] [appId]

[appId] è il tuo ID dell'applicazione, il formato è spiegato qui. [channelName] il nome del canale che desideri configurare, ad esempio production o beta.

Opzionalmente, puoi fornire:

  • --bundle [1.2.3] il tuo bundle dell'applicazione già inviato in cloud, per collegarlo a un canale.
  • --latest ottenere la versione del bundle da package.json:version, non può essere utilizzato con --bundle.
  • --state [ normal | default ] impostare lo stato del canale, può essere normal o default. È necessario configurare un solo canale default.
  • --downgrade consente al canale di inviare versione di downgrade ai dispositivi.
  • --no-downgrade proibisce al canale di inviare versione di downgrade ai dispositivi.
  • --upgrade consente al canale di inviare versione di upgrade (maggiore) ai dispositivi.
  • --no-upgrade proibisce al canale di inviare versione di upgrade (maggiore) ai dispositivi.
  • --ios consente al canale di inviare versione ai dispositivi iOS.
  • --no-ios proibisce al canale di inviare versione ai dispositivi iOS.
  • --android consente al canale di inviare versione ai dispositivi Android.
  • --no-android proibisce al canale di inviare versione ai dispositivi Android.
  • --self-assign consente ai dispositivi di assegnarsi automaticamente a questo canale.
  • --no-self-assign proibisce ai dispositivi di assegnarsi automaticamente a questo canale.
  • --disable-auto-update STRATEGY Disabilita la strategia di aggiornamento automatico per questo canale. Le opzioni possibili sono: maggiore, minore, patch, metadati, nessuna.
  • --apikey [key] chiave API per collegarsi al proprio account.

Ci sono poche modalità per gestire la disabilitazione degli aggiornamenti per versioni troppo vecchie.
Capgo non può aggiornare il nativo code quindi un aggiornamento da una versione con il nativo vecchio code a una versione con il nativo aggiornato code non dovrebbe essere possibile. Ci sono un paio di modi per raggiungere questo obiettivo.

In primo luogo, la major strategia. Impedisce un aggiornamento dal baseline nativo 0.0.0 -> bundle di destinazione 1.0.0. Il numero maggiore è il numero evidenziato (1.0.0 e 0.0.0).
In secondo luogo, la minor strategia. Impedisce un aggiornamento quando il bundle di destinazione ha un numero maggiore o minore della baseline nativa del dispositivo, ad esempio 0.0.0 -> 1.1.0 o 1.1.0 -> 1.2.0.

Terzo, la patch strategia. È stata aggiunta in capgo come un modo molto rigoroso. Non è consigliato di utilizzarla a meno che non si comprenda completamente come funziona. Per accettare un aggiornamento, le seguenti condizioni devono essere soddisfatte:

  • Il maggiore è lo stesso tra il bundle di destinazione e version_build
  • Il minore è lo stesso tra il bundle di destinazione e version_build
  • Il patch è lo stesso tra il bundle di destinazione e version_build
  • Solo la suffisso di versione può differire, ad esempio prerelease (-beta.2) o metadati di costruzione (+build.2)

Ecco un esempio di quali scenari l'aggiornamento è consentito o negato

  • 1.0.0-beta.1 -> 1.0.0-beta.2 consentito
  • 1.0.0+build.1 -> 1.0.0+build.2 consentito
  • 1.0.0 -> 1.0.1 bloccato
  • 1.0.0 -> 1.1.0 bloccato
  • 1.0.0 -> 2.0.0 bloccato

La comparazione della strategia utilizza il baseline nativo inviato come version_builde non il bundle scaricato corrente inviato come version_name.

Infine la strategia più complessa. La metadata strategia.
In primo luogo, è necessario sapere che inizialmente dopo averlo abilitato gli aggiornamenti NON RISCONTRERANNO SUCCESSI poiché il canale manca dei metadati richiesti. Se il canale manca di metadati, vedrai un messaggio come questo:
Non è possibile trovare i metadati

Se vedi qualcosa di questo tipo, sai che devi andare al bundle corrente per il canale che sta fallendo e impostare i metadati.

In primo luogo, determina quale canale sta fallendo. Puoi farlo osservando il bundle corrente per il canale che sta fallendo e impostare i metadati.
In primo luogo, determina quale canale sta fallendo. Puoi farlo osservando il bundle corrente per il canale che sta fallendo e impostare i metadati. misconfigured colonna

tabella non configurata

Vai quindi al canale che sta fallendo e clicca su Bundle numberCiò dovrebbe portarti alla pagina del pacchetto.

Localizza il canale che sta fallendo

Una volta lì, riempi il Minimal update version campo. Ciò dovrebbe essere un sempre versione.
Se il valore che passi non è una semperversione, otterrai un errore, ma se tutto va bene dovresti vedere qualcosa come questo:

Imposta la versione minima

Ora, probabilmente non desideri impostare manualmente questo dato ogni volta che aggiorni. Fortunatamente, il CLI ti impedirà di inviare un aggiornamento senza questo metadati

CLI fallimento senza metadati

To upload correttamente un bundle quando si utilizza l' metadata opzione è necessario passare il --min-update-version con il valido semver. Qualcosa di simile a questo:

CLI upload con metadati

Il --min-update-version non è l'UNICO modo per fare la compatibilità. Esiste anche il --auto-min-update-version. Ecco come funziona.

In primo luogo, prende in considerazione la versione attualmente caricata sul canale. Controlla la compatibilità allo stesso modo del bundle compatibility command. Secondo, se la nuova versione è del 100% compatibile la riutilizza il min_update_version dalla versione più recente nel canale. Se non, allora imposta il min_update_version To il numero di bundle della versione appena caricata.

Otterai sempre informazioni su cosa è. min_update_version Quando si utilizza questa opzione. Vedrà qualcosa di questo tipo:

Versione di aggiornamento minima

Se la nuova versione non è compatibile dovrebbe vedere qualcosa di questo tipo:

Versione di aggiornamento minima non compatibile

Capgo supporta la crittografia end-to-end, ciò significa che il tuo bundle (code) viene crittografato prima di essere inviato in cloud e decrittografato sul dispositivo. Per questo, hai bisogno di generare una coppia di chiavi RSA, puoi utilizzare il seguente comando per generarle.

Il sistema di crittografia è una combinazione di RSA e AES, la chiave RSA viene utilizzata per crittografare la chiave AES, e la chiave AES viene utilizzata per crittografare il file.

Ecco di seguito ulteriori informazioni sul sistema di crittografia.

Come funziona la crittografia

Schema di crittografia

npx @capgo/cli key create

Se lo desideri, puoi fornire: --force per sovrascrivere la chiave esistente. Questo comando creerà per te una coppia di chiavi nel tuo app, e ti chiederà di salvare la chiave privata in un luogo sicuro. È consigliabile non commitare la chiave privata nel repository Git, e non condividerla con nessuno.

Dopo aver effettuato i test locali, rimuovi la chiave dal file di configurazione e aggiungila nel passo di integrazione CI con key save

npx @capgo/cli key save

Se lo desideri, puoi fornire:

--key [/path/to/my/public_key] il percorso del file della chiave pubblica.

--key-data [publicKey] i dati della chiave pubblica, se desideri utilizzare inline. Questo comando è utile se hai seguito la raccomandazione e non hai commitato la chiave nel file di configurazione dell'app.

Per automatizzare il tuo lavoro, ti consiglio di fare in modo che l'azione GitHub si occupi di inviare i dati sul nostro server

Tutorial dell'azione GitHub

GitHub - Cap-go/demo-app

Non dimenticare di configurare la variabile di ambiente CI con la tua chiave API

Se stai utilizzando Comandi per pianificare il dashboard e le operazioni API, connettilo con API Panoramica per i dettagli di implementazione in API Panoramica, Introduzione per i dettagli di implementazione in Introduzione, API Chiavi per i dettagli di implementazione in API Chiavi, Dispositivi per i dettagli di implementazione in Dispositivi, e Bundle per i dettagli di implementazione in Bundle.