Saltare al contenuto

Comandi

Questa pagina è un'introduzione guidata. Utilizzare la riferimento delle attuali command per flag esatti: app, bundle, canale, e costruire.

All 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 aiuterà a verificare se l'aggiornamento funziona.

npx @capgo/cli login [apikey]

Questo metodo è qui per ricordare il apikey per te

Facoltativamente puoi dare:

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

npx @capgo/cli doctor

Comando per verificare se sei aggiornato con i pacchetti Capgo.

Questo comando sarà anche utile per i report 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] avere un'icona personalizzata visualizzata nel Capgo app web.
  • --name [test] per avere un nome personalizzato nella lista.
  • --apikey [key] la chiave API per collegarti al 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 nella cartella risorse

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

npx @capgo/cli app set [appId]

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

Facoltativamente, puoi dare:

  • --icon [/path/to/my/icon] avere un'icona personalizzata visualizzata nel Capgo web app.
  • --name [test] per avere un nome personalizzato nella lista.
  • --retention [retention] periodo di conservazione del bundle dell'applicazione in giorni, 0 di default = infinito.
  • --expose-metadata [true|false] per esporre i metadati del bundle (link e commento) al plugin.
  • --preview o --no-preview abilitare o disabilitare la visualizzazione dei codici QR per bundle e 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 gli ID dei dispositivi personalizzati.
  • --build-timeout-minutes [5-360] Impostare il timeout di costruzione nativa.
  • --ios-store-url [url] o --android-store-url [url] per impostare il timeout di costruzione nativa.
  • --default-upload-channel [channel] per impostare l'URL del negozio.
  • --default-download-channel [channel] per impostare il canale di upload predefinito. --disable-download-channels per impostare il canale di download predefinito, o
  • --apikey [key] tasto API per collegarsi al tuo account.

npx @capgo/cli app list [appId]

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

Opzionalmente, puoi fornire:

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

npx @capgo/cli app delete [appId]

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

Opzionalmente, puoi fornire:

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

npx @capgo/cli app debug [appId]

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

Opzionalmente, puoi fornire:

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

npx @capgo/cli app setting [path]

Modifica il Capacitor config.

[path] - percorso dell'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 uno dei seguenti --string o --bool!

Options:

  • --string <string> - imposta la impostazione su una stringa
  • --bool <true | false> imposta la impostazione su un booleano

npx @capgo/cli bundle upload [appId]

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

