Commandes

Cette page est un aperçu guidé. Utilisez la référence de commande actuelle pour les flags exacts : app, bundle, canal, et build.

Utilisation

All command should be run in your app folder with capacitor project ignited properly.

Capacitor Runtime natif multiplateforme pour les applications web

Init

npx @capgo/cli@latest init [apikey]

Cette méthode vous guide pas à pas dans l'onboarding.

Elle ajoutera votre application à Capgo. Elle ajoutera code à votre application pour valider la mise à jour. De même, elle compilera votre application. De plus, elle enverra votre application vers Capgo. Enfin, elle vous aidera à vérifier que la mise à jour fonctionne.

Connexion

npx @capgo/cli login [apikey]

Cette méthode sert à mémoriser le apikey pour vous.

Remarque

utiliser --apikey=******** dans n'importe quelle commande pour le remplacer

En option, vous pouvez fournir :

--local Cela stockera votre clé API dans le repo local et l'ajoutera au .gitignore.

Doctor

npx @capgo/cli doctor

Commande pour vérifier si vos packages Capgo sont à jour.

Cette commande sera également utile pour les rapports de bugs.

cible

Ajoutez

npx @capgo/cli app add [appId]

[appId] votre ID d'application au format com.test.app est expliqué ici.

💡 Si aucune option n'est fournie, elles seront déduites de votre config.

En option, vous pouvez fournir :

• --icon [/path/to/my/icon] pour afficher une icône personnalisée dans l'application web Capgo.
• --name [test] pour avoir un nom personnalisé dans la liste.
• --apikey [key] Clé API pour lier votre compte.
• --retention [retention] période de rétention du bundle de l'app en jours, 0 par défaut = infini.

Exemple de capacitor.config.json pour l'appId et l'AppName, l'icône est détectée dans le dossier resources

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

Définissez

npx @capgo/cli app set [appId]

[appId] est l'ID de votre application, le format est expliqué ici.

En option, vous pouvez fournir :

• --icon [/path/to/my/icon] pour afficher une icône personnalisée dans l'application web Capgo.
• --name [test] pour avoir un nom personnalisé dans la liste.
• --retention [retention] période de rétention du bundle de l'app en jours, 0 par défaut = infini.
• --expose-metadata [true|false] pour exposer les métadonnées du bundle (lien et commentaire) au plugin.
• --preview ou --no-preview pour activer ou désactiver les QR codes de prévisualisation du bundle et du canal.
• --allow-device-custom-id ou --no-allow-device-custom-id pour contrôler les IDs d'appareils personnalisés.
• --block-provider-infra-requests ou --no-block-provider-infra-requests pour contrôler le blocage des requêtes provenant des datacenters Google et Apple.
• --build-timeout-minutes [5-360] pour définir le timeout du Native Build.
• --ios-store-url [url] ou --android-store-url [url] pour définir l'URL du store.
• --default-upload-channel [channel] pour définir le canal d'upload par défaut.
• --default-download-channel [channel] pour définir le canal de téléchargement par défaut, ou --disable-download-channels pour rendre tous les canaux de téléchargement non publics.
• --apikey [key] Clé API pour lier votre compte.

Liste

npx @capgo/cli app list [appId]

[appId] votre ID d'application au format com.test.app est expliqué ici.

En option, vous pouvez fournir :

• --apikey [key] Clé API pour lier votre compte.

Supprimer

npx @capgo/cli app delete [appId]

[appId] votre ID d'application au format com.test.app est expliqué ici.

En option, vous pouvez fournir :

• --apikey [key] Clé API pour lier votre compte.
• --bundle avec le numéro de version ne supprimera que cette version.

Débogage

npx @capgo/cli app debug [appId]

[appId] votre ID d'application au format com.test.app est expliqué ici.

En option, vous pouvez fournir :

• --apikey [key] Clé API pour lier votre compte.
• --device avec l'appareil spécifique que vous souhaitez déboguer

Paramètre

npx @capgo/cli app setting [path]

Modifiez la config Capacitor.

[path] - chemin du paramètre que vous souhaitez modifier. Par exemple, pour changer le appId, fournissez appId. Si vous souhaitez désactiver l'auto update dans le capacitor-updater, fournissez plugins.CapacitorUpdater.autoUpdate par --string off.

Vous DEVEZ fournir soit --string ou --bool!

Options :

• --string <string> - définit le paramètre comme une chaîne
• --bool <true | false> - définit le paramètre comme un booléen

Bundle

Envoyer

npx @capgo/cli bundle upload [appId]

[appId] est l'ID de votre application, le format est expliqué ici.

En option, vous pouvez fournir :

• --apikey <apikey> Clé API pour lier votre compte.
• --path <path> Chemin du dossier à uploader.
• --channel <channel> Channel to link to.
• --external <url> Lien vers une URL externe au lieu d'uploader sur le cloud Capgo.
• --iv-session-key <key> Définit l'IV et la clé de session pour l'URL du bundle externe.
• --s3-endpoint <s3Endpoint> URL du endpoint S3. Ne fonctionne pas avec les uploads delta ou l'option externe.
• --s3-region <region> Région de votre bucket S3.
• --s3-apikey <apikey> Clé API pour votre endpoint S3.
• --s3-apisecret <apisecret> Secret API pour votre endpoint S3.
• --s3-bucket-name <bucketName> Nom de votre bucket AWS S3.
• --s3-port <port> Port pour votre endpoint S3.
• --no-s3-ssl Désactiver le SSL pour l'upload S3.
• --key <key> Chemin personnalisé pour la clé de signature publique (système v1).
• --key-data <keyData> Clé de signature publique (système v1).
• --key-v2 <key> Chemin personnalisé pour la clé de signature privée (système v2).
• --key-data-v2 <keyData> Clé de signature privée (système v2).
• --bundle-url Affiche l'URL du bundle dans la sortie standard.
• --no-key Ignore signing key and send clear update.
• --no-code-check Ignorer la vérification de l'appel à notifyAppReady() dans la source code et la présence de index dans le dossier racine.
• --display-iv-session Affiche dans la console l'IV et la clé de session utilisés pour chiffrer la mise à jour.
• --bundle <bundle> Numéro de version du bundle à envoyer.
• --auto-bump [level] Incrémentation automatique depuis le bundle lié au canal, sinon la dernière version de l'app distante. Niveau : major, minor (par défaut), patch (alias) fix), metadata, ou ai (Workers AI compare les fichiers locaux au manifeste delta Capgo/canal précédent, déduit le niveau et logue une raison courte ; ignore l'IA et incrémente patch si aucune version Capgo précédente n'existe). Incrémente jusqu'à trouver un nom libre (les noms supprimés restent occupés). Ne peut être combiné avec --bundle.
• --min-update-version <minUpdateVersion> Version minimale requise pour passer à cette version. Utilisée uniquement si la désactivation de l'auto-update est définie sur metadata dans le canal.
• --auto-min-update-version Définit la version minimale de mise à jour d'après les packages natifs.
• --ignore-metadata-check Ignore la vérification des métadonnées (node_modules) lors de l'upload.
• --ignore-checksum-check Ignore la vérification du checksum lors de l'upload.
• --timeout <timeout> Délai d'attente du processus d'upload en secondes.
• --delta Envoie les fichiers Delta (manifest) en plus du bundle complet.
• --delta-only Envoie uniquement les mises à jour Delta (manifest), sans le bundle complet.
• --no-delta Désactive l'upload des fichiers Delta (manifest) (utile si le mode instant apply autoUpdate est activé mais que vous souhaitez un bundle complet).
• --tus Envoie le bundle avec le protocole tus.
• --multipart Utilise le protocole multipart pour envoyer les données vers S3. Obsolète, utilisez plutôt TUS.
• --encrypted-checksum <encryptedChecksum> Un checksum chiffré (signature). Utilisé uniquement lors de l'upload d'un bundle externe.
• --package-json <packageJson> Un chemin vers le package.json. Utile pour les monorepos.
• --auto-set-bundle Définit le bundle dans capacitor.config.json.
• --node-modules <nodeModules> Une liste de chemins vers node_modules. Utile pour les monorepos (séparés par des virgules, ex : ../../node_modules,./node_modules)

⭐️ L'option External aide à débloquer 2 cas : les entreprises avec des enjeux de confidentialité (ne pas envoyer le code à un tiers) et les apps de plus de 200 Mo. Avec ce réglage, Capgo ne stocke que le lien vers le zip et envoie ce lien à toutes les apps.

👀 Le cloud Capgo ne consulte jamais le contenu du lien (pour l'option External), ni celui de code lors du stockage.

🔑 Vous pouvez ajouter une seconde couche de sécurité en utilisant le chiffrement : Capgo ne pourra alors ni consulter ni modifier quoi que ce soit, ce qui rend le système « trustless ».

Exemple de package.json pour la version

{
  "version": "1.0.2"
}

⛔ La version doit être supérieure à « 0.0.0 ».

💡 N'oubliez pas de mettre à jour le numéro de version à chaque envoi ; pour des raisons de sécurité, un numéro de version ne peut pas être écrasé ou réutilisé après suppression.

Liste

npx @capgo/cli bundle list [appId]

[appId] votre ID d'application au format com.test.app est expliqué ici.

En option, vous pouvez fournir :

• --apikey [key] Clé API pour lier votre compte.

Supprimer

npx @capgo/cli bundle delete [appId]

[appId] votre ID d'application au format com.test.app est expliqué ici.

En option, vous pouvez fournir :

• --apikey [key] Clé API pour lier votre compte.
• --bundle avec le numéro de version ne supprimera que cette version.

Nettoyage

dans une plage SemVer pour une version majeure vers le cloud

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

[appId] votre ID d'application au format com.test.app est expliqué ici.

En option, vous pouvez fournir :

• --apikey [key] Clé API pour lier votre compte.
• --bundle [majorVersion] une version pour laquelle vous souhaitez supprimer les packages précédents ; il conservera la dernière + numberToKeep.
• --keep [numberToKeep] le nombre de packages que vous souhaitez conserver (par défaut 4).

Par exemple : si vous avez 10 versions de 10.0.1 à 10.0.11, et que vous utilisez npx @capgo/cli cleanup [appId] --bundle=10.0.0 il supprimera les versions 10.0.1 à 10.0.6. Celles de 10.0.7 à 10.0.11 seront conservées.

Si vous avez 20 versions au total et que vous n'indiquez pas de numéro de bundle comme ceci : npx @capgo/cli cleanup [appId] --keep=2 Il supprimera 18 versions et conservera les 2 dernières.

Cette commande demandera une confirmation et affichera un tableau des éléments conservés et de ceux qui seront supprimés.

Remarque

Cette commande ignorera les bundles actuellement utilisés dans un canal.

Chiffrer

Attention : Cette commande est obsolète et sera supprimée lors de la prochaine version majeure. Veuillez utiliser le nouveau système de chiffrement. npx @capgo/cli bundle encrypt [path/to/zip]

Cette commande est utilisée lorsque vous utilisez une source externe pour stocker votre code ou à des fins de test.

En option, vous pouvez fournir :

--key [/path/to/my/private_key] le chemin de votre clé privée. --key-data [privateKey] les données de la clé privée, si vous souhaitez une utilisation inline. La commande affichera votre ivSessionKeyy et générera un zip chiffré, à utiliser avec la commande upload ou la commande decrypt.

Chiffrement V2

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

Cette commande est utilisée lorsque vous utilisez une source externe pour stocker votre code ou à des fins de test. Le checksum est le sha256 du bundle (généré par —key-v2), il sert à vérifier l'intégrité du fichier après déchiffrement. Il sera chiffré avec la clé privée et envoyé avec le bundle. Dans le chiffrement v2, le checksum devient une « signature » du bundle.

En option, vous pouvez fournir :

--key [/path/to/my/private_key] le chemin de votre clé privée. --key-data [privateKey] les données de la clé privée, si vous souhaitez les utiliser inline. --json pour afficher les infos en json. La commande affichera votre ivSessionKeyy et générera un zip chiffré, à utiliser avec la commande upload ou la commande decrypt.

Déchiffrer

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

En option, vous pouvez fournir :

--key [/path/to/my/private_key] le chemin de votre clé privée.

--key-data [privateKey] les données de la clé privée, si vous souhaitez utiliser l'option inline. Cette commande est principalement utilisée à des fins de test : elle déchiffre le zip et affiche la clé de session déchiffrée en base64 dans la console.

Déchiffrer V2

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

En option, vous pouvez fournir :

--key [/path/to/my/private_key] le chemin de votre clé privée. --key-data [privateKey] les données de la clé privée, si vous souhaitez utiliser l'option inline. Cette commande est principalement utilisée à des fins de test : elle déchiffre le zip et affiche la clé de session déchiffrée en base64 dans la console. --checksum [checksum] le checksum du fichier ; il vérifiera le checksum après le déchiffrement.

Zipper

npx @capgo/cli bundle zip [appId]

[appId] est l'ID de votre application, le format est expliqué ici.

En option, vous pouvez fournir :

• --path [/path/to/my/bundle] pour envoyer un dossier spécifique.
• --bundle [1.0.0] pour définir le numéro de version du bundle dans le nom du fichier.
• --name [myapp] pour remplacer le nom du fichier.
• --json pour afficher les informations au format JSON.
• --no-code-check pour ignorer la vérification code et envoyer le bundle quand même.
• --key-v2 pour utiliser le nouveau système de chiffrement. Cela est requis car le nouveau système utilise de meilleurs checksums pour vérifier l'intégrité du fichier.

Compatibilité

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

[appId] est l'ID de votre application, le format est expliqué ici. [channelName] le nom du canal à vérifier.

En option, vous pouvez fournir :

• --apikey [key] Clé API pour lier votre compte.
• --text utilisez du texte plutôt que des emojis dans le tableau
• --channel [channel] le canal avec lequel vérifier la compatibilité.
• --package-json <packageJson> Un chemin vers le package.json. Utile pour les monorepos
• --node-modules <nodeModules> Une liste de chemins vers node_modules. Utile pour les monorepos (séparés par des virgules, ex : ../../node_modules,./node_modules)

Canal

Ajoutez

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

[channelName] le nom de votre nouveau canal, par exemple production ou beta. [appId] votre ID d'application au format com.test.app est expliqué ici.

Supprimer

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

[channelName] le nom du canal que vous souhaitez supprimer. [appId] votre ID d'application au format com.test.app est expliqué ici.

Liste

npx @capgo/cli channel list [appId]

[appId] votre ID d'application au format com.test.app est expliqué ici.

En option, vous pouvez fournir :

• --apikey [key] Clé API pour lier votre compte.

Définissez

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

[appId] est l'ID de votre application, le format est expliqué ici. [channelName] le nom du canal que vous souhaitez configurer, comme production ou beta.

En option, vous pouvez fournir :

• --bundle [1.2.3] le bundle de votre application déjà envoyé sur le cloud, pour le lier à un canal.
• --latest récupérer la version du bundle depuis package.json:version, ne peut pas être utilisé avec --bundle.
• --state [ normal | default ] définit l'état du canal, peut être normal ou default. Un canal doit être default.
• --downgrade autorise le canal à envoyer une version antérieure aux appareils.
• --no-downgrade interdit au canal d'envoyer une version antérieure aux appareils.
• --upgrade autorise le canal à envoyer une version supérieure (majeure) aux appareils.
• --no-upgrade interdit au canal d'envoyer une version supérieure (majeure) aux appareils.
• --ios autorise le canal à envoyer la version aux appareils iOS.
• --no-ios interdit au canal d'envoyer la version aux appareils iOS.
• --android autorise le canal à envoyer la version aux appareils Android.
• --no-android interdit au canal d'envoyer la version aux appareils Android.
• --self-assign permet aux appareils de s'assigner automatiquement à ce canal.
• --no-self-assign empêche les appareils de s'assigner automatiquement à ce canal.
• --disable-auto-update STRATEGY Désactive la stratégie de mise à jour automatique pour ce canal. Les options possibles sont : major, minor, patch, metadata, none.
• --apikey [key] Clé API pour lier votre compte.

Désactiver la stratégie de mise à jour

Il existe plusieurs façons de désactiver les mises à jour pour les versions trop anciennes.
Capgo ne peut pas mettre à jour le code natif ; ainsi, une mise à jour d'une version avec l'ancien code natif vers une version avec le code natif mis à jour ne devrait pas être possible. Il existe plusieurs méthodes pour y parvenir.

Premièrement, la major stratégie. Elle empêche une mise à jour depuis le baseline natif 0.0.0 -> bundle cible 1.0.0. Le chiffre major est le nombre mis en évidence (1.0.0 et 0.0.0).
La seconde est la minor stratégie. Elle empêche une mise à jour si le bundle cible possède une version major ou minor différente de la base native de l'appareil, comme 0.0.0 -> 1.1.0 ou 1.1.0 -> 1.2.0.

Troisièmement, la patch stratégie. Elle a été ajoutée à capgo comme un mode très strict. Il n'est pas recommandé de l'utiliser à moins de comprendre parfaitement son fonctionnement. Pour qu'une mise à jour soit acceptée, les conditions suivantes doivent être remplies :

• La version major est identique entre le bundle cible et version_build
• La version minor est identique entre le bundle cible et version_build
• La version patch est identique entre le bundle cible et version_build
• Seul le suffixe de version peut différer, comme une version de pré-release ("-beta.2") ou des métadonnées de build ("+build.2)

Voici un exemple des scénarios où la mise à jour est autorisée ou refusée

• 1.0.0-beta.1 -> 1.0.0-beta.2 autorisé
• 1.0.0+build.1 -> 1.0.0+build.2 autorisé
• 1.0.0 -> 1.0.1 bloqué
• 1.0.0 -> 1.1.0 bloqué
• 1.0.0 -> 2.0.0 bloqué

La comparaison de stratégie utilise la baseline native envoyée comme version_build, et non au bundle actuellement téléchargé envoyé en version_name.

Enfin, la stratégie la plus complexe. La metadata stratégie.
Sachez tout d'abord qu'une fois activées, les mises à jour SERA échouent car le canal manque des métadonnées requises.
Si le canal manque de métadonnées, vous verrez un message comme celui-ci :

Si vous voyez un message de ce type, vous devez accéder au bundle actuel du canal concerné pour définir les métadonnées.
Tout d'abord, identifiez le canal qui pose problème. Vous pouvez le faire en consultant les misconfigured colonne

Ensuite, allez sur le canal concerné et cliquez sur Bundle number. Cela devrait vous rediriger vers la page du bundle.

Une fois sur place, remplissez le champ Minimal update version . Il doit s'agir d'un semver.
Si la valeur que vous passez n'est pas un semver, vous obtiendrez une erreur, mais si tout se passe bien, vous devriez voir quelque chose comme ceci :

Maintenant, vous ne voudrez probablement pas saisir ces données manuellement à chaque mise à jour. Heureusement, CLI vous empêchera d'envoyer une mise à jour sans ces métadonnées

Pour envoyer correctement un bundle en utilisant l'option metadata vous devez passer le --min-update-version avec le semver valide. Quelque chose comme ceci :

Le --min-update-version n'est pas la SEULE façon de gérer la compatibilité. Il existe également le --auto-min-update-version. Voici comment ça marche.

D'abord, il examine la version actuellement uploadée sur le canal. Il vérifie la compatibilité de la même manière que la bundle compatibility commande. Ensuite, si la nouvelle version est compatible à 100 %, il réutilise le min_update_version de la dernière version du canal. Sinon, il définit le min_update_version sur le numéro de bundle de la version nouvellement uploadée.

Vous saurez toujours quelle est la min_update_version lorsque vous utilisez cette option. Voici à quoi cela ressemblera :

Si la nouvelle version n'est pas compatible, cela devrait ressembler à ceci :

Chiffrement de bout en bout (Trustless)

Capgo prend en charge le chiffrement de bout en bout, ce qui signifie que votre bundle (code) est chiffré avant d'être envoyé vers le cloud et déchiffré sur l'appareil. Pour cela, vous devez générer une paire de clés RSA ; vous pouvez utiliser la commande suivante pour la générer.

Le système de chiffrement combine RSA et AES : la clé RSA sert à chiffrer la clé AES, et la clé AES est utilisée pour chiffrer le fichier.

Consultez la suite pour plus d'informations sur le système de chiffrement.

Schéma de chiffrement

Créer une clé pour votre app

npx @capgo/cli key create

En option, vous pouvez fournir : --force pour écraser la clé existante. Cette commande créera une paire de clés pour votre app et vous demandera de sauvegarder la clé privée dans un endroit sûr. Il est recommandé de ne pas commiter la clé privée sur Git et de ne la partager avec personne.

Après vos tests locaux, retirez la clé du fichier de config et ajoutez-l’à l'étape CI avec key save

Sauvegarder la clé dans la config de votre app

npx @capgo/cli key save

En option, vous pouvez fournir :

--key [/path/to/my/public_key] le chemin de votre fichier de clé publique.

--key-data [publicKey] les données de la clé publique, si vous souhaitez une utilisation inline. Cette commande est utile si vous avez suivi la recommandation de ne pas commiter la clé dans la config de votre app.

Intégration CI

Pour automatiser votre travail, je vous recommande de configurer une action GitHub pour envoyer les données vers notre serveur

Tutoriel sur l'action GitHub

Notre app de démo

GitHub - Cap-go/demo-app

N'oubliez pas de configurer la variable d'env CI avec votre clé API

Continuer depuis Commands

Si vous utilisez Commandes pour planifier les opérations du dashboard et de API, connectez-l’avec Aperçu de API pour les détails d'implémentation dans « Vue d'ensemble de API », Introduction pour les détails d'implémentation dans l'introduction, Clés API pour les détails d'implémentation dans API Keys, Appareils pour les détails d'implémentation dans Devices, et Les bundles pour les détails d'implémentation dans Bundles.