Saltare al contenuto

Comandi

Questa pagina è un'introduzione guidata. Utilizza la riferimento delle attuali istruzioni per flag esatti: app, bundle, canalee costruire.

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 app a Capgo. Aggiungerà il code al tuo app per validare l'aggiornamento. Allo stesso modo, costruirà il tuo app. Inoltre, caricherà il tuo app su Capgo. E ti aiuterà a verificare se l'aggiornamento funziona.

npx @capgo/cli login [apikey]

Questo metodo è qui per ricordare il apikey per te.

Opzionalmente puoi fornire:

--local Questo memorizzerà il tuo apikey nel repository locale e lo ignorerà nel file .gitignore.

npx @capgo/cli doctor

Comando per verificare se sei aggiornato con i pacchetti Capgo.

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 ipotizzate nella tua configurazione se non fornite.

Opzionalmente, 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] la chiave API per collegare il tuo account.
  • --retention [retention] il periodo di conservazione del bundle dell'app in giorni, 0 di default = infinito.

Esempio di capacitor.config.json per appId e AppName, l'icona viene ipotizzata nel folder dei risorse

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

npx @capgo/cli app set [appId]

[appId] è il tuo ID app, la formattazione è spiegata qui.

Opzionalmente, puoi fornire:

  • --icon [/path/to/my/icon] per avere un'icona personalizzata nella Capgo app web.
  • --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.
  • --expose-metadata [true|false] per esporre i metadati del bundle (link e commento) al plugin.
  • --preview o --no-preview per abilitare o disabilitare i codici QR di anteprima del bundle e del canale.
  • --allow-device-custom-id o --no-allow-device-custom-id per controllare gli ID dei dispositivi personalizzati.
  • --block-provider-infra-requests o --no-block-provider-infra-requests per controllare la bloccata richiesta dei datacenter Google e Apple noti.
  • --build-timeout-minutes [5-360] per impostare il timeout di costruzione nativa.
  • --ios-store-url [url] o --android-store-url [url] per impostare l'URL del negozio.
  • --default-upload-channel [channel] per impostare il canale di upload predefinito.
  • --default-download-channel [channel] per impostare il canale di download predefinito, o --disable-download-channels per rendere tutti i canali di download non pubblici.
  • --apikey [key] chiave API per collegarsi al proprio account.

npx @capgo/cli app list [appId]

[appId] il tuo ID app nella forma 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 app nella forma com.test.app è spiegato qui.

Facoltativamente, puoi fornire:

  • --apikey [key] API chiave 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, puoi fornire:

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

npx @capgo/cli app setting [path]

Modifica la Capacitor configurazione.

[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 la impostazione a una stringa

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

npx @capgo/cli bundle upload [appId]

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

Opzionalmente, puoi fornire:

  • --apikey <apikey> API chiave per collegare al tuo account.
  • --path <path> Percorso della cartella da caricare.
  • --channel <channel> Canale per collegare.
  • --external <url> Collega a un URL esterno invece 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 caricamento delta o quella esterna.
  • --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 nel file sorgente code e l'indice presente nella cartella radice.
  • --display-iv-session Mostra nel console il IV e la chiave di sessione utilizzati 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 in base ai pacchetti nativi.
  • --ignore-metadata-check Ignora la verifica dei metadati (node_modules) durante l'upload.
  • --ignore-checksum-check Ignora la verifica del checksum durante l'upload.
  • --timeout <timeout> Timeout per il processo di upload 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 part 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 app 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 app 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 eliminerà 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 i pacchetti precedenti, terrà l'ultima + numberToKeep.
  • --keep [numberToKeep] il numero di pacchetti da mantenere (predefinito 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 pacchetti come questo: npx @capgo/cli cleanup [appId] --keep=2 Rimuoverà 18 versioni, e terrà le ultime 2.

Questa riga di comando chiederà 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. Nel 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 le informazioni in formato JSON. Il comando stampa il tuo ivSessionKeyy e genera un zip crittografato, per utilizzarlo con il comando di caricamento o il comando di decrittografia.

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

Se desideri, 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 base64 decrittografata nella console.

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

Se desideri, 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.

Opcionalmente, puoi dare:

  • --path [/path/to/my/bundle] per caricare una cartella specifica.
  • --bundle [1.0.0] per impostare il numero di versione del bundle nel 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, la formattazione è spiegata qui. [channelName] il nome del canale da controllare.

Opzionalmente, puoi fornire:

  • --apikey [key] la chiave API per collegarsi al tuo account.
  • --text utilizzare il testo al posto degli emoji nella tabella
  • --channel [channel] il canale da controllare la compatibilità con.
  • --package-json <packageJson> Un percorso per package.json. Utile per i monorepos
  • --node-modules <nodeModules> Una 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 app nella forma com.test.app è spiegato qui.

npx @capgo/cli channel list [appId]

[appId] il vostro ID app nella forma com.test.app è spiegato qui.

Facoltativamente, potete inserire:

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

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

[appId] è il tuo ID app, 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 app 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. Un canale deve essere default.
  • --downgrade consente al canale di inviare una versione di downgrade ai dispositivi.
  • --no-downgrade impedisce al canale di inviare una versione di downgrade ai dispositivi.
  • --upgrade consente al canale di inviare una versione di upgrade (maggiore) ai dispositivi.
  • --no-upgrade impedisce al canale di inviare una versione di upgrade (maggiore) ai dispositivi.
  • --ios consente al canale di inviare una versione ai dispositivi iOS.
  • --no-ios impedisce al canale di inviare una versione ai dispositivi iOS.
  • --android consente al canale di inviare una versione ai dispositivi Android.
  • --no-android impedisce al canale di inviare una versione ai dispositivi Android.
  • --self-assign consente ai dispositivi di assegnarsi automaticamente a questo canale.
  • --no-self-assign impedisce 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, nessuno.
  • --apikey [key] la chiave API per collegarsi al proprio account.

C'è più di un modo per gestire l'aggiornamento per versioni troppo vecchie.
Capgo non può aggiornare il nativo code quindi un aggiornamento da una versione con il vecchio nativo code a una versione con il nativo aggiornato code non dovrebbe essere possibile. Ci sono un paio di modi per raggiungere questo obiettivo.

Prima, la major strategia. Impedisce l'aggiornamento dalla baseline nativa 0.0.0 -> bundle di destinazione 1.0.0. Il numero maggiore è il numero evidenziato (1.0.0 e 0.0.0).
Seconda è la minor strategia. Impedisce l'aggiornamento quando il bundle di destinazione ha un numero maggiore o minore diverso dalla 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 è raccomandato di utilizzarlo 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 della 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_build, non il bundle scaricato corrente inviato come version_name.

Infine la strategia più complessa. Il metadata strategia.
Innanzitutto devi sapere che inizialmente dopo aver abilitato l'aggiornamento, esso NON andrà a buon fine poiché il canale manca dei dati richiesti.
Se il canale manca dei dati, vedrai un messaggio come questo:

Non è possibile trovare i metadati

Se vedi qualcosa di simile, sai che devi andare al bundle corrente del canale che sta fallendo e impostare i metadati.
Innanzitutto devi capire quale canale sta fallendo. Puoi farlo osservando il bundle corrente del 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 di questo tipo:

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 di 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. In secondo luogo, se la nuova versione è del 100% compatibile riprende 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.

Otterrete sempre informazioni su ciò che è. 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 bundle (code) viene crittografato prima di essere inviato nella cloud e decrittografato sul dispositivo. Per questo, è necessario generare una coppia di chiavi RSA, si può 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

Opzionalmente, 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 il test locale, rimuovi la chiave dal file di configurazione e aggiungila nel passo di integrazione CI con: key save

Salva la chiave nel file di configurazione dell'app

Sezione intitolata “Salva la chiave nel file di configurazione dell'app”

npx @capgo/cli key save

Opzionalmente, 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 far fare all'azione GitHub il lavoro di invio sul nostro server

Tutorial dell'azione GitHub

GitHub - Cap-go/demo-app

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

Se stai utilizzando Comandi per pianificare il dashboard e le operazioni API, connettilo con Panoramica API per i dettagli di implementazione in Panoramica API 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.