Se lo desideri, puoi fornire:

  • --apikey <apikey> chiave API per collegarsi al tuo account.
  • --path <path> Percorso della cartella da caricare.
  • --channel <channel> Canale da collegare.
  • --external <url> Collega all'URL esterno al posto di caricare su Capgo Cloud.
  • --iv-session-key <key> Imposta l'IV e la chiave di sessione per l'URL del bundle esterno.
  • --s3-endpoint <s3Endpoint> URL del punto di accesso S3. Non funziona con le condivisioni delta o l'opzione esterna.
  • --s3-region <region> Regione per il tuo bucket S3.
  • --s3-apikey <apikey> API chiave per il tuo punto di accesso S3.
  • --s3-apisecret <apisecret> API segreto per il tuo punto di accesso S3.
  • --s3-bucket-name <bucketName> Nome per il tuo bucket S3 AWS.
  • --s3-port <port> Porta per il tuo punto di accesso 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 in chiaro.
  • --no-code-check Ignora la verifica se notifyAppReady() è chiamato nel file code e l'indice presente nella cartella radice.
  • --display-iv-session Mostra nella console la chiave di sessione e IV utilizzati per cifrare l'aggiornamento.
  • --bundle <bundle> Numero di versione del bundle da caricare.
  • --auto-bump [level] Auto-incrementa dal bundle collegato del canale, altrimenti la versione app più recente remota. Livello: major, minor (predefinito) patch (alias) fix), metadata, o ai (I Workers confrontano i file locali con il manifesto delta precedente Capgo/canale, inferiscono il livello e registrano una breve ragione; saltano l'AI e aumentano patch se non esiste una versione precedente Capgo. Aumenta fino a quando non viene trovato un nome libero (i nomi eliminati restano occupati). Non può essere combinato con --bundle.
  • --min-update-version <minUpdateVersion> Versione minima richiesta per aggiornarsi a questa versione. Utilizzato solo se l'aggiornamento automatico è disabilitato nel 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 l'upload.
  • --ignore-checksum-check Ignora il controllo 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 le pubblicazioni Delta (manifesto) (utile se si applica immediatamente autoUpdate Carica il bundle utilizzando il protocollo tus.
  • --tus Carica il bundle utilizzando il protocollo tus.
  • --multipart Un checksum crittografato (firma). Utilizzato solo quando si carica un bundle esterno.
  • --encrypted-checksum <encryptedChecksum> Un checksum crittografato (firma). Utilizzato solo quando si carica un bundle esterno.
  • --package-json <packageJson> Imposta il bundle in __CAPGO_KEEP_0__.config.json.
  • --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 inviano il code a una terza parte e applicazioni più grandi di 200 MB. Con questa impostazione, Capgo archivia 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 archiviato.

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

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.

Facoltativamente, puoi fornire:

  • --apikey [key] API chiave per collegare il 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] API chiave per collegare il tuo account.
  • --bundle con il numero di versione eliminerà solo questa versione.

per una versione maggiore in un intervallo SemVer per Cloud

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

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

Facoltativamente, puoi fornire:

  • --apikey [key] API chiave per collegare al tuo account.
  • --bundle [majorVersion] per la versione che desideri rimuovere, le precedenti pacchetti verranno mantenuti, tranne l'ultimo. numberToKeep.
  • --keep [numberToKeep] il numero di pacchetti che desideri mantenere (predefinito 4).

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 sarà mantenuto.

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 comando chiederà conferma, mostra una tabella di cosa verrà mantenuto e rimosso.

Attenzione: Questa operazione è deprecata e verrà rimossa nella prossima versione maggiore. Utilizza il nuovo sistema di crittografia. npx @capgo/cli bundle encrypt [path/to/zip]

Questa operazione viene utilizzata 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 via del tuo chiave privata. --key-data [privateKey] i dati della chiave privata, se desideri utilizzarli inline. La riga di comando stampa i tuoi ivSessionKeyy e generare un file zip crittografato, per utilizzarlo 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), utilizzato per verificare l'integrità del file dopo la decrittografia. Verrà crittografato con la chiave privata e inviato insieme al bundle. Nell'encryption v2 il checksum viene aggiornato per diventare una “firma” del bundle.

Facoltativamente, puoi fornire:

--key [/path/to/my/private_key] la via del tuo chiave privata. --key-data [privateKey] i dati della chiave privata, se desideri utilizzarli inline. --json per outputtare le informazioni in formato json. Il comando stampa i ivSessionKeyy e generare un file zip crittografato, per utilizzarlo con il comando di caricamento o il comando di decrittografia.

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

Opcionalmente, puoi fornire:

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

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

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

Opcionalmente, puoi fornire:

--key [/path/to/my/private_key] la via del tuo chiave privata. --key-data [privateKey] la chiave privata, se desideri utilizzare inline. Questo comando è principalmente utilizzato per scopi di test, decrittograferà il zip e stampa la chiave di sessione base64 decrittografata nella console. --checksum [checksum] il checksum del file, verrà verificato il checksum dopo la decrittografia.

npx @capgo/cli bundle zip [appId]

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

Opcionalmente, puoi dare:

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

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

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

Facoltativamente, puoi fornire:

  • --apikey [key] API chiave 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> 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 nome del tuo nuovo canale, ad esempio com.test.app è spiegato here.

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

[channelName] il nome del canale che desideri cancellare [appId] il nome del tuo nuovo canale, ad esempio com.test.app è spiegato here.

npx @capgo/cli channel list [appId]

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

Facoltativamente, potete dare:

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

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

[appId] E' il tuo ID app, il formato è spiegato qui. [channelName] è il vostro ID applicazione, il formato è spiegato production or beta.

Opzionalmente, puoi fornire:

  • --bundle [1.2.3] il tuo bundle di app già inviato al 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 defaultUn canale deve essere default.
  • --downgrade disabilita il canale a inviare versioni di downgrade ai dispositivi.
  • --no-downgrade abilita il canale a inviare versioni di downgrade ai dispositivi.
  • --upgrade abilita il canale a inviare versioni di aggiornamento (maggiore) ai dispositivi.
  • --no-upgrade disabilita il canale a inviare versioni di aggiornamento (maggiore) ai dispositivi.
  • --ios abilita il canale a inviare versioni ai dispositivi iOS.
  • --no-ios impedisce al canale di inviare la versione ai dispositivi iOS.
  • --android consente al canale di inviare la versione ai dispositivi Android.
  • --no-android impedisce al canale di inviare la versione ai dispositivi Android.
  • --self-assign allows devices to self assign to this channel.
  • --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: major, minor, patch, metadata, none.
  • --apikey [key] chiave API per collegarsi al proprio account.

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

