Commandes

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

Utilisation

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

Capacitor Runtime natif cross-plateforme pour les applications web

Init

npx @capgo/cli@latest init [apikey]

Cette méthode est ici pour vous guider étape par étape.

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

Connexion

npx @capgo/cli login [apikey]

Cette méthode est ici pour vous rappeler le apikey pour vous.

Remarque

utilisez --apikey=******** dans n'importe quel commande pour le remplacer

Optionnellement vous pouvez donner :

--local Cela stockera votre apikey dans le repo local et l'ignorez sur git.

Docteur

npx @capgo/cli doctor

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

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

Application

Ajouter

npx @capgo/cli app add [appId]

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

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

Optionnellement, vous pouvez donner :

• --icon [/path/to/my/icon] pour avoir un icône personnalisé affiché dans l'application web de Capgo.
• --name [test] pour avoir un nom personnalisé dans la liste.
• --apikey [key] le clé API pour se connecter à votre compte.
• --retention [retention] la durée de conservation du bundle de l'application en jours, 0 par défaut = infini.

Exemple de capacitor.config.json pour appId et AppName, l'icône est supposée se trouver dans le dossier des ressources

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

Configurer

npx @capgo/cli app set [appId]

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

Vous pouvez optionnellement donner :

• --icon [/path/to/my/icon] pour avoir une icône personnalisée affichée dans l'application web de Capgo.
• --name [test] pour avoir un nom personnalisé dans la liste.
• --retention [retention] durée de conservation de l'archive de l'application en jours, 0 par défaut = infini.
• --expose-metadata [true|false] pour exposer les métadonnées de l'archive (lien et commentaire) au plugin.
• --preview ou --no-preview pour activer ou désactiver les codes QR de prévisualisation du paquet 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 pour 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 limite de construction native.
• --ios-store-url [url] ou --android-store-url [url] pour définir l'URL de la boutique.
• --default-upload-channel [channel] pour définir le canal d'upload par défaut.
• --default-download-channel [channel] pour définir le canal de download par défaut, ou --disable-download-channels pour rendre tous les canaux de download non publics.
• --apikey [key] API pour vous connecter à votre compte.

List

npx @capgo/cli app list [appId]

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

Optionnellement, vous pouvez donner :

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

Delete

npx @capgo/cli app delete [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.
• --bundle avec le numéro de version, cela supprimera uniquement cette version.

Débogage

npx @capgo/cli app debug [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.
• --device avec le dispositif spécifique que vous souhaitez déboguer

Paramètres

npx @capgo/cli app setting [path]

Éditez la Capacitor config.

[path] - chemin du paramètre que vous souhaitez modifier. Par exemple, pour modifier le appId, fournissez appId. Si 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 en chaîne de caractères
• --bool <true | false> - définit le paramètre en booléen

Bundle

Charger

npx @capgo/cli bundle upload [appId]

[appId] Votre ID d'application, le format est expliqué ici.

Optionnellement, vous pouvez donner :

• --apikey <apikey> Clé API pour se connecter à votre compte.
• --path <path> Chemin du dossier à charger.
• --channel <channel> Canal pour se connecter.
• --external <url> Se connecter à une URL externe au lieu de charger sur Capgo Cloud.
• --iv-session-key <key> Définir la clé de chiffrement et la clé de session pour l'URL du bundle externe.
• --s3-endpoint <s3Endpoint> Adresse 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 conteneur S3.
• --s3-apikey <apikey> Clé API pour votre endpoint S3.
• --s3-apisecret <apisecret> Clé secrète API pour votre endpoint S3.
• --s3-bucket-name <bucketName> Nom pour votre conteneur S3 AWS.
• --s3-port <port> Port pour votre endpoint S3.
• --no-s3-ssl Désactiver SSL pour le téléchargement 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 Ignorer la clé de signature et envoyer une mise à jour claire.
• --no-code-check Ignorez la vérification si notifyAppReady() est appelé dans le source code et l'index est présent dans le dossier racine.
• --display-iv-session Affichez dans la console les IV et la clé de session utilisés pour chiffrer la mise à jour.
• --bundle <bundle> Numéro de version du bundle à télécharger.
• --min-update-version <minUpdateVersion> Numéro de 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éfinit la version minimale de mise à jour basée sur les packages natifs.
• --ignore-metadata-check Ignores la vérification des métadonnées (node_modules) lors du téléchargement.
• --ignore-checksum-check Ignores la vérification de la somme de contrôle lors du téléchargement.
• --timeout <timeout> Temps d'attente pour le processus de téléchargement en secondes.
• --delta Télécharge les fichiers Delta (manifest) en parallèle du bundle complet.
• --delta-only Télécharge uniquement les mises à jour Delta (manifest), en ignorant le bundle complet.
• --no-delta Désactive les téléchargements Delta (manifest) (utile si une mise à jour instantanée est requise) autoUpdate mode est activé mais vous souhaitez un bundle complet).
• --tus Envoyez le bundle à l'aide du protocole tus.
• --multipart Utilise le protocole multipart pour envoyer des données vers S3, Déprécié, utilisez TUS à la place.
• --encrypted-checksum <encryptedChecksum> Un hachage chiffré (signature). Utilisé uniquement lors de l'upload d'un bundle externe.
• --package-json <packageJson> Un chemin vers package.json. Utile pour les monorepos.
• --auto-set-bundle Fixez 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 de déverrouiller 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.

👀 Le cloud de Capgo ne regarde jamais ce qui se trouve dans le lien (pour l'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] votre ID d'application au format com.test.app est expliqué ici.

Optionnellement, vous pouvez donner :

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

Supprimer

npx @capgo/cli bundle delete [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.
• --bundle avec le numéro de version ne supprimera que cette version.

Nettoyage

dans une plage SemVer pour une version majeure vers Cloud

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

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

Optionnellement, vous pouvez fournir :

• --apikey [key] La clé API pour se connecter à votre compte.
• --bundle [majorVersion] une version que vous souhaitez supprimer les packages précédents, il gardera le dernier + 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 vous utilisez npx @capgo/cli cleanup [appId] --bundle=10.0.0 il supprimera 10.0.1 à 10.0.6. 10.0.7 jusqu'à 10.0.11 sera conservé.

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

Cette commande demandera confirmation, elle affichera une table de ce qu'elle gardera et supprimera.

Note

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

Chiffrer

Avertissement: Cette commande est obsolète et sera supprimée dans la prochaine version majeure. Veuillez utiliser le nouveau système de chiffrage. 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.

Optionnellement, 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 une clé inline. ivSessionKeyLa commande imprimera votre

y et générera un zip chiffré, pour l'utiliser avec la commande d'upload ou la commande de décryptage.

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

This command is used when you use external source to store your code or for test purpose. The checksum is the sha256 of the bundle (generated by —key-v2), it is used to verify the integrity of the file after decryption. It will be enncrypted with the private key and sent along with the bundle. In encryption v2 the checksum is upgraded to become a “signature” of the bundle.

Optionnellement, 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 l'utiliser en ligne. --json pour afficher les informations sous forme de JSON. ivSessionKeyLa commande imprimer votre

y et générer un zip chiffré, pour l'utiliser avec la commande d'upload ou la commande de déchiffrement.

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

Section intitulée “Déchiffrer”

--key [/path/to/my/private_key] Optionnellement, vous pouvez fournir :

--key-data [privateKey] le chemin de votre clé privée.

les données de la clé privée, si vous souhaitez l'utiliser en ligne. Cette commande est principalement utilisée à des fins de test, elle déchiffrera le zip et imprimer le clé de session décryptée sous forme de base64 dans la console.

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

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 utiliser une méthode inline. Cette commande est principalement utilisée pour des tests, elle déchiffrera le zip et affichera 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] c'est votre ID d'application, la forme est expliquée ici.

Vous pouvez également fournir :

• --path [/path/to/my/bundle] pour télécharger un dossier spécifique.
• --bundle [1.0.0] pour définir la version du bundle du nom du fichier.
• --name [myapp] pour remplacer le nom du fichier.
• --json afficher les informations sous forme de JSON.
• --no-code-check ignorer la vérification de code et envoyer le bundle en tout cas.
• --key-v2 utiliser le nouveau système d'encryption. Cela est requis car le nouveau système d'encryption utilise des sommes de contrôle améliorées pour vérifier l'intégrité du fichier.

Compatibilité

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

[appId] c'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 utiliser le texte au lieu des émoticônes dans le tableau
• --channel [channel] le canal à vérifier la compatibilité avec.
• --package-json <packageJson> Acheminez vers le fichier package.json. Utile pour les monoproduits
• --node-modules <nodeModules> Une liste de chemins vers node_modules. Utile pour les monoproduits (séparés par des virgules par exemple : ../../node_modules,./node_modules)

Chaîne

Ajouter

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

[channelName] le nom de votre nouvelle chaîne, comme 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.

Optionnellement, vous pouvez fournir :

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

Configurez

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

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

Optionnellement, vous pouvez fournir :

• --bundle [1.2.3] votre application bundle déjà envoyée dans le cloud, pour la lier à un canal.
• --latest obtenez la version du bundle à partir de package.json:version, qui ne peut pas être utilisé avec --bundle.
• --state [ normal | default ] fixez l'état du canal, qui peut être normal ou default. Une seule chaîne doit être utilisée default.
• --downgrade autorise la chaîne à envoyer une version downgrade aux appareils.
• --no-downgrade interdit à la chaîne d'envoyer une version downgrade aux appareils.
• --upgrade autorise la chaîne à envoyer une version majeure (upgrade) aux appareils.
• --no-upgrade interdit à la chaîne d'envoyer une version majeure (upgrade) aux appareils.
• --ios autorise la chaîne à envoyer une version aux appareils iOS.
• --no-ios interdit à la chaîne d'envoyer une version aux appareils iOS.
• --android autorise la chaîne à envoyer une version aux appareils Android.
• --no-android interdit à la chaîne d'envoyer une version aux appareils Android.
• --self-assign autorise les appareils à se réassigner automatiquement à cette chaîne.
• --no-self-assign interdit aux appareils de se réassigner automatiquement à cette chaîne.
• --disable-auto-update STRATEGY Désactive la stratégie d'actualisation automatique pour cette chaîne. Les options possibles sont : majeure, mineure, patch, métadonnées, aucune.
• --apikey [key] API clé pour se connecter à votre compte.

Stratégie de désactivation des mises à jour

Il existe quelques façons de gérer la désactivation des mises à jour pour les versions trop anciennes.
Capgo ne peut pas mettre à jour les code natifs, il n'est donc pas possible d'effectuer une mise à jour d'une version avec les anciens code natifs vers une version avec les code natifs mis à jour. Il existe plusieurs façons d'y parvenir.

Premièrement, la major stratégie. Elle empêche une mise à jour de la base native 0.0.0 -> cible bundle 1.0.0. Le numéro majeur est le numéro mis en surbrillance (1.0.0 et 0.0.0).
Deuxièmement, la minor stratégie. Elle empêche une mise à jour lorsque le bundle cible a un numéro majeur ou mineur différent de la base native du dispositif, comme 0.0.0 -> 1.1.0 ou 1.1.0 -> 1.2.0.

Troisième, la stratégie. Elle a été ajoutée dans __CAPGO_KEEP_0__ sous la forme d'un mode très strict. Il ne faut pas l'utiliser à moins de bien comprendre comment cela fonctionne. Pour qu'il accepte une mise à jour, les conditions suivantes doivent être remplies : 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 bundle cible et version_build
• Le numéro de patch est le même entre le bundle cible et version_build
• Seule la version de suffixe peut différer, comme les préversions ( version_build
• ) ou les métadonnées de construction (-beta.2) or build metadata (+build.2)

Ceci est un exemple de scénarios dans lesquels 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 référence de base native envoyée comme version_build, et non la version téléchargée actuelle envoyée comme version_name.

Enfin, la stratégie la plus compliquée. Le metadata stratégie.
Tout d'abord, vous devez savoir que initialement après avoir activé cela, les mises à jour SERONT é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, vous savez que vous devez aller à la version actuelle du bundle pour le canal qui a échoué et configurer les métadonnées.
Premièrement, déterminez quel canal est en panne. Vous pouvez le faire en regardant la misconfigured colonne

Ensuite, allez dans le canal en panne et cliquez sur Bundle number. Cela devrait vous emmener sur la page du bundle.

Une fois là, renseignez le Minimal update version champ. Il s'agit 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écharger correctement un bundle en utilisant l' metadata option, vous devez passer le --min-update-version avec le version semver valide. Quelque chose comme ceci :

Le --min-update-version n'est pas la SEULE façon de 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. Deuxièmement, si la nouvelle version est 100% compatible, il réutilise le min_update_version à partir de la dernière version du canal. Si ce n'est pas le cas, alors il défini le min_update_version à la version du bundle de la nouvelle version téléchargée.

Vous obtiendrez toujours des informations sur le min_update_version lorsque vous utilisez cette option. Il ressemblera à ceci:

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

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 un 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 d'encryption

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 une paire 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 commit la clé privée dans le dépôt Git, et de ne pas la partager avec personne.

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

Enregistrer la clé dans la configuration de l'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 commit la clé dans la configuration de l'application.

Intégration CI

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

Tutoriel de l'action GitHub

Notre application de démonstration

GitHub - Cap-go/demo-app

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

Continuez d'ici : Commandes

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