Commandes

Cette page est une vue d'ensemble guidée. Utilisez la référence de commande actuelle pour les flags exacts : app, bundle, canal, et build.

Utilisation

Toutes les commandes doivent être exécutées dans le dossier de votre application avec le projet capacitor allumé correctement.

Capacitor Exécution native croisée pour les applications web

Init

npx @capgo/cli@latest init [apikey]

Cette méthode est conçue pour vous guider étape par étape.

Elle ajoutera votre application à Capgo. Elle ajoutera le code à votre application pour valider la mise à jour. De même, elle construira votre application. De plus, elle téléchargera votre application sur Capgo. Et elle vous aidera à vérifier si la mise à jour fonctionne.

Connexion

npx @capgo/cli login [apikey]

Cet élément est conservé pour rappeler le apikey pour vous.

Remarque

utilisez --apikey=******** dans toute commande pour la remplacer

Vous pouvez optionnellement fournir :

--local Cela stockera votre clé d'API dans le dépôt local et l'ignorera dans Git.

Docteur

npx @capgo/cli doctor

Commande pour vérifier si vous êtes à jour avec les Capgo paquets.

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

Application

Ajouter

npx @capgo/cli app add [appId]

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

Tout les options seront devinées dans votre configuration si elles ne sont pas fournies.

Vous pouvez également donner :

• --icon [/path/to/my/icon] to have a custom icon display in Capgo web app.
• --name [test] avoir un nom personnalisé dans la liste.
• --apikey [key] clé API pour vous connecter à votre compte.
• --retention [retention] Durée de conservation du bundle d'application en jours, 0 par défaut = infini.

Exemple de capacitor.config.json pour appId et AppName, l'icône est déduite dans le dossier des ressources

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

Configurer

npx @capgo/cli app set [appId]

[appId] est votre ID d'application, la forme est expliquée ici.

Optionnellement, vous pouvez fournir :

• --icon [/path/to/my/icon] to have a custom icon display in Capgo web app.
• --name [test] pour avoir un nom personnalisé dans la liste.
• --retention [retention] la durée de conservation du bundle d'application 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 Activer ou désactiver les codes QR de prévisualisation du bundle et du canal.
• --allow-device-custom-id ou --no-allow-device-custom-id pour contrôler les identifiants de dispositif personnalisés.
• --block-provider-infra-requests ou --no-block-provider-infra-requests Contrôler le blocage des requêtes de centres de données Google et Apple connus.
• --build-timeout-minutes [5-360] pour définir le temps d'attente de la construction native.
• --ios-store-url [url] ou --android-store-url [url] pour définir l'URL de la boutique.
• --default-upload-channel [channel] Définir le canal de téléchargement par défaut.
• --default-download-channel [channel] pour rendre tous les canaux de téléchargement non publics. --disable-download-channels rendre tous les canaux de téléchargement non publics.
• --apikey [key] API clé pour se connecter à votre compte.

Liste

npx @capgo/cli app list [appId]

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

Optionnellement, vous pouvez fournir :

• --apikey [key] API clé pour se connecter à votre compte.

Supprimer

npx @capgo/cli app delete [appId]

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

Vous pouvez optionnellement fournir :

• --apikey [key] API clé pour se connecter à votre compte.
• --bundle Avec le numéro de version, seuls cette version sera supprimée.

Débogage

npx @capgo/cli app debug [appId]

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

Vous pouvez optionnellement fournir :

• --apikey [key] API clé pour se connecter à votre compte.
• --device sur le dispositif spécifique que vous souhaitez déboguer

Paramètres

npx @capgo/cli app setting [path]

Éditez la configuration du Capacitor.

[path] - Chemin du paramètre que vous souhaitez modifier. Par exemple, pour modifier le appId, fournissez appIdSi vous souhaitez désactiver la mise à jour automatique dans le capacitor-updater, fournissez plugins.CapacitorUpdater.autoUpdate avec --string off.

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

Options :

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

Bundle

Télécharger

npx @capgo/cli bundle upload [appId]

[appId] c'est votre ID d'application, la forme est expliquée ici.

Optionnellement, vous pouvez donner :

• --apikey <apikey> API clé pour se connecter à votre compte.
• --path <path> Chemin du dossier à télécharger.
• --channel <channel> Chaîne à relier.
• --external <url> Lier à une URL externe au lieu de télécharger sur Capgo Cloud.
• --iv-session-key <key> Configurez l'IV et la clé de session pour l'URL du bundle externe.
• --s3-endpoint <s3Endpoint> URL de l'endpoint S3. Ne fonctionne pas avec les téléchargements delta ou l'option externe.
• --s3-region <region> Région pour votre bac 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 bac S3 AWS.
• --s3-port <port> Port pour votre endpoint S3.
• --no-s3-ssl Désactiver 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 Vérifiez si notifyAppReady() est appelé dans le source code et si l'index est présent dans le dossier racine.
• --display-iv-session Affiche dans la console les clés IV et de session utilisées pour chiffrer la mise à jour.
• --bundle <bundle> Numéro de version du bundle à télécharger.
• --auto-bump [level] Niveau : auto-incrémentation à partir de la version de l'application liée au canal, sinon la dernière version distante. major, minor (par défaut), patch (alias) fix), metadata, ou ai Le Workers AI compare les fichiers locaux avec le précédent Capgo/canal delta manifest, infère le niveau et affiche une brève raison ; saute l'IA et augmente patch Si aucun précédent Capgo n'est trouvé). Augmente jusqu'à trouver un nom libre (les noms supprimés restent occupés). Ne peut pas être combiné avec --bundle.
• --min-update-version <minUpdateVersion> Version minimale requise pour mettre à jour vers cette version. Utilisé uniquement si la mise à jour automatique est désactivée dans le canal.
• --auto-min-update-version Définir la version minimale d'actualisation en fonction des packages natifs.
• --ignore-metadata-check Igore la vérification des métadonnées (node_modules) lors de l'upload.
• --ignore-checksum-check Igore la vérification du checksum lors de l'upload.
• --timeout <timeout> Temps d'attente pour le processus d'upload en secondes.
• --delta Upload les fichiers Delta (manifest) aux côtés du bundle complet.
• --delta-only Upload uniquement les mises à jour Delta (manifest), en ignorant le bundle complet.
• --no-delta Désactive les téléchargements de Delta (manifeste) (utile si un appliquer instantané) autoUpdate Upload le bundle en utilisant le protocole tus.
• --tus Téléchargez le bundle en utilisant le protocole tus.
• --multipart Un checksum chiffré (signature). Utilisé uniquement lors de l'upload d'un bundle externe.
• --encrypted-checksum <encryptedChecksum> Une somme chiffrée (signature) cryptée. Utilisée uniquement lors de l'upload d'un bundle externe.
• --package-json <packageJson> Un chemin vers package.json. Utile pour les monorepos.
• --auto-set-bundle Définir 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 par exemple : ../../node_modules,./node_modules)

⭐️ L'option externe permet d'activer 2 cas : les entreprises avec des préoccupations de confidentialité, ne pas envoyer le code à un tiers et les applications plus grandes que 200 MB. Avec cette configuration, Capgo stocke uniquement le lien vers le zip et envoie le lien à toutes les applications.

👀 Capgo ne consulte jamais ce qui se trouve dans le lien (pour option externe), ou dans le code lorsqu'il est stocké.

🔑 Vous pouvez ajouter une deuxième couche de sécurité en utilisant l'encryption, puis Capgo ne pourra pas regarder ou modifier quoi que ce soit, il devient « sans confiance ».

Exemple de package.json pour 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 fois que vous envoyez un, le numéro de version ne peut pas être surchargé ou réutilisé après suppression pour des raisons de sécurité.

Liste

npx @capgo/cli bundle list [appId]

[appId] l'ID de votre application sous la forme com.test.app est expliqué ici.

Optionnellement, vous pouvez fournir :

• --apikey [key] API clé pour se connecter à votre compte.

Supprimer

npx @capgo/cli bundle delete [appId]

[appId] l'ID de votre application sous la forme com.test.app est expliqué ici.

Optionnellement, vous pouvez fournir :

• --apikey [key] API clé pour se connecter à votre compte.
• --bundle avec le numéro de version, seuls supprimera cette version.

Nettoyage

dans une plage SemVer pour une version majeure vers Cloud

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

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

Optionnellement, vous pouvez donner :

• --apikey [key] API clé pour se connecter à votre compte.
• --bundle [majorVersion] une version que vous souhaitez supprimer les packages précédents pour, il gardera le dernier + numberToKeep.
• --keep [numberToKeep] le nombre de packages que vous souhaitez garder (par défaut 4).

Par exemple : Si vous avez 10 versions de 10.0.1 à 10.0.11, et vous utilisez npx @capgo/cli cleanup [appId] --bundle=10.0.0 Il supprimera 10.0.1 à 10.0.6. 10.0.7 à 10.0.11 sera conservé.

Si vous avez 20 versions au total, et que vous n'avez pas fourni un 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 confirmation, elle affichera une table de ce qui sera conservé et supprimé.

Remarque

Cette commande ignorera les bundles qui sont actuellement en cours d'utilisation dans n'importe quel canal.

Chiffrer

WarningCette commande est utilisée lorsque vous utilisez une source externe pour stocker votre __CAPGO_KEEP_0__ ou à des fins de test. 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.

Vous pouvez également fournir :

--key [/path/to/my/private_key] le chemin de votre clé privée. --key-data [privateKey] vos données de clé privée, si vous souhaitez utiliser une méthode inline. La commande imprime vos ivSessionKeyy et génère un zip chiffré, afin de l'utiliser avec la commande d'upload ou de déchiffrement.

Chiffrer 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. La checksum est le sha256 du bundle (généré par —key-v2), elle est utilisée pour vérifier l'intégrité du fichier après déchiffrement. Elle sera chiffrée avec la clé privée et envoyée avec le bundle. Dans l'encryption v2, la checksum est améliorée pour devenir une « signature » du bundle.

Vous pouvez également 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 l'utiliser en ligne. --json pour afficher les informations sous forme de json. La commande imprime vos ivSessionKeyy et génère un zip chiffré, afin de l'utiliser avec la commande d'upload ou de déchiffrement.

Déchiffrer

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

Vous pouvez optionnellement 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 l'utiliser inline. Cette commande est principalement utilisée à des fins de test, elle déchiffre le zip et imprime la clé de session déchiffrée en base64 dans la console.

Déchiffrer V2

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

Vous pouvez optionnellement 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 l'utiliser inline. Cette commande est principalement utilisée à des fins de test, elle déchiffre le zip et imprime 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 déchiffrement.

Zip

npx @capgo/cli bundle zip [appId]

[appId] est votre ID d'application, la forme est expliquée ici.

Optionnellement, vous pouvez donner :

• --path [/path/to/my/bundle] pour télécharger un dossier spécifique.
• --bundle [1.0.0] fixer le numéro de version du bundle du fichier.
• --name [myapp] pour définir le nom du fichier.
• --json pour afficher les informations sous forme de 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 cryptage. Cela est requis car le nouveau système de cryptage utilise des sommes de contrôle meilleures pour vérifier l'intégrité du fichier.

Compatibilité

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

[appId] est votre ID d'application, la forme est expliquée ici. [channelName] le nom du canal à vérifier.

Optionnellement, vous pouvez donner :

• --apikey [key] API clé pour se connecter à votre compte.
• --text utilisez du texte au lieu d'émoticônes dans le tableau
• --channel [channel] le canal à vérifier la compatibilité avec.
• --package-json <packageJson> Un chemin vers 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 par exemple : ../../node_modules,./node_modules)

Canal

Ajouter

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

[channelName] le nom de votre nouveau canal, tel que production ou beta. [appId] le nom de votre application, dans le 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] le nom de votre application, dans le 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.

Optionnellement, vous pouvez fournir :

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

Configurer

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

[appId] votre ID d'application, la forme est expliquée ici. [channelName] le nom du canal que vous souhaitez configurer, comme production ou beta.

Vous pouvez également fournir :

• --bundle [1.2.3] votre application bundle déjà envoyée dans le cloud, pour la lier à un canal.
• --latest obtenir la version du bundle à partir de package.json:version, ne peut pas être utilisé avec --bundle.
• --state [ normal | default ] mettre à jour l'état du canal, peut être normal ou default. Un seul canal doit être default.
• --downgrade permet au canal d'envoyer une version de dégradation aux appareils.
• --no-downgrade interdit au canal d'envoyer une version de dégradation aux appareils.
• --upgrade permet au canal d'envoyer une version d'amélioration (majeure) aux appareils.
• --no-upgrade interdit au canal d'envoyer une version d'amélioration (majeure) aux appareils.
• --ios permet au canal de transmettre la version aux appareils iOS.
• --no-ios interdit au canal de transmettre la version aux appareils iOS.
• --android permet au canal de transmettre la version aux appareils Android.
• --no-android interdit au canal de transmettre la version aux appareils Android.
• --self-assign permet aux appareils de s'attribuer automatiquement à ce canal.
• --no-self-assign interdit aux appareils de s'attribuer automatiquement à ce canal.
• --disable-auto-update STRATEGY Désactive la stratégie d'actualisation automatique pour ce canal. Les options possibles sont : majeur, mineur, patch, métadonnées, aucun.
• --apikey [key] clé API pour vous connecter à votre compte.

Désactive la stratégie d'actualisation.

Existe plusieurs façons de gérer la désactivation des mises à jour pour les versions trop anciennes.
clé Capgo ne peut pas mettre à jour le code natif code ; il ne doit donc pas être possible de passer d'une version avec le code natif code obsolète à une version avec le code natif code mis à jour. Existe plusieurs façons d'y parvenir.

Tout d'abord, le major stratégie. Cela empêche une mise à jour de la base native. 0.0.0 -> bundle cible 1.0.0Le major est le numéro mis en évidence ("1.0.0 et 0.0.0).
Deuxième est le minor stratégie. Elle empêche une mise à jour lorsque le bundle cible a un numéro majeur ou mineur différent du niveau de base natif du dispositif. 0.0.0 -> 1.1.0 or 1.1.0 -> 1.2.0.

Troisième, le patch strategy. It was added into capgo as a very strict mode. It’s not recommended to be used unless you fully understand how it works. In order for it to accept an update, the following conditions must be met:

• Le numéro mineur est le même entre le paquet cible et version_build
• Le numéro mineur est le même entre le paquet cible et version_build
• Le patch est le même entre le bundle cible et version_build
• Seule la version peut différer, comme une version préalable (-beta.2) ou des métadonnées de construction (+build.2)

Voici des exemples de scénarios dans lesquels l'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 base native envoyée comme version_buildet non la bundle téléchargée actuelle envoyée comme version_name.

Enfin, la stratégie la plus compliquée. Le metadata stratégie.
D'abord, vous devez savoir que les mises à jour s'activent après leur initialisation. WILL échouer car le canal manque les métadonnées requises.
Si le canal manque de métadonnées, vous verrez un message comme celui-ci :

Si vous voyez quelque chose comme cela, cela signifie que vous devez aller dans le bundle actuel du canal qui ne fonctionne pas et configurer les métadonnées.
Premièrement, déterminez quel canal ne fonctionne pas. Vous pouvez le faire en regardant la misconfigured colonne

Then go to the failing channel and click on Bundle numberCe qui devrait vous emmener sur la page du bundle.

Une fois là, renseignez le Minimal update version champ. Il devrait 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 correctement, vous devriez voir quelque chose comme ceci :

Maintenant, il est probable que vous ne souhaitez pas renseigner ces données manuellement chaque fois que vous mettez à jour. Heureusement, le CLI empêchera de vous de faire une mise à jour sans ce métadonnée

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

Le --min-update-version n'est pas la VOIE UNIQUE pour faire la compatibilité. Il existe également la --auto-min-update-version . Voici comment cela fonctionne.

Tout d'abord, il regarde la version actuellement téléchargée sur le canal. Il vérifie la compatibilité de la même manière que le bundle compatibility commande le ferait. Ensuite, si la nouvelle version est 100% compatible, il réutilise le min_update_version du dernier version dans le canal. Si ce n'est pas le cas, alors il définit le min_update_version au numéro de bundle de la nouvelle version téléchargée.

Vous obtiendrez toujours une information sur la min_update_version lorsque vous utilisez cette option. Elle ressemblera à ceci:

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

Chiffrement de bout en bout (sans confiance)

Capgo prend en charge le chiffrement de bout en bout, ce qui signifie que votre bundle (code) est chiffré avant d'être envoyé dans le cloud et déchiffré sur le dispositif. 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 est une combinaison de RSA et AES, la clé RSA est utilisée pour chiffrer la clé AES, et la clé AES est utilisée pour chiffrer le fichier.

Voir ci-dessous pour plus d'informations sur le système de chiffrement.

Schéma de chiffrement

Créer une clé pour votre application

npx @capgo/cli key create

Optionnellement, vous pouvez fournir : --force Pour écraser la clé existante. Cette commande créera pour vous un pair de clés dans votre application, 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 dans votre dépôt Git, et de ne pas la partager avec personne.

Après votre test local, supprimez la clé de votre fichier de configuration et ajoutez-l’à l'étape CI avec key save

Enregistrer la clé dans votre config d'application

npx @capgo/cli key save

Optionnellement, 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 l'utiliser inline. Cette commande est utile si vous avez suivi la recommandation et n'avez pas commis la clé dans votre config d'application.

Intégration CI

Pour automatiser votre travail, je vous recommande de faire que l'action GitHub s'occupe de la tâche de pousser vers notre serveur

La tutorielle de l'action GitHub

Notre application de démo

GitHub - Cap-go/démoweb

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

Continuez d'ici les Commandes

Si vous utilisez les Commandes pour planifier le tableau de bord et les opérations API, connectez-l’avec API Vue d'ensemble pour les détails d'implémentation dans API Vue d'ensemble, Introduction pour les détails d'implémentation dans Introduction, API Clés pour le détail d'implémentation dans API Clés, Appareils pour les détails d'implémentation dans les appareils, et Bundles pour le détail d'implémentation dans Appareils, et