Prima, il major La strategia. Evita 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).
Secondo è il minor La strategia. Evita un aggiornamento quando il bundle di destinazione ha un numero maggiore o minore diverso dal baseline nativo del dispositivo, ad esempio 0.0.0 -> 1.1.0 o 1.1.0 -> 1.2.0.

Terzo, il patch La strategia. È stata aggiunta in capgo come modalità molto rigorosa. Non è consigliato utilizzarla a meno che non si comprenda completamente come funziona. Per accettare un aggiornamento, le seguenti condizioni devono essere soddisfatte:

  • Il numero maggiore è lo stesso tra il bundle di destinazione e version_build
  • Il numero minore è lo stesso tra il bundle di destinazione e version_build
  • Il numero di patch è lo stesso tra il bundle di destinazione e version_build
  • Solo la suffice 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_build, non il bundle scaricato corrente inviato come version_name.

Infine la strategia più complessa. La metadata strategia.
Innanzitutto devi sapere che inizialmente dopo aver abilitato le aggiornamenti WILL falliranno poiché il canale manca dei dati richiesti per il metadata.
Se il canale manca dei dati di metadata vedrai un messaggio come questo:

Non è stato trovato il metadati

Se vedi qualcosa di questo tipo sai che devi andare alla corrente bundle per il canale che sta fallendo e impostare i dati di metadata.
Risolvere il problema inizia con l'identificare il canale che non funziona. Puoi farlo esaminando misconfigured column

Tavola configurata in modo errato

Questo dovrebbe portarti alla pagina del bundle. Bundle numberIdentifica il canale che sta fallendo

Trova il canale che fallisce

Una volta riempite il Minimal update version Questo dovrebbe essere un semver.
Se il valore che passate non è un semver otterrete un errore, ma se tutto va bene dovreste vedere qualcosa di questo tipo:

Imposta versione minima

Ora, probabilmente non desiderate impostare manualmente questo dato ogni volta che aggiornate. Fortunatamente, il CLI vi impedirà di inviare un aggiornamento senza questo metadati

CLI fallito senza metadati

Per caricare correttamente un bundle quando si utilizza l' metadata opzione è necessario passare il --min-update-version con il semver validoqualcosa di questo tipo:

CLI caricamento con metadati

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

Prima, si guarda la versione attualmente caricata sul canale. Verifica la compatibilità allo stesso modo del bundle compatibility comando. Secondo, se la nuova versione è del 100% compatibile, riprende il min_update_version dal numero di versione più recente nel canale. Se non, allora imposta il min_update_version al numero del pacchetto della versione appena caricata.

Otterrai sempre un messaggio che ti informa su cosa è il min_update_version quando utilizzi questa opzione. Assomiglierà a questo:

Minima versione di aggiornamento

Se la nuova versione non è compatibile dovrebbe assomigliare a questo

Minima versione di aggiornamento non compatibile

Capgo supporta la crittografia end-to-end, il che significa che il tuo pacchetto (code) viene crittografato prima di essere inviato in cloud e decrittografato sul dispositivo. Per questo, è necessario 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.

Vedi di seguito per ulteriori informazioni sul sistema di crittografia.

Come funziona la crittografia

Schema di crittografia

npx @capgo/cli key create

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

Dopo il tuo test locale, rimuovi la chiave dal file di configurazione e aggiungila nel passo di CI con key save

Salva la chiave nella configurazione del tuo app

Salva chiave nella configurazione dell'app

npx @capgo/cli key save

Facoltativamente, puoi fornire:

--key [/path/to/my/public_key] il percorso del tuo file di 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 commesso la chiave nella configurazione del tuo app.

Per automatizzare il tuo lavoro, ti consiglio di fare l'azione GitHub eseguire il lavoro di invio sul nostro server

Tutorial dell'azione GitHub

GitHub - Cap-go/demo-app

Dimentica di configurare l'ambiente di integrazione 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 il dettaglio di implementazione in API Chiavi, Dispositivi per i dettagli di implementazione nei dispositivi, e Bundles per i dettagli di implementazione nei Bundle.