Commandes

Utilisation

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

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

Initialisation

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]

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

Remarque

utilisation --apikey=******** dans n'importe quelle commande pour le contourner

Optionnellement, vous pouvez donner :

--local Cela stockera votre apikey dans le dépôt local et l'ignore 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é ici.

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

Optionnellement, vous pouvez fournir :

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

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

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

Définir

npx @capgo/cli app set [appId]

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

Optionnellement, vous pouvez donner :

• --icon [/path/to/my/icon] avoir un icône personnalisée s'afficher dans l'application web Capgo.
• --name [test] 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.
• --apikey [key] API clé pour se connecter à votre compte.

Liste

npx @capgo/cli app list [appId]

[appId] l'ID de votre 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.

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.

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 configuration.

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

Vous DEVEZ fournir l'un ou l'autre --string ou --bool!

Options:

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

Bundle

Upload

npx @capgo/cli bundle upload [appId]

[appId] 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> Canal à lier.
• --external <url> Lier à une URL externe au lieu de télécharger sur Capgo Cloud.
• --iv-session-key <key> Définir la valeur de l'IV et de 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> API clé pour votre endpoint S3.
• --s3-apisecret <apisecret> API secret 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 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 Ignore la clé de signature et envoie une mise à jour claire.
• --no-code-check Ignore la vérification si notifyAppReady() est appelé dans le source code et l'index est présent dans le dossier racine.
• --display-iv-session Affiche dans la console la clé de session et l'IV 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 minimal requis pour mettre à jour vers cette version. Utilisé uniquement si la mise à jour automatique est désactivée dans le canal.
• --auto-min-update-version Fixe la version de mise à jour minimale basée sur les packages natifs.
• --ignore-metadata-check Ignores la vérification des métadonnées (node_modules) lors de l'upload.
• --ignore-checksum-check Ignores la vérification de la checksum lors de l'upload.
• --timeout <timeout> Durée de temps limite pour le processus d'upload en secondes.
• --delta Envoie les fichiers Delta (manifest) ainsi que le bundle complet.
• --delta-only Envoie uniquement les mises à jour Delta (manifest), en ignorant le bundle complet.
• --no-delta Désactive les uploads Delta (manifest) (utile si un mode d'application instantanée est activé mais que vous souhaitez un bundle complet). autoUpdate Envoie le bundle en utilisant le protocole tus.
• --tus Utilise le protocole multipart pour envoyer des données vers S3, obsolète, utilisez TUS à la place.
• --multipart Un hachage chiffré (signature). Utilisé uniquement lors de l'upload d'un bundle externe.
• --encrypted-checksum <encryptedChecksum> Un chemin vers package.json. Utile pour les monorepos.
• --package-json <packageJson> Définissez le bundle dans __CAPGO_KEEP_0__.config.json.
• --auto-set-bundle Set the bundle in capacitor.config.json.
• --node-modules <nodeModules> ⭐️ L'option externe permet de déverrouiller 2 cas : les entreprises avec des préoccupations de confidentialité, ne pas envoyer le __CAPGO_KEEP_0__ à un tiers et les applications plus grandes que 200 MB. Avec cette configuration, __CAPGO_KEEP_1__ stocke uniquement le lien vers le zip et envoie le lien à toutes les applications.

⭐️ L'option externe aide à 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.

👀 Capgo le cloud ne regarde 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] 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 bundle delete [appId]

[appId] votre ID d'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 ne supprimera que cette version.

Nettoyage

dans une plage de version 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 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 jusqu'à 10.0.11 sera gardé.

Si vous avez 20 versions au total, et vous ne fournissez pas 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 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.

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 inline. La commande affichera votre ivSessionKeyet générer un zip chiffré, pour l'utiliser avec la commande de téléchargement ou la commande de décryptage.

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 vérification de l'intégrité 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écryptage. Il sera chiffré avec la clé privée et envoyé avec le bundle. Dans la chiffrer V2, la vérification de l'intégrité est mise à niveau pour devenir une « signature » du 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 inline. --json pour afficher les informations sous forme de JSON. La commande affichera votre ivSessionKeyet générer un zip chiffré, pour l'utiliser avec la commande de téléchargement ou la commande de décryptage.

Décrypter

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

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. Cette commande est principalement utilisée à des fins de test, elle déchiffrera le zip et affichera la clé de session déchiffrée en base64 dans la console.

Déchiffrer V2

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

Optionnellement, vous pouvez donner :

--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. Cette commande est principalement utilisée à des fins de test, 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] 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 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 sous forme de JSON.
• --no-code-check pour ignorer la vérification code et envoyer le bundle malgré tout.
• --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 plus performantes 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 fournir :

• --apikey [key] API clé pour se connecter à votre compte.
• --text Utiliser du texte au lieu d'émoticônes dans le tableau
• --channel [channel] le canal pour 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] 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 donner :

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

Définir

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, comme production ou beta.

Optionnellement, vous pouvez donner :

• --bundle [1.2.3] votre bundle d'application déjà envoyé dans le cloud, pour le lier à un canal.
• --latest obtenez la version du bundle de package.json:version, ne peut pas être utilisé avec --bundle.
• --state [ normal | default ] fixez l'état du canal, cela peut normal ou default. Un canal doit être default.
• --downgrade empêche le canal de transmettre une version de dégradation aux appareils.
• --no-downgrade empêche le canal de transmettre une version de dégradation aux appareils.
• --upgrade permet au canal de transmettre une version de mise à niveau (majeure) aux appareils.
• --no-upgrade empêche le canal de transmettre une version de mise à niveau (majeure) aux appareils.
• --ios permet au canal de transmettre une version aux appareils iOS.
• --no-ios empêche le canal de transmettre une version aux appareils iOS.
• --android permet au canal de transmettre une version aux appareils Android.
• --no-android interdit le canal d'envoyer 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ésactiver la stratégie d'actualisation automatique pour ce canal. Les options possibles sont : majeur, mineur, patch, métadonnées, aucun.
• --apikey [key] API pour se connecter à votre compte.

Désactiver la stratégie d'actualisation

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 est donc impossible 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 de ligne native 0.0.0 -> vers un bundle cible 1.0.0. Le numéro majeur est le numéro mis en surbrillance (1.0.0 et 0.0.0).
Deuxième est la minor stratégie. Elle empêche une mise à jour lorsque le paquet cible a un numéro majeur ou mineur différent du niveau de base natif du dispositif, tel que 0.0.0 -> 1.1.0 ou 1.1.0 -> 1.2.0.

Troisième, la patch stratégie. Elle a été ajoutée dans capgo comme 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 : version_build
• Le numéro majeur 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 numéro de patch est le même entre le paquet cible et-beta.2Seul le suffixe de version peut différer, tel que la version préalable (+build.2)

Voici un exemple 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 référence native envoyée comme version_build, et non le bundle téléchargé actuellement envoyé comme version_name.

Enfin, la stratégie la plus compliquée. La metadata stratégie.
Tout d'abord, vous devez savoir que initialement après avoir activé cela, les mises à jour SERONT échoue comme 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 dans le bundle actuel du canal en question et configurer les métadonnées.
Tout d'abord, déterminez quel canal est en train de faillir. Vous pouvez le faire en regardant la misconfigured colonne

Alors, allez dans le canal en question et cliquez sur Bundle numberCela devrait vous emmener sur la page du bundle.

Une fois là, renseignez le Minimal update version champ. Cela devrait être 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, vous n'avez probablement pas envie de définir ce données manuellement chaque fois que vous mettez à jour. Heureusement, le CLI vous empêchera de vous envoyer une mise à jour sans ce métadonnées

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

Les --min-update-version n'est pas la SEULE façon de faire la compatibilité. Il existe également le --auto-min-update-version. Voici comment cela fonctionne.

Premièrement, il prend un coup d'œil à 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 de la version la plus récente du canal. Si ce n'est pas le cas, alors il définit le min_update_version au numéro de paquet de la nouvelle version téléchargée.

Vous obtiendrez toujours des informations sur la min_update_version lorsque vous utilisez cette option. Elle 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 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 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 Git, et de ne pas la partager avec personne.

Après vos tests locaux, supprimez la clé de le fichier de configuration et ajoutez-la dans l'étape CI avec key save

Enregistrer la clé dans la configuration de votre 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 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

GitHub action tutorial

Notre application de démonstration

GitHub - Cap-go/demo-app

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

Continuez de là Commandes

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