Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# AWS IoT Greengrass outils de développement
Utilisez les outils de AWS IoT Greengrass développement pour créer, tester, créer, publier et déployer des composants Greengrass personnalisés.
+ **[Kit de développement Greengrass CLI](greengrass-development-kit-cli.md)**
Utilisez l'interface de ligne de commande du kit de AWS IoT Greengrass développement (CLI GDK) dans votre environnement de développement local pour créer des composants à partir de modèles et de composants communautaires du catalogue de logiciels [Greengrass](greengrass-software-catalog.md). Vous pouvez utiliser la CLI GDK pour créer le composant et le publier sur le AWS IoT Greengrass service en tant que composant privé dans votre Compte AWS.
+ **[Interface de ligne de commande Greengrass](gg-cli.md)**
Utilisez l'interface de ligne de commande Greengrass (Greengrass CLI) sur les appareils principaux de Greengrass pour déployer et déboguer les composants de Greengrass. La CLI Greengrass est un composant que vous pouvez déployer sur vos appareils principaux pour créer des déploiements locaux, afficher les détails des composants installés et explorer les fichiers journaux.
+ **[Console de débogage locale](local-debug-console-component.md)**
Utilisez la console de débogage locale sur les appareils principaux de Greengrass pour déployer et déboguer les composants de Greengrass à l'aide d'une interface Web de tableau de bord local. La console de débogage locale est un composant que vous pouvez déployer sur vos appareils principaux pour créer des déploiements locaux et afficher les détails des composants installés.
AWS IoT Greengrass fournit également les éléments suivants SDKs que vous pouvez utiliser dans les composants Greengrass personnalisés :
+ Le Kit SDK des appareils AWS IoT et le SDK de AWS IoT Greengrass composants, qui contiennent la bibliothèque de communication interprocessus (IPC). Pour de plus amples informations, veuillez consulter [Utilisez le Kit SDK des appareils AWS IoT pour communiquer avec le noyau de Greengrass, les autres composants et AWS IoT CoreCommuniquez avec le noyau de Greengrass, les autres composants et AWS IoT Core](interprocess-communication.md).
+ Le SDK Stream Manager, que vous pouvez utiliser pour transférer des flux de données vers le AWS Cloud. Pour de plus amples informations, veuillez consulter [Gérez les flux de données sur les appareils principaux de Greengrass](manage-data-streams.md).
**Topics**
+ [AWS IoT Greengrass Interface de ligne de commande du kit de développement](greengrass-development-kit-cli.md)
+ [Interface de ligne de commande Greengrass](gg-cli.md)
+ [Utiliser le framework AWS IoT Greengrass de test](gg-testing-framework.md)
# AWS IoT Greengrass Interface de ligne de commande du kit de développement
L'interface de ligne de commande du kit de AWS IoT Greengrass développement (GDK CLI) fournit des fonctionnalités qui vous aident à développer des composants [Greengrass personnalisés](develop-greengrass-components.md). Vous pouvez utiliser la CLI GDK pour créer, créer et publier des composants personnalisés. Lorsque vous créez un référentiel de composants avec la CLI GDK, vous pouvez partir d'un modèle ou d'un composant communautaire du catalogue de logiciels [Greengrass](greengrass-software-catalog.md). Ensuite, vous pouvez choisir un système de compilation qui empaquète les fichiers sous forme d'archives ZIP, utilise un script de génération Maven ou Gradle ou exécute une commande de construction personnalisée. Après avoir créé un composant, vous pouvez utiliser la CLI GDK pour le publier sur le AWS IoT Greengrass service. Vous pouvez ainsi utiliser la AWS IoT Greengrass console ou l'API pour déployer le composant sur vos appareils principaux Greengrass.
Lorsque vous développez des composants Greengrass sans la CLI GDK, vous devez mettre à jour la version et l' URIs artefact dans [le fichier de recette du composant](component-recipe-reference.md) chaque fois que vous créez une nouvelle version du composant. Lorsque vous utilisez la CLI GDK, elle peut automatiquement mettre à jour la version et l'artefact URIs pour vous chaque fois que vous publiez une nouvelle version du composant.
La CLI GDK est open source et disponible sur GitHub. Vous pouvez personnaliser et étendre la CLI GDK pour répondre à vos besoins de développement de composants. Nous vous invitons à ouvrir des problèmes et à extraire des requêtes sur le GitHub référentiel. Vous pouvez trouver la source de la CLI GDK sur le lien suivant : [https://github.com/aws-greengrass/aws-greengrass-gdk-cli](https://github.com/aws-greengrass/aws-greengrass-gdk-cli)
## Prérequis
Pour installer et utiliser la CLI du Greengrass Development Kit, vous avez besoin des éléments suivants :
+ Un Compte AWS. Si vous n'en avez pas, veuillez consulter [Configurez un Compte AWS](setting-up.md#set-up-aws-account).
+ Un ordinateur de développement de type Windows, macOS ou Unix doté d'une connexion Internet.
+ Pour la version 1.1.0 ou ultérieure de GDK CLI, [Python](https://www.python.org/downloads/) 3.6 ou version ultérieure est installé sur votre ordinateur de développement.
Pour la version 1.0.0 de la CLI GDK, [Python](https://www.python.org/downloads/) 3.8 ou version ultérieure installé sur votre ordinateur de développement.
+ [Git](https://git-scm.com/) est installé sur votre ordinateur de développement.
+ AWS Command Line Interface (AWS CLI) installé et configuré avec des informations d'identification sur votre ordinateur de développement. Pour plus d'informations, consultez les [sections Installation, mise à jour et désinstallation du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [Configuration du AWS CLI dans le](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) *guide de l'AWS Command Line Interface utilisateur*.
**Note**
Si vous utilisez un Raspberry Pi ou un autre appareil ARM 32 bits, installez la AWS CLI V1. AWS CLI La V2 n'est pas disponible pour les appareils ARM 32 bits. Pour plus d'informations, voir [Installation, mise à jour et désinstallation de la AWS CLI version 1](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html).
+ Pour utiliser la CLI GDK afin de publier des composants sur le AWS IoT Greengrass service, vous devez disposer des autorisations suivantes :
+ `s3:CreateBucket`
+ `s3:GetBucketLocation`
+ `s3:PutObject`
+ `greengrass:CreateComponentVersion`
+ `greengrass:ListComponentVersions`
+ Pour utiliser la CLI GDK afin de créer un composant dont les artefacts existent dans un compartiment S3 et non dans le système de fichiers local, vous devez disposer des autorisations suivantes :
+ `s3:ListBucket`
Cette fonctionnalité est disponible pour GDK CLI v1.1.0 et versions ultérieures.
## Journal des modifications
Le tableau suivant décrit les modifications apportées à chaque version de la CLI GDK. Pour plus d'informations, consultez la [page des versions de la CLI GDK](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases) sur GitHub.
| **Version** | **Modifications** |
| --- | --- |
| 1.6.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.0.0 | Première version. |
# Installation ou mise à jour de l'interface de ligne de commande AWS IoT Greengrass du kit de développement
L'interface de ligne de commande du kit de AWS IoT Greengrass développement (GDK CLI) est basée sur Python, vous pouvez donc `pip` l'installer sur votre ordinateur de développement.
**Astuce**
Vous pouvez également installer la CLI GDK dans un environnement virtuel Python tel que [venv](https://docs.python.org/3/library/venv.html#module-venv). Pour plus d'informations, consultez [Environnements virtuels et packages](https://docs.python.org/3/tutorial/venv.html) dans la *documentation de Python 3*.
**Pour installer ou mettre à jour la CLI GDK**
1. Exécutez la commande suivante pour installer la dernière version de la CLI GDK à partir de son [GitHubréférentiel](https://github.com/aws-greengrass/aws-greengrass-gdk-cli).
```
python3 -m pip install -U git+https://github.com/aws-greengrass/aws-greengrass-gdk-cli.git@v1.6.2
```
**Note**
Pour installer une version spécifique de la CLI GDK, remplacez-la *versionTag* par la balise de version à installer. Vous pouvez consulter les balises de version de la CLI GDK dans son [GitHubréférentiel](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/tags).
```
python3 -m pip install -U git+https://github.com/aws-greengrass/aws-greengrass-gdk-cli.git@versionTag
```
1. Exécutez la commande suivante pour vérifier que la CLI GDK a été correctement installée.
```
gdk --help
```
Si la `gdk` commande n'est pas trouvée, ajoutez son dossier dans PATH.
+ Sur les appareils Linux, ajoutez `/home/MyUser/.local/bin` à PATH et remplacez-le par *MyUser* le nom de votre utilisateur.
+ Sur les appareils Windows, ajoutez `PythonPath\\Scripts` à PATH et remplacez-le par *PythonPath* le chemin d'accès au dossier Python de votre appareil.
Vous pouvez désormais utiliser la CLI GDK pour créer, créer et publier des composants Greengrass. Pour plus d'informations sur l'utilisation de la CLI GDK, consultez[AWS IoT Greengrass Commandes de l'interface de ligne de commande du kit de développement](greengrass-development-kit-cli-commands.md).
# AWS IoT Greengrass Commandes de l'interface de ligne de commande du kit de développement
L'interface de ligne de commande du kit de AWS IoT Greengrass développement (GDK CLI) fournit une interface de ligne de commande que vous pouvez utiliser pour créer, créer et publier des composants Greengrass sur votre ordinateur de développement. Les commandes GDK CLI utilisent le format suivant.
```
gdk [arguments]
```
Lorsque vous [installez la CLI GDK](install-greengrass-development-kit-cli.md), le programme d'installation ajoute des éléments `gdk` au PATH afin que vous puissiez exécuter la CLI GDK depuis la ligne de commande.
Vous pouvez utiliser les arguments suivants avec n'importe quelle commande :
+ Utilisez `-h` ou `--help` pour obtenir des informations sur une commande GDK CLI.
+ Utilisez `-v` ou `--version` pour voir quelle version de GDK CLI est installée.
+ Utilisez `-d` ou `--debug` pour générer des journaux détaillés que vous pouvez utiliser pour déboguer la CLI GDK.
Cette section décrit les commandes de la CLI GDK et fournit des exemples pour chaque commande. Le synopsis de chaque commande montre ses arguments et leur utilisation. Les arguments facultatifs sont indiqués entre crochets.
**Topics**
+ [composant](greengrass-development-kit-cli-component.md)
+ [config](greengrass-development-kit-cli-config.md)
+ [test-e2e](greengrass-development-kit-cli-test.md)
# composant
Utilisez la `component` commande dans l'interface de ligne de commande du kit de AWS IoT Greengrass développement (CLI GDK) pour créer, créer et publier des composants Greengrass personnalisés.
**Topics**
+ [init](#greengrass-development-kit-cli-component-init)
+ [build](#greengrass-development-kit-cli-component-build)
+ [publication](#greengrass-development-kit-cli-component-publish)
+ [liste](#greengrass-development-kit-cli-component-list)
## init
Initialisez un dossier de composants Greengrass à partir d'un modèle de composant ou d'un composant communautaire.
La CLI GDK récupère les composants communautaires du [catalogue des logiciels Greengrass](greengrass-software-catalog.md) et les modèles de composants du référentiel de modèles de [AWS IoT Greengrass composants](https://github.com/aws-greengrass/aws-greengrass-component-templates) sur. GitHub
**Note**
Si vous utilisez GDK CLI v1.0.0, vous devez exécuter cette commande dans un dossier vide. La CLI GDK télécharge le modèle ou le composant communautaire dans le dossier actuel.
Si vous utilisez la CLI GDK v1.1.0 ou une version ultérieure, vous pouvez spécifier l'`--name`argument pour spécifier le dossier dans lequel la CLI GDK télécharge le modèle ou le composant communautaire. Si vous utilisez cet argument, spécifiez un dossier qui n'existe pas. La CLI GDK crée le dossier pour vous. Si vous ne spécifiez pas cet argument, la CLI GDK utilise le dossier actuel, qui doit être vide.
Si le composant utilise le [système de génération zip](gdk-cli-configuration-file.md#gdk-cli-configuration-file-build-system), la CLI GDK compresse certains fichiers du dossier du composant dans un fichier zip portant le même nom que le dossier du composant. Par exemple, si le nom du dossier du composant est`HelloWorld`, la CLI GDK crée un fichier zip nommé`HelloWorld.zip`. Dans la recette du composant, le nom de l'artefact zip doit correspondre au nom du dossier du composant. Si vous utilisez la version 1.0.0 de la CLI GDK sur un appareil Windows, les noms des dossiers de composants et des fichiers zip ne doivent contenir que des lettres minuscules.
Si vous initialisez un modèle ou un composant communautaire qui utilise le système de génération zip dans un dossier portant un nom différent de celui du modèle ou du composant, vous devez modifier le nom de l'artefact zip dans la recette du composant. Mettez à jour les `Lifecycle` définitions `Artifacts` et de manière à ce que le nom du fichier zip corresponde au nom du dossier du composant. L'exemple suivant met en évidence le nom du fichier zip dans les `Lifecycle` définitions `Artifacts` et.
```
{
...
"Manifests": [
{
"Platform": {
"os": "all"
},
"Artifacts": [
{
"URI": "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/HelloWorld.zip",
"Unarchive": "ZIP"
}
],
"Lifecycle": {
"Run": "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
}
}
]
}
```
```
---
...
Manifests:
- Platform:
os: all
Artifacts:
- URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/HelloWorld.zip"
Unarchive: ZIP
Lifecycle:
Run: "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
```
**Résumé**
```
$ gdk component init
[--language]
[--template]
[--repository]
[--name]
```
**Arguments (initialisation à partir du modèle de composant)**
+ `-l`, `--language` — Langage de programmation à utiliser pour le modèle que vous spécifiez.
Vous devez spécifier soit, `--repository` soit `--language` et`--template`.
+ `-t`, `--template` — Modèle de composant à utiliser pour un projet de composant local. Pour afficher les modèles disponibles, utilisez la commande [list](#greengrass-development-kit-cli-component-list).
Vous devez spécifier soit, `--repository` soit `--language` et`--template`.
+ `-n`, `--name` — (Facultatif) Le nom du dossier local dans lequel la CLI GDK initialise le composant. Spécifiez un dossier qui n'existe pas. La CLI GDK crée le dossier pour vous.
Cette fonctionnalité est disponible pour GDK CLI v1.1.0 et versions ultérieures.
**Arguments (initialisation à partir du composant communautaire)**
+ `-r`, `--repository` — Le composant communautaire à récupérer dans le dossier local. Pour afficher les composants communautaires disponibles, utilisez la commande [list](#greengrass-development-kit-cli-component-list).
Vous devez spécifier soit, `--repository` soit `--language` et`--template`.
+ `-n`, `--name` — (Facultatif) Le nom du dossier local dans lequel la CLI GDK initialise le composant. Spécifiez un dossier qui n'existe pas. La CLI GDK crée le dossier pour vous.
Cette fonctionnalité est disponible pour GDK CLI v1.1.0 et versions ultérieures.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande pour initialiser un dossier de composants à partir du modèle Python Hello World.
```
$ gdk component init -l python -t HelloWorld
[2021-11-29 12:51:40] INFO - Initializing the project directory with a python component template - 'HelloWorld'.
[2021-11-29 12:51:40] INFO - Fetching the component template 'HelloWorld-python' from Greengrass Software Catalog.
```
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande pour initialiser un dossier de composants à partir d'un composant communautaire.
```
$ gdk component init -r aws-greengrass-labs-database-influxdb
[2022-01-24 15:44:33] INFO - Initializing the project directory with a component from repository catalog - 'aws-greengrass-labs-database-influxdb'.
[2022-01-24 15:44:33] INFO - Fetching the component repository 'aws-greengrass-labs-database-influxdb' from Greengrass Software Catalog.
```
## build
Intégrez la source d'un composant dans une recette et des artefacts que vous pouvez publier sur le AWS IoT Greengrass service. La CLI GDK exécute le système de génération que vous spécifiez dans le [fichier de configuration de la CLI GDK](gdk-cli-configuration-file.md),. `gdk-config.json` Vous devez exécuter cette commande dans le dossier où se trouve le `gdk-config.json` fichier.
Lorsque vous exécutez cette commande, la CLI GDK crée une recette et des artefacts dans le `greengrass-build` dossier du dossier des composants. La CLI GDK enregistre la recette dans le `greengrass-build/recipes` dossier et enregistre les artefacts dans le `greengrass-build/artifacts/componentName/componentVersion` dossier.
Si vous utilisez GDK CLI v1.1.0 ou version ultérieure, la recette du composant peut spécifier des artefacts qui existent dans un compartiment S3 mais pas dans le dossier de construction du composant local. Vous pouvez utiliser cette fonctionnalité pour réduire l'utilisation de la bande passante lorsque vous développez des composants comportant de gros artefacts, tels que des modèles d'apprentissage automatique.
Après avoir créé un composant, vous pouvez effectuer l'une des opérations suivantes pour le tester sur un appareil Greengrass principal :
+ Si vous développez sur un appareil différent de celui sur lequel vous exécutez le logiciel AWS IoT Greengrass Core, vous devez publier le composant pour le déployer sur un appareil principal Greengrass. Publiez le composant sur le AWS IoT Greengrass service et déployez-le sur le périphérique principal de Greengrass. Pour plus d'informations, consultez la commande de [publication](#greengrass-development-kit-cli-component-build) et[Créer des déploiements](create-deployments.md).
+ Si vous développez sur le même appareil que celui sur lequel vous exécutez le logiciel AWS IoT Greengrass Core, vous pouvez publier le composant sur le AWS IoT Greengrass service à déployer, ou vous pouvez créer un déploiement local pour installer et exécuter le composant. Pour créer un déploiement local, utilisez la CLI Greengrass. Pour plus d’informations, consultez [Interface de ligne de commande Greengrass](gg-cli.md) et [Testez AWS IoT Greengrass les composants avec des déploiements locaux](test-components.md). Lorsque vous créez le déploiement local, `greengrass-build/recipes` spécifiez-le comme dossier de recettes et `greengrass-build/artifacts` comme dossier d'artefacts.
**Résumé**
```
$ gdk component build
```
**Arguments**
Aucun
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ gdk component build
[2021-11-29 13:18:49] INFO - Getting project configuration from gdk-config.json
[2021-11-29 13:18:49] INFO - Found component recipe file 'recipe.yaml' in the project directory.
[2021-11-29 13:18:49] INFO - Building the component 'com.example.PythonHelloWorld' with the given project configuration.
[2021-11-29 13:18:49] INFO - Using 'zip' build system to build the component.
[2021-11-29 13:18:49] WARNING - This component is identified as using 'zip' build system. If this is incorrect, please exit and specify custom build command in the 'gdk-config.json'.
[2021-11-29 13:18:49] INFO - Zipping source code files of the component.
[2021-11-29 13:18:49] INFO - Copying over the build artifacts to the greengrass component artifacts build folder.
[2021-11-29 13:18:49] INFO - Updating artifact URIs in the recipe.
[2021-11-29 13:18:49] INFO - Creating component recipe in 'C:\Users\MyUser\Documents\greengrass-components\python\HelloWorld\greengrass-build\recipes'.
```
## publication
Publiez ce composant sur le AWS IoT Greengrass service. Cette commande télécharge les artefacts de construction dans un compartiment S3, met à jour l'URI de l'artefact dans la recette et crée une nouvelle version du composant à partir de la recette. La CLI GDK utilise le compartiment S3 et la AWS région que vous spécifiez dans le [fichier de configuration de la CLI GDK](gdk-cli-configuration-file.md),. `gdk-config.json` Vous devez exécuter cette commande dans le dossier où se trouve le `gdk-config.json` fichier.
Si vous utilisez la CLI GDK v1.1.0 ou une version ultérieure, vous pouvez spécifier l'`--bucket`argument pour spécifier le compartiment S3 dans lequel la CLI GDK télécharge les artefacts du composant. Si vous ne spécifiez pas cet argument, la CLI GDK télécharge vers le compartiment S3 dont le nom est`bucket-region-accountId`, où *bucket* et *region* sont les valeurs que vous spécifiez`gdk-config.json`, ainsi que votre *accountId* Compte AWS identifiant. La CLI GDK crée le bucket s'il n'existe pas.
Si vous utilisez la CLI GDK v1.2.0 ou une version ultérieure, vous pouvez remplacer ce qui est Région AWS spécifié dans le fichier de configuration de la CLI GDK à l'aide du paramètre. `--region` Vous pouvez également définir des options supplémentaires à l'aide du `--options` paramètre. Pour obtenir la liste des options disponibles, consultez[Fichier de configuration CLI du Greengrass Development Kit](gdk-cli-configuration-file.md).
Lorsque vous exécutez cette commande, la CLI GDK publie le composant avec la version que vous spécifiez dans la recette. Si vous le spécifiez`NEXT_PATCH`, la CLI GDK utilise la prochaine version du correctif qui n'existe pas encore. Les versions sémantiques utilisent une *majeure*. *mineur*. système de numérotation des *patchs*. Pour plus d'informations, consultez la [spécification de version sémantique](https://semver.org/).
**Note**
Si vous utilisez la CLI GDK v1.1.0 ou une version ultérieure, lorsque vous exécutez cette commande, la CLI GDK vérifie si le composant est créé. Si le composant n'est pas créé, la CLI GDK [le construit](#greengrass-development-kit-cli-component-build) avant de le publier.
**Résumé**
```
$ gdk component publish
[--bucket] [--region] [--options]
```
**Arguments**
+ `-b`, `--bucket` — (Facultatif) Spécifiez le nom du compartiment S3 dans lequel la CLI GDK publie les artefacts des composants.
Si vous ne spécifiez pas cet argument, la CLI GDK télécharge vers le compartiment S3 dont le nom est`bucket-region-accountId`, où *bucket* et *region* sont les valeurs que vous spécifiez`gdk-config.json`, ainsi que votre *accountId* Compte AWS identifiant. La CLI GDK crée le bucket s'il n'existe pas.
La CLI GDK crée le bucket s'il n'existe pas.
Cette fonctionnalité est disponible pour GDK CLI v1.1.0 et versions ultérieures.
+ `-r`, `--region` — (Facultatif) Spécifiez le nom du Région AWS to lorsque le composant est créé. Cet argument remplace le nom de la région dans la configuration de la CLI GDK.
Cette fonctionnalité est disponible pour GDK CLI v1.2.0 et versions ultérieures.
+ `-o`, `--options` (Facultatif) Spécifiez une liste d'options pour publier un composant. L'argument doit être une chaîne JSON valide ou un chemin de fichier vers un fichier JSON contenant les options de publication. Cet argument remplace les options de la configuration de la CLI GDK.
Cette fonctionnalité est disponible pour GDK CLI v1.2.0 et versions ultérieures.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ gdk component publish
[2021-11-29 13:45:29] INFO - Getting project configuration from gdk-config.json
[2021-11-29 13:45:29] INFO - Found component recipe file 'recipe.yaml' in the project directory.
[2021-11-29 13:45:29] INFO - Found credentials in shared credentials file: ~/.aws/credentials
[2021-11-29 13:45:30] INFO - Publishing the component 'com.example.PythonHelloWorld' with the given project configuration.
[2021-11-29 13:45:30] INFO - No private version of the component 'com.example.PythonHelloWorld' exist in the account. Using '1.0.0' as the next version to create.
[2021-11-29 13:45:30] INFO - Uploading the component built artifacts to s3 bucket.
[2021-11-29 13:45:30] INFO - Uploading component artifacts to S3 bucket: {bucket}. If this is your first time using this bucket, add the 's3:GetObject' permission to each core device's token exchange role to allow it to download the component artifacts. For more information, see https://docs.aws.amazon.com/greengrass/v2/developerguide/device-service-role.html.
[2021-11-29 13:45:30] INFO - Not creating an artifacts bucket as it already exists.
[2021-11-29 13:45:30] INFO - Updating the component recipe com.example.PythonHelloWorld-1.0.0.
[2021-11-29 13:45:30] INFO - Creating a new greengrass component com.example.PythonHelloWorld-1.0.0
[2021-11-29 13:45:30] INFO - Created private version '1.0.0' of the component in the account.'com.example.PythonHelloWorld'.
```
## liste
Récupérez la liste des modèles de composants et des composants communautaires disponibles.
La CLI GDK récupère les composants communautaires du [catalogue des logiciels Greengrass](greengrass-software-catalog.md) et les modèles de composants du référentiel de modèles de [AWS IoT Greengrass composants](https://github.com/aws-greengrass/aws-greengrass-component-templates) sur. GitHub
Vous pouvez transmettre le résultat de cette commande à la commande [init](#greengrass-development-kit-cli-component-init) pour initialiser les référentiels de composants à partir de modèles et de composants communautaires.
**Résumé**
```
$ gdk component list
[--template]
[--repository]
```
**Arguments**
+ `-t`, `--template` — (Facultatif) Spécifiez cet argument pour répertorier les modèles de composants disponibles. Cette commande affiche le nom et la langue de chaque modèle au format`name-language`. Par exemple, dans`HelloWorld-python`, le nom du modèle est `HelloWorld` et la langue est`python`.
+ `-r`, `--repository` — (Facultatif) Spécifiez cet argument pour répertorier les référentiels de composants communautaires disponibles.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ gdk component list --template
[2021-11-29 12:29:04] INFO - Listing all the available component templates from Greengrass Software Catalog.
[2021-11-29 12:29:04] INFO - Found '2' component templates to display.
1. HelloWorld-python
2. HelloWorld-java
```
# config
Utilisez la `config` commande de l'interface de ligne de commande du kit de AWS IoT Greengrass développement (CLI GDK) pour modifier la configuration du GDK dans le fichier de configuration,. `gdk-config.json`
**Topics**
+ [mise à jour](#greengrass-development-kit-cli-config-update)
## mise à jour
Lancez une invite interactive pour modifier les champs d'un fichier de configuration GDK existant.
**Résumé**
```
$ gdk config update
[--component]
```
**Arguments**
+ `-c`, `--component` — Pour mettre à jour les champs relatifs aux composants dans le `gdk-config.json` fichier. Cet argument est obligatoire car il s'agit de la seule option.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande pour configurer un composant.
```
$ gdk config update --component
Current value of the REQUIRED component_name is (default: com.example.PythonHelloWorld):
Current value of the REQUIRED author is (default: author):
Current value of the REQUIRED version is (default: NEXT_PATCH):
Do you want to change the build configurations? (y/n)
Do you want to change the publish configurations? (y/n)
[2023-09-26 10:19:48] INFO - Config file has been updated. Exiting...
```
# test-e2e
Utilisez la `test-e2e` commande de l'interface de ligne de commande du kit de AWS IoT Greengrass développement (CLI GDK) pour initialiser, créer et end-to-end exécuter des modules de test dans le projet GDK.
**Topics**
+ [init](#greengrass-development-kit-cli-test-init)
+ [build](#greengrass-development-kit-cli-test-build)
+ [run](#greengrass-development-kit-cli-test-run)
## init
Initialisez un projet GDK CLI existant avec un module de test qui utilise Greengrass Testing Framework (GTF).
Par défaut, la CLI GDK récupère le modèle de module maven depuis le référentiel de [modèles de AWS IoT Greengrass composants](https://github.com/aws-greengrass/aws-greengrass-component-templates) sur. GitHub Ce module maven est livré avec une dépendance au fichier `aws-greengrass-testing-standalone` JAR.
Cette commande crée un nouveau répertoire appelé `gg-e2e-tests` inside of the GDK project. Si le répertoire du module de test existe déjà et qu'il n'est pas vide, la commande s'arrête sans rien faire. Ce `gg-e2e-tests` dossier contient la fonctionnalité Cucumber et les définitions d'étapes structurées dans un projet Maven.
Par défaut, cette commande essaie d'utiliser la dernière version de GTF.
**Résumé**
```
$ gdk test-e2e init
[--gtf-version]
```
**Arguments**
+ `-ov`, `--gtf-version` — (Facultatif) Version du GTF à utiliser avec le module de end-to-end test dans le projet GDK. Cette valeur doit être l'une des versions GTF des [versions](https://github.com/aws-greengrass/aws-greengrass-testing/releases). Cet argument remplace celui de la configuration `gtf_version` de la CLI GDK.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande pour initialiser le projet GDK avec le module de test.
```
$ gdk test-e2e init
[2023-12-06 12:20:28] INFO - Using the GTF version provided in the GDK test config 1.2.0
[2023-12-06 12:20:28] INFO - Downloading the E2E testing template from GitHub into gg-e2e-tests directory...
```
## build
**Note**
Vous devez créer le composant en l'exécutant **gdk component build** avant de créer le module de end-to-end test.
Créez le module end-to-end de test. La CLI GDK crée le module de test à l'aide du système de génération que vous spécifiez dans le [fichier de configuration de la CLI GDK](gdk-cli-configuration-file.md)`gdk-config.json`, sous la `test-e2e` propriété. Vous devez exécuter cette commande dans le dossier où se trouve le `gdk-config.json` fichier.
Par défaut, la CLI GDK utilise le système de construction maven pour créer le module de test. [Maven](https://maven.apache.org/) est requis pour exécuter la `gdk test-e2e build` commande.
Vous devez créer le composant en l'exécutant **gdk-component-build** avant de créer le module de test, si les fichiers de fonctionnalités de test contiennent des variables telles que `GDK_COMPONENT_NAME` et `GDK_COMPONENT_RECIPE_FILE` à interpoler.
Lorsque vous exécutez cette commande, la CLI GDK interpole toutes les variables de la configuration du projet GDK et crée le `gg-e2e-tests` module pour générer le fichier JAR de test final.
**Résumé**
```
$ gdk test-e2e build
```
**Arguments**
Aucun
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ gdk test-e2e build
[2023-07-20 15:36:48] INFO - Updating feature file: file:///path/to//HelloWorld/greengrass-build/gg-e2e-tests/src/main/resources/greengrass/features/component.feature
[2023-07-20 15:36:48] INFO - Creating the E2E testing recipe file:///path/to/HelloWorld/greengrass-build/recipes/e2e_test_recipe.yaml
[2023-07-20 15:36:48] INFO - Building the E2E testing module
[2023-07-20 15:36:48] INFO - Running the build command 'mvn package'
.........
```
## run
Exécutez le module de test avec les options de test du fichier de configuration GDK.
**Note**
Vous devez créer le module de test en l'exécutant **gdk test-e2e build** avant d'exécuter les end-to-end tests.
**Résumé**
```
$ gdk test-e2e run
[--gtf-options]
```
**Arguments**
+ `-oo`, `--gtf-options` — (Facultatif) Spécifiez une liste d'options pour exécuter les end-to-end tests. L'argument doit être une chaîne JSON valide ou un chemin de fichier vers un fichier JSON contenant les options GTF. Les options fournies dans le fichier de configuration sont fusionnées avec celles fournies dans les arguments de commande. Si une option est présente aux deux endroits, celle en argument a priorité sur celle du fichier de configuration.
Si l'`tags`option n'est pas spécifiée dans cette commande, GDK l'utilise `Sample` pour les balises. Si `ggc-archive` ce n'est pas spécifié, GDK télécharge la dernière version de l'archive Greengrass nucleus.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ gdk test-e2e run
[2023-07-20 16:35:53] INFO - Downloading latest nucleus archive from url https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-latest.zip
[2023-07-20 16:35:57] INFO - Running test jar with command java -jar /path/to/greengrass-build/gg-e2e-tests/target/uat-features-1.0.0.jar —ggc-archive=/path/to/aws-greengrass-gdk-cli/HelloWorld/greengrass-build/greengrass-nucleus-latest.zip —tags=Sample
16:35:59.693 [] [] [] [INFO] com.aws.greengrass.testing.modules.GreengrassContextModule - Extracting /path/to/workplace/aws-greengrass-gdk-cli/HelloWorld/greengrass-build/greengrass-nucleus-latest.zip into /var/folders/7g/ltzcb_3s77nbtmkzfb6brwv40000gr/T/gg-testing-7718418114158172636/greengrass
16:36:00.534 [gtf-1.1.0-SNAPSHOT] [] [] [INFO] com.aws.greengrass.testing.features.LoggerSteps - GTF Version is gtf-1.1.0-SNAPSHOT
.......
```
# Fichier de configuration CLI du Greengrass Development Kit
L'interface de ligne de commande du kit de AWS IoT Greengrass développement (CLI GDK) lit un fichier de configuration `gdk-config.json` nommé pour créer et publier des composants. Ce fichier de configuration doit exister à la racine du référentiel de composants. Vous pouvez utiliser la [commande d'initialisation](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-init) de la CLI GDK pour initialiser les référentiels de composants avec ce fichier de configuration.
**Topics**
+ [Format de fichier de configuration GDK CLI](#gdk-config-format)
+ [Exemples de fichiers de configuration GDK CLI](#gdk-config-examples)
## Format de fichier de configuration GDK CLI
Lorsque vous définissez un fichier de configuration GDK CLI pour un composant, vous spécifiez les informations suivantes au format JSON.
`gdk_version`
Version minimale de la CLI GDK compatible avec ce composant. Cette valeur doit être l'une des versions de la CLI GDK des [versions](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases).
`component`
Configuration de ce composant.
`componentName`
`author`
L'auteur ou l'éditeur du composant.
`version`
Version du composant. Spécifiez l’un des éléments suivants :
+ `NEXT_PATCH`— Lorsque vous choisissez cette option, la CLI GDK définit la version lorsque vous publiez le composant. La CLI GDK interroge le AWS IoT Greengrass service pour identifier la dernière version publiée du composant. Ensuite, il définit la version sur la version de correctif suivante après cette version. Si vous n'avez jamais publié le composant auparavant, la CLI GDK utilise la version`1.0.0`.
Si vous choisissez cette option, vous ne pouvez pas utiliser la [CLI Greengrass](greengrass-cli-component.md) pour déployer et tester localement le composant sur votre ordinateur de développement local qui exécute le logiciel AWS IoT Greengrass Core. Pour activer les déploiements locaux, vous devez plutôt spécifier une version sémantique.
+ Une version sémantique, telle que**1.0.0**. Les versions sémantiques utilisent une *majeure*. *mineur*. système de numérotation des *patchs*. Pour plus d'informations, consultez la [spécification de version sémantique](https://semver.org/).
Si vous développez des composants sur un appareil principal Greengrass sur lequel vous souhaitez les déployer et les tester, choisissez cette option. Vous devez créer le composant avec une version spécifique pour créer des déploiements locaux avec la CLI [Greengrass](greengrass-cli-component.md).
`build`
Configuration à utiliser pour intégrer la source de ce composant en artefacts. Cet objet contient les informations suivantes :
`build_system`
Le système de compilation à utiliser. Sélectionnez parmi les options suivantes :
+ `zip`— Regroupe le dossier du composant dans un fichier ZIP à définir comme seul artefact du composant. Choisissez cette option pour les types de composants suivants :
+ Composants utilisant des langages de programmation interprétés, tels que Python ou JavaScript.
+ Composants qui empaquetent des fichiers autres que du code, tels que des modèles d'apprentissage automatique ou d'autres ressources.
La CLI GDK compresse le dossier du composant dans un fichier zip portant le même nom que le dossier du composant. Par exemple, si le nom du dossier du composant est`HelloWorld`, la CLI GDK crée un fichier zip nommé`HelloWorld.zip`.
**Note**
Si vous utilisez la version 1.0.0 de la CLI GDK sur un appareil Windows, les noms des dossiers de composants et des fichiers zip ne doivent contenir que des lettres minuscules.
Lorsque la CLI GDK comprime le dossier du composant dans un fichier zip, elle ignore les fichiers suivants :
+ le fichier `gdk-config.json` ;
+ Le fichier de recette (`recipe.json`ou`recipe.yaml`)
+ Créez des dossiers, tels que `greengrass-build`
+ `maven`— Exécute la `mvn clean package` commande pour intégrer la source du composant en artefacts. Choisissez cette option pour les composants qui utilisent [Maven](https://maven.apache.org/), tels que les composants Java.
Sur les appareils Windows, cette fonctionnalité est disponible pour GDK CLI v1.1.0 et versions ultérieures.
+ `gradle`— Exécute la `gradle build` commande pour intégrer la source du composant en artefacts. Choisissez cette option pour les composants qui utilisent [Gradle](https://gradle.org/). Cette fonctionnalité est disponible pour GDK CLI v1.1.0 et versions ultérieures.
Le système de `gradle` construction prend en charge Kotlin DSL en tant que fichier de construction. Cette fonctionnalité est disponible pour GDK CLI v1.2.0 et versions ultérieures.
+ `gradlew`— Exécute la `gradlew` commande pour intégrer la source du composant en artefacts. Choisissez cette option pour les composants qui utilisent le [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html).
Cette fonctionnalité est disponible pour GDK CLI v1.2.0 et versions ultérieures.
+ `custom`— Exécute une commande personnalisée pour intégrer la source du composant dans une recette et des artefacts. Spécifiez la commande personnalisée dans le `custom_build_command` paramètre.
`custom_build_command`
(Facultatif) La commande de construction personnalisée à exécuter pour un système de génération personnalisé. Vous devez spécifier ce paramètre si vous spécifiez `custom` pour`build_system`.
Cette commande doit créer une recette et des artefacts dans les dossiers suivants du dossier des composants. La CLI GDK crée ces dossiers pour vous lorsque vous exécutez la [commande component build](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build).
+ Dossier de recettes : `greengrass-build/recipes`
+ Dossier Artifacts : `greengrass-build/artifacts/componentName/componentVersion`
Remplacez *componentName* par le nom du composant et remplacez *componentVersion* par la version du composant ou`NEXT_PATCH`.
Vous pouvez spécifier une chaîne unique ou une liste de chaînes, chaque chaîne étant un mot dans la commande. Par exemple, pour exécuter une commande de génération personnalisée pour un composant C\$1\$1, vous pouvez spécifier **cmake --build build --config Release** ou**["cmake", "--build", "build", "--config", "Release"]**.
Pour voir un exemple de système de construction personnalisé, consultez le [aws.greengrass.labs.LocalWebServer community component sur GitHub](https://github.com/awslabs/aws-greengrass-labs-local-web-server).
`options`
(Facultatif) Options de configuration supplémentaires utilisées pendant le processus de création du composant.
Cette fonctionnalité est disponible pour GDK CLI v1.2.0 et versions ultérieures.
`excludes`
Liste de modèles globaux qui définissent les fichiers à exclure du répertoire des composants lors de la création du fichier zip. Valable uniquement lorsque `build_system` c'est le cas`zip`.
Dans les versions 1.4.0 et antérieures de la CLI GDK, tout fichier correspondant à une entrée de la liste des exclusions est exclu de tous les sous-répertoires du composant. Pour obtenir le même comportement dans les versions 1.5.0 et ultérieures de la CLI GDK, ajoutez les `**/` entrées existantes dans la liste des exclusions. Par exemple, `*.txt` exclura les fichiers texte du répertoire uniquement ; `**/*.txt` exclura les fichiers texte de tous les répertoires et sous-répertoires.
Dans les versions 1.5.0 et ultérieures de la CLI GDK, vous pouvez voir un avertissement lors de la création du composant lorsque cela `excludes` est défini dans le fichier de configuration GDK. Pour désactiver cet avertissement, définissez la variable `GDK_EXCLUDES_WARN_IGNORE` d'environnement sur`true`.
La CLI GDK exclut toujours les fichiers suivants du fichier zip :
+ le fichier `gdk-config.json` ;
+ Le fichier de recette (`recipe.json`ou`recipe.yaml`)
+ Créez des dossiers, tels que `greengrass-build`
Les fichiers suivants sont exclus par défaut. Cependant, vous pouvez contrôler lesquels de ces fichiers sont exclus à l'aide de `excludes` cette option.
+ Tout dossier commençant par le préfixe « test » () `test*`
+ Tous les fichiers cachés
+ Le dossier `node_modules`
Si vous spécifiez l'`excludes`option, la CLI GDK exclut uniquement les fichiers que vous avez définis avec l'`excludes`option. Si vous ne spécifiez pas `excludes` cette option, la CLI GDK exclut les fichiers et dossiers par défaut indiqués précédemment.
`zip_name`
Le nom du fichier zip à utiliser lorsque vous créez un artefact zip pendant le processus de génération. Valable uniquement lorsque `build_system` c'est le cas`zip`. Si le `build_system` champ est vide, le nom du composant est utilisé pour le nom du fichier zip.
`publish`
Configuration à utiliser pour publier ce composant sur le AWS IoT Greengrass service.
Si vous utilisez la CLI GDK v1.1.0 ou une version ultérieure, vous pouvez spécifier l'`--bucket`argument pour spécifier le compartiment S3 dans lequel la CLI GDK télécharge les artefacts du composant. Si vous ne spécifiez pas cet argument, la CLI GDK télécharge vers le compartiment S3 dont le nom est`bucket-region-accountId`, où *bucket* et *region* sont les valeurs que vous spécifiez`gdk-config.json`, ainsi que votre *accountId* Compte AWS identifiant. La CLI GDK crée le bucket s'il n'existe pas.
Cet objet contient les informations suivantes :
`bucket`
Le nom du compartiment S3 à utiliser pour héberger les artefacts du composant.
`region`
L' Région AWS endroit où la CLI GDK publie ce composant.
Cette propriété est facultative si vous utilisez GDK CLI v1.3.0 ou version ultérieure.
`options`
(Facultatif) Options de configuration supplémentaires utilisées lors de la création de la version du composant.
Cette fonctionnalité est disponible pour GDK CLI v1.2.0 et versions ultérieures.
`file_upload_args`
Structure JSON contenant des arguments envoyés à Amazon S3 lors du chargement de fichiers dans un compartiment, tels que des métadonnées et des mécanismes de chiffrement. Pour une liste des arguments autorisés, consultez la [https://boto3.amazonaws.com/v1/documentation/api/latest/reference/customizations/s3.html#boto3.s3.transfer.S3Transfer.ALLOWED_UPLOAD_ARGS](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/customizations/s3.html#boto3.s3.transfer.S3Transfer.ALLOWED_UPLOAD_ARGS)classe dans la documentation de *Boto3*. .
`test-e2e`
(Facultatif) Configuration à utiliser lors du end-to-end test du composant. Cette fonctionnalité est disponible pour GDK CLI v1.3.0 et versions ultérieures.
`build`
`build_system`— Le système de construction à utiliser. L'option par défaut est`maven`. Sélectionnez parmi les options suivantes :
+ `maven`— Exécute la `mvn package` commande pour créer le module de test. Choisissez cette option pour créer le module de test qui utilise [Maven](https://maven.apache.org/).
+ `gradle`— Exécute la `gradle build` commande pour créer le module de test. Choisissez cette option pour le module de test qui utilise [Gradle](https://gradle.org/).
`gtf_version`
(Facultatif) Version du Greengrass Testing Framework (GTF) à utiliser comme dépendance du module de end-to-end test lorsque vous initialisez le projet GDK avec GTF. Cette valeur doit être l'une des versions GTF des [versions](https://github.com/aws-greengrass/aws-greengrass-testing/releases). La valeur par défaut est GTF version 1.1.0.
`gtf_options`
(Facultatif) Options de configuration supplémentaires utilisées lors du end-to-end test du composant.
La liste suivante inclut les options que vous pouvez utiliser avec la version 1.1.0 de GTF.
+ `additional-plugins`— (Facultatif) Plugins Cucumber supplémentaires
+ `aws-region`— Cible des points de terminaison régionaux spécifiques pour les AWS services. La valeur par défaut correspond à ce que le AWS SDK découvre.
+ `credentials-path`— Chemin d'accès facultatif aux informations d'identification du AWS profil. Par défaut, ce sont les informations d'identification découvertes sur l'environnement hôte.
+ `credentials-path-rotation`— Durée de rotation facultative pour les AWS informations d'identification. La valeur par défaut est de 15 minutes ou`PT15M`.
+ `csr-path`— Le chemin du CSR à l'aide duquel le certificat de l'appareil sera généré.
+ `device-mode`— L'appareil cible en cours de test. Par défaut, il s'agit d'un appareil local.
+ `env-stage`— Cible l'environnement de déploiement de Greengrass. Par défaut, c'est la production.
+ `existing-device-cert-arn`— L'ARN d'un certificat existant que vous souhaitez utiliser comme certificat d'appareil pour Greengrass.
+ `feature-path`— Fichier ou répertoire contenant des fichiers de fonctionnalités supplémentaires. Par défaut, aucun fichier de fonctionnalités supplémentaire n'est utilisé.
+ `gg-cli-version`— Remplace la version de la CLI Greengrass. La valeur par défaut est celle trouvée dans. `ggc.version`
+ `gg-component-bucket`— Le nom d'un compartiment Amazon S3 existant qui héberge les composants Greengrass.
+ `gg-component-overrides`— Liste des remplacements de composants Greengrass.
+ `gg-persist`— Liste des éléments de test à conserver après un essai. Le comportement par défaut est de ne rien conserver. Les valeurs acceptées sont : `aws.resources``installed.software`, et`generated.files`.
+ `gg-runtime`— Une liste de valeurs destinées à influencer la manière dont le test interagit avec les ressources de test. Ces valeurs remplacent le paramètre. `gg.persist` Si la valeur par défaut est vide, cela suppose que toutes les ressources de test sont gérées par scénario de test, y compris le moteur d'exécution Greengrass installé. Les valeurs acceptées sont : `aws.resources``installed.software`, et`generated.files`.
+ `ggc-archive`— Le chemin d'accès au composant du noyau Greengrass archivé.
+ `ggc-install-root`— Répertoire pour installer le composant Greengrass nucleus. La valeur par défaut est test.temp.path et le dossier test run.
+ `ggc-log-level`— Définissez le niveau logarithmique du noyau Greengrass pour le test. La valeur par défaut est « INFO ».
+ `ggc-tes-rolename`— Le rôle IAM que AWS IoT Greengrass Core assumera pour accéder aux AWS services. Si aucun rôle portant un nom donné n'existe, un rôle sera créé avec une politique d'accès par défaut.
+ `ggc-trusted-plugins`— La liste séparée par des virgules des chemins (sur l'hôte) des plugins fiables qui doivent être ajoutés à Greengrass. Pour fournir le chemin sur le DUT lui-même, préfixez-le par « dut : »
+ `ggc-user-name`— La valeur POSIXUser user:group pour le noyau Greengrass. La valeur par défaut est le nom d'utilisateur actuel connecté.
+ `ggc-version`— Remplace la version du composant Greengrass nucleus en cours d'exécution. La valeur par défaut est celle trouvée dans ggc.archive.
+ `log-level`— Niveau de journalisation du test. La valeur par défaut est « INFO ».
+ `parallel-config`— Ensemble d'index de lots et de nombre de lots sous forme de chaîne JSON. La valeur par défaut de l'index des lots est 0 et le nombre de lots est 1.
+ `proxy-url`— Configurez tous les tests pour acheminer le trafic via cette URL.
+ `tags`— Exécutez uniquement des balises de fonctionnalité. Peut être intersecté avec « & »
+ `test-id-prefix`— Un préfixe commun appliqué à toutes les ressources spécifiques au test, y compris les noms de AWS ressources et les balises. Le préfixe par défaut est « gg ».
+ `test-log-path`— Répertoire qui contiendra les résultats de l'ensemble du test. La valeur par défaut est « TestResults ».
+ `test-results-json`— Indicateur permettant de déterminer si le rapport Cucumber JSON résultant est généré écrit sur le disque. La valeur par défaut est true (vrai).
+ `test-results-log`— Indicateur permettant de déterminer si la sortie de console est générée écrite sur le disque. La valeur par défaut est false.
+ `test-results-xml`— Indicateur permettant de déterminer si le rapport JUnit XML obtenu est généré et écrit sur le disque. La valeur par défaut est true (vrai).
+ `test-temp-path`— Répertoire pour générer des artefacts de test locaux. La valeur par défaut est un répertoire temporaire aléatoire préfixé par gg-testing.
+ `timeout-multiplier`— Multiplicateur fourni à tous les délais d'expiration des tests. La valeur par défaut est 1,0.
## Exemples de fichiers de configuration GDK CLI
Vous pouvez vous référer aux exemples de fichiers de configuration de la CLI GDK suivants pour vous aider à configurer les environnements de composants Greengrass.
### Bonjour tout le monde (Python)
Le fichier de configuration de la CLI GDK suivant prend en charge un composant Hello World qui exécute un script Python. Ce fichier de configuration utilise le système de `zip` compilation pour empaqueter le script Python du composant dans un fichier ZIP que la CLI GDK télécharge sous forme d'artefact.
```
{
"component": {
"com.example.PythonHelloWorld": {
"author": "Amazon",
"version": "NEXT_PATCH",
"build": {
"build_system" : "zip",
"options": {
"excludes": [".*"]
}
},
"publish": {
"bucket": "greengrass-component-artifacts",
"region": "us-west-2",
"options": {
"file_upload_args": {
"Metadata": {
"some-key": "some-value"
}
}
}
}
},
"test-e2e":{
"build":{
"build_system": "maven"
},
"gtf_version": "1.1.0",
"gtf_options": {
"tags": "Sample"
}
},
"gdk_version": "1.6.1"
}
}
```
### Bonjour tout le monde (Java)
Le fichier de configuration GDK CLI suivant prend en charge un composant Hello World qui exécute une application Java. Ce fichier de configuration utilise le système de `maven` compilation pour empaqueter le code source Java du composant dans un fichier JAR que la CLI GDK télécharge sous forme d'artefact.
```
{
"component": {
"com.example.JavaHelloWorld": {
"author": "Amazon",
"version": "NEXT_PATCH",
"build": {
"build_system" : "maven"
},
"publish": {
"bucket": "greengrass-component-artifacts",
"region": "us-west-2",
"options": {
"file_upload_args": {
"Metadata": {
"some-key": "some-value"
}
}
}
}
},
"test-e2e":{
"build":{
"build_system": "maven"
},
"gtf_version": "1.1.0",
"gtf_options": {
"tags": "Sample"
}
},
"gdk_version": "1.6.1"
}
}
```
### Composantes communautaires
Plusieurs composants communautaires du [catalogue de logiciels Greengrass](greengrass-software-catalog.md) utilisent la CLI GDK. Vous pouvez explorer les fichiers de configuration de la CLI GDK dans les référentiels de ces composants.
**Pour afficher les fichiers de configuration de la CLI GDK des composants de la communauté**
1. Exécutez la commande suivante pour répertorier les composants de la communauté qui utilisent la CLI GDK.
```
gdk component list --repository
```
La réponse indique le nom du GitHub référentiel pour chaque composant de communauté qui utilise la CLI GDK. Chaque référentiel existe au sein de l'`awslabs`organisation.
```
[2022-02-22 17:27:31] INFO - Listing all the available component repositories from Greengrass Software Catalog.
[2022-02-22 17:27:31] INFO - Found '6' component repositories to display.
1. aws-greengrass-labs-database-influxdb
2. aws-greengrass-labs-telemetry-influxdbpublisher
3. aws-greengrass-labs-dashboard-grafana
4. aws-greengrass-labs-dashboard-influxdb-grafana
5. aws-greengrass-labs-local-web-server
6. aws-greengrass-labs-lookoutvision-gstreamer
```
1. Ouvrez le GitHub référentiel d'un composant communautaire à l'adresse URL suivante. Remplacez *community-component-name* par le nom d'un composant communautaire de l'étape précédente.
```
https://github.com/awslabs/community-component-name
```
# Interface de ligne de commande Greengrass
L'interface de ligne de commande (CLI) Greengrass vous permet d'interagir avec AWS IoT Greengrass Core sur votre appareil pour développer des composants et résoudre des problèmes localement. Par exemple, vous pouvez utiliser la CLI Greengrass pour créer un déploiement local et redémarrer un composant sur le périphérique principal.
Déployez le [composant Greengrass CLI](greengrass-cli-component.md) (`aws.greengrass.Cli`) pour installer la Greengrass CLI sur votre appareil principal.
**Important**
Nous vous recommandons d'utiliser ce composant uniquement dans les environnements de développement, et non dans les environnements de production. Ce composant permet d'accéder aux informations et aux opérations dont vous n'avez généralement pas besoin dans un environnement de production. Suivez le principe du moindre privilège en déployant ce composant uniquement sur les appareils principaux là où vous en avez besoin.
**Topics**
+ [Installation de la CLI Greengrass](install-gg-cli.md)
+ [Commandes Greengrass CLI](gg-cli-reference.md)
# Installation de la CLI Greengrass
Vous pouvez installer la CLI Greengrass de l'une des manières suivantes :
+ Utilisez `--deploy-dev-tools` cet argument lorsque vous configurez le logiciel AWS IoT Greengrass Core pour la première fois sur votre appareil. Vous devez également spécifier `--provision true` d'appliquer cet argument.
+ Déployez le composant Greengrass CLI (`aws.greengrass.Cli`) sur votre appareil.
Cette section décrit les étapes de déploiement du composant Greengrass CLI. Pour plus d'informations sur l'installation de la CLI Greengrass lors de la configuration initiale, consultez. [Tutoriel : Débuter avec AWS IoT Greengrass V2](getting-started.md)
## Conditions préalables
Pour déployer le composant Greengrass CLI, vous devez répondre aux exigences suivantes :
+ AWS IoT Greengrass Logiciel de base installé et configuré sur votre appareil principal. Pour de plus amples informations, veuillez consulter [Tutoriel : Débuter avec AWS IoT Greengrass V2](getting-started.md).
+ Pour utiliser le AWS CLI pour déployer la Greengrass CLI, vous devez avoir installé et configuré le. AWS CLI Pour plus d'informations, veuillez consulter [configuration de l'outil AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) dans le *guide de l'utilisateur de l'outil AWS Command Line Interface *.
+ Vous devez être autorisé à utiliser la CLI Greengrass pour interagir avec le logiciel AWS IoT Greengrass principal. Pour utiliser la CLI Greengrass, effectuez l'une des opérations suivantes :
+ Utilisez l'utilisateur du système qui exécute le logiciel AWS IoT Greengrass Core.
+ Utilisez un utilisateur doté d'autorisations root ou administratives. Sur les appareils principaux de Linux, vous pouvez l'utiliser `sudo` pour obtenir des autorisations root.
+ Utilisez un utilisateur système appartenant à un groupe que vous spécifiez dans les paramètres de `AuthorizedWindowsGroups` configuration `AuthorizedPosixGroups` ou lorsque vous déployez le composant. Pour plus d'informations, consultez la section Configuration des [composants de la CLI Greengrass](greengrass-cli-component.md#greengrass-cli-component-configuration).
## Déployer le composant Greengrass CLI
Procédez comme suit pour déployer le composant Greengrass CLI sur votre appareil principal :
### Pour déployer le composant Greengrass CLI (console)
1. Connectez-vous à la [console AWS IoT Greengrass](https://console.aws.amazon.com/greengrass).
1. Dans le menu de navigation, sélectionnez **Composants**.
1. Sur la page **Components (Composants)**, sous l'onglet **Public components (Composants publics)**, choisissez `aws.greengrass.Cli`.
1. Sur la page **aws.greengrass.Cli**, choisissez **Deploy (Déployer)**.
1. Dans **Ajouter au déploiement**, choisissez **Créer un nouveau déploiement**.
1. **Sur la page **Spécifier la cible**, sous **Cibles de déploiement**, dans la liste **Nom de la cible**, choisissez le groupe Greengrass vers lequel vous souhaitez effectuer le déploiement, puis cliquez sur Next.**
1. Sur la page **Sélectionner les composants**, vérifiez que le **aws.greengrass.Cli**composant est sélectionné, puis choisissez **Next**.
1. Sur la page **Configurer les composants**, conservez les paramètres de configuration par défaut et choisissez **Next**.
1. Sur la page **Configurer les paramètres avancés**, conservez les paramètres de configuration par défaut et choisissez **Next**.
1. Sur la page de **révision**, cliquez sur **Déployer**
### Pour déployer le composant Greengrass CLI ()AWS CLI
1. Sur votre appareil, créez un `deployment.json` fichier pour définir la configuration de déploiement du composant Greengrass CLI. Ce fichier doit ressembler à ce qui suit :
```
{
"targetArn":"targetArn",
"components": {
"aws.greengrass.Cli": {
"componentVersion": "2.17.0",
"configurationUpdate": {
"merge": "{\"AuthorizedPosixGroups\":\",,...,\",\"AuthorizedWindowsGroups\":\",,...,\"}"
}
}
}
}
```
+ Dans le champ `target`, remplacez `targetArn` par l'Amazon Resource Name (ARN) de l'objet ou du groupe d'objets à cibler pour le déploiement, au format suivant :
+ Objet : `arn:aws:iot:region:account-id:thing/thingName`
+ Groupe d'objets : `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
+ Dans l'objet `aws.greengrass.Cli` composant, spécifiez les valeurs comme suit :
`version`
Version du composant Greengrass CLI.
`configurationUpdate.AuthorizedPosixGroups`
(Facultatif) Chaîne contenant une liste de groupes de systèmes séparés par des virgules. Vous autorisez ces groupes de systèmes à utiliser la CLI Greengrass pour interagir avec le logiciel AWS IoT Greengrass principal. Vous pouvez spécifier des noms de groupes ou des groupes IDs. Par exemple, `group1,1002,group3` autorise trois groupes de systèmes (`group1``1002`, et`group3`) à utiliser la CLI Greengrass.
Si vous ne spécifiez aucun groupe à autoriser, vous pouvez utiliser la CLI Greengrass en tant qu'utilisateur root (`sudo`) ou en tant qu'utilisateur système qui exécute le logiciel AWS IoT Greengrass Core.
`configurationUpdate.AuthorizedWindowsGroups`
(Facultatif) Chaîne contenant une liste de groupes de systèmes séparés par des virgules. Vous autorisez ces groupes de systèmes à utiliser la CLI Greengrass pour interagir avec le logiciel AWS IoT Greengrass principal. Vous pouvez spécifier des noms de groupes ou des groupes IDs. Par exemple, `group1,1002,group3` autorise trois groupes de systèmes (`group1``1002`, et`group3`) à utiliser la CLI Greengrass.
Si vous ne spécifiez aucun groupe à autoriser, vous pouvez utiliser la CLI Greengrass en tant qu'administrateur ou en tant qu'utilisateur du système qui exécute le logiciel AWS IoT Greengrass principal.
1. Exécutez la commande suivante pour déployer le composant Greengrass CLI sur le périphérique :
```
$ aws greengrassv2 create-deployment --cli-input-json file://path/to/deployment.json
```
Pendant l'installation, le composant ajoute un lien symbolique `greengrass-cli` dans le `/greengrass/v2/bin` dossier de votre appareil, et vous exécutez la CLI Greengrass à partir de ce chemin. Pour exécuter la CLI Greengrass sans son chemin absolu, ajoutez votre `/greengrass/v2/bin` dossier à votre variable PATH. Pour vérifier l'installation de Greengrass CLI, exécutez la commande suivante :
------
#### [ Linux or Unix ]
```
/greengrass/v2/bin/greengrass-cli help
```
------
#### [ Windows ]
```
C:\greengrass\v2\bin\greengrass-cli help
```
------
Vous devriez voir la sortie suivante :
```
Usage: greengrass-cli [-hV] [--ggcRootPath=] [COMMAND]
Greengrass command line interface
--ggcRootPath=
The AWS IoT Greengrass V2 root directory.
-h, --help Show this help message and exit.
-V, --version Print version information and exit.
Commands:
help Show help information for a command.
component Retrieve component information and stop or restart
components.
deployment Create local deployments and retrieve deployment status.
logs Analyze Greengrass logs.
get-debug-password Generate a password for use with the HTTP debug view
component.
```
S'il `greengrass-cli` n'est pas trouvé, le déploiement n'a peut-être pas réussi à installer la CLI Greengrass. Pour de plus amples informations, veuillez consulter [Résolution des problèmes AWS IoT Greengrass V2](troubleshooting.md).
# Commandes Greengrass CLI
La CLI Greengrass fournit une interface de ligne de commande pour interagir localement avec votre appareil AWS IoT Greengrass principal. Les commandes Greengrass CLI utilisent le format suivant.
```
$ greengrass-cli [arguments]
```
Par défaut, le fichier `greengrass-cli` exécutable du `/greengrass/v2/bin/` dossier interagit avec la version du logiciel AWS IoT Greengrass Core exécutée dans le `/greengrass/v2` dossier. Si vous appelez un exécutable qui n'est pas placé à cet emplacement, ou si vous souhaitez interagir avec le logiciel AWS IoT Greengrass Core à un autre emplacement, vous devez utiliser l'une des méthodes suivantes pour spécifier explicitement le chemin racine du logiciel AWS IoT Greengrass Core avec lequel vous souhaitez interagir :
+ Définissez la variable d'environnement `GGC_ROOT_PATH` sur `/greengrass/v2`.
+ Ajoutez l'`--ggcRootPath /greengrass/v2`argument à votre commande comme indiqué dans l'exemple suivant.
```
greengrass-cli --ggcRootPath /greengrass/v2 [arguments]
```
Vous pouvez utiliser les arguments suivants avec n'importe quelle commande :
+ À utiliser `--help` pour obtenir des informations sur une commande Greengrass CLI spécifique.
+ À utiliser `--version` pour obtenir des informations sur la version de Greengrass CLI.
Cette section décrit les commandes de la CLI Greengrass et fournit des exemples de ces commandes. Le synopsis de chaque commande montre ses arguments et leur utilisation. Les arguments facultatifs sont indiqués entre crochets.
**Topics**
+ [composant](gg-cli-component.md)
+ [déploiement](gg-cli-deployment.md)
+ [journaux](gg-cli-logs.md)
+ [get-debug-password](gg-cli-get-debug-password.md)
# composant
Utilisez la `component` commande pour interagir avec les composants locaux de votre appareil principal.
**Sous-commandes**
+ [détails](#component-details)
+ [liste](#component-list)
+ [redémarrer](#component-restart)
+ [stop](#component-stop)
## détails
Récupérez la version, le statut et la configuration d'un composant.
**Résumé**
```
greengrass-cli component details --name
```
**Arguments**
`--name`,`-n`. Le nom du composant.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ sudo greengrass-cli component details --name MyComponent
Component Name: MyComponent
Version: 1.0.0
State: RUNNING
Configuration: null
```
## liste
Récupérez le nom, la version, l'état et la configuration de chaque composant installé sur le périphérique.
**Résumé**
```
greengrass-cli component list
```
**Arguments**
Aucun
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ sudo greengrass-cli component list
Components currently running in Greengrass:
Component Name: FleetStatusService
Version: 0.0.0
State: RUNNING
Configuration: {"periodicUpdateIntervalSec":86400.0}
Component Name: UpdateSystemPolicyService
Version: 0.0.0
State: RUNNING
Configuration: null
Component Name: aws.greengrass.Nucleus
Version: 2.0.0
State: FINISHED
Configuration: {"awsRegion":"region","runWithDefault":{"posixUser":"ggc_user:ggc_group"},"telemetry":{}}
Component Name: DeploymentService
Version: 0.0.0
State: RUNNING
Configuration: null
Component Name: TelemetryAgent
Version: 0.0.0
State: RUNNING
Configuration: null
Component Name: aws.greengrass.Cli
Version: 2.0.0
State: RUNNING
Configuration: {"AuthorizedPosixGroups":"ggc_user"}
```
## redémarrer
Redémarrez les composants.
**Résumé**
```
greengrass-cli component restart --names ,...
```
**Arguments**
`--names`,`-n`. Le nom du composant. Au moins un nom de composant est requis. Vous pouvez spécifier des noms de composants supplémentaires, en séparant chaque nom par une virgule.
**Sortie**
Aucun
## stop
Arrêtez d'exécuter les composants.
**Résumé**
```
greengrass-cli component stop --names ,...
```
**Arguments**
`--names`,`-n`. Le nom du composant. Au moins un nom de composant est requis. Vous pouvez spécifier des noms de composants supplémentaires si nécessaire, en séparant chaque nom par une virgule.
**Sortie**
Aucun
# déploiement
Utilisez la `deployment` commande pour interagir avec les composants locaux de votre appareil principal.
Pour suivre la progression d'un déploiement local, utilisez la `status` sous-commande. Vous ne pouvez pas suivre la progression d'un déploiement local à l'aide de la console.
**Sous-commandes**
+ [créer](#deployment-create)
+ [annuler](#deployment-cancel)
+ [liste](#deployment-list)
+ [status](#deployment-status)
## créer
Créez ou mettez à jour un déploiement local à l'aide de recettes de composants, d'artefacts et d'arguments d'exécution spécifiés.
**Résumé**
```
greengrass-cli deployment create
--recipeDir path/to/component/recipe
[--artifactDir path/to/artifact/folder ]
[--update-config {component-configuration}]
[--groupId ]
[--merge "="]...
[--runWith ":posixUser=[:]"]...
[--systemLimits "{component-system-resource-limits}]"]...
[--remove ,...]
[--failure-handling-policy ]
```
**Arguments**
+ `--recipeDir`,`-r`. Le chemin complet du dossier contenant les fichiers de recette des composants.
+ `--artifactDir`,`-a`. Le chemin complet du dossier contenant les fichiers d'artefacts que vous souhaitez inclure dans votre déploiement. Le dossier des artefacts doit contenir la structure de répertoire suivante :
```
/path/to/artifact/folder///
```
+ `--update-config`,`-c`. Les arguments de configuration pour le déploiement, fournis sous forme de chaîne JSON ou de fichier JSON. La chaîne JSON doit être au format suivant :
```
{ \
"componentName": { \
"MERGE": {"config-key": "config-value"}, \
"RESET": ["path/to/reset/"] \
} \
}
```
`MERGE`et `RESET` distinguent les majuscules des minuscules et doivent être en majuscules.
+ `--groupId`,`-g`. Le groupe d'objets cible pour le déploiement.
+ `--merge`,`-m`. Le nom et la version du composant cible que vous souhaitez ajouter ou mettre à jour. Vous devez fournir les informations du composant dans le format`=`. Utilisez un argument distinct pour chaque composant supplémentaire à spécifier. Si nécessaire, utilisez l'`--runWith`argument pour fournir les `windowsUser` informations `posixUser``posixGroup`, et pour exécuter le composant.
+ `--runWith`. Les `posixUser` `windowsUser` informations et relatives à l'exécution d'un composant générique ou Lambda. `posixGroup` Vous devez fournir ces informations dans le format`:{posixUser|windowsUser}=[:<=posixGroup>]`. Par exemple, vous pouvez spécifier **HelloWorld:posixUser=ggc\$1user:ggc\$1group** ou**HelloWorld:windowsUser=ggc\$1user**. Utilisez un argument distinct pour chaque option supplémentaire à spécifier.
Pour de plus amples informations, veuillez consulter [Configurer l'utilisateur qui exécute les composants](configure-greengrass-core-v2.md#configure-component-user).
+ `--systemLimits`. Les limites de ressources du système à appliquer aux processus des composants Lambda génériques et non conteneurisés sur le périphérique principal. Vous pouvez configurer la quantité maximale d'utilisation du processeur et de la RAM que les processus de chaque composant peuvent utiliser. Spécifiez un objet JSON sérialisé ou un chemin d'accès à un fichier JSON. L'objet JSON doit avoir le format suivant.
```
{ \
"componentName": { \
"cpus": cpuTimeLimit, \
"memory": memoryLimitInKb \
} \
}
```
Vous pouvez configurer les limites de ressources système suivantes pour chaque composant :
+ `cpus`— Le temps processeur maximal que les processus de ce composant peuvent utiliser sur le périphérique principal. Le temps processeur total d'un appareil principal est équivalent au nombre de cœurs processeurs de l'appareil. Par exemple, sur un périphérique principal doté de 4 cœurs de processeur, vous pouvez définir cette valeur `2` pour limiter les processus de ce composant à 50 % d'utilisation de chaque cœur de processeur. Sur un appareil doté d'un cœur de processeur, vous pouvez définir cette valeur `0.25` pour limiter les processus de ce composant à 25 % d'utilisation du processeur. Si vous définissez cette valeur sur un nombre supérieur au nombre de cœurs de processeur, le logiciel AWS IoT Greengrass Core ne limite pas l'utilisation du processeur par le composant.
+ `memory`— La quantité maximale de RAM (en kilo-octets) que les processus de ce composant peuvent utiliser sur le périphérique principal.
Pour de plus amples informations, veuillez consulter [Configuration des limites de ressources système pour les composants](configure-greengrass-core-v2.md#configure-component-system-resource-limits).
Cette fonctionnalité est disponible pour les versions 2.4.0 et ultérieures du [composant Greengrass nucleus et de la CLI Greengrass](greengrass-nucleus-component.md) sur les appareils principaux Linux. AWS IoT Greengrass ne prend actuellement pas en charge cette fonctionnalité sur les appareils Windows principaux.
+ `--remove`. Nom du composant cible que vous souhaitez supprimer d'un déploiement local. Si le composant définit une étape [du cycle de désinstallation](component-recipe-reference.md#uninstall-lifecycle-definition), le logiciel AWS IoT Greengrass Core exécute le script de désinstallation avant de supprimer le composant. Pour supprimer un composant qui a été fusionné d'un déploiement dans le cloud, vous devez fournir l'ID de groupe du groupe d'objets cible au format suivant :
------
#### [ Greengrass nucleus v2.4.0 and later ]
```
--remove --groupId
```
------
#### [ Earlier than v2.4.0 ]
```
--remove --groupId thinggroup/
```
------
+ `--failure-handling-policy`. Définit l'action entreprise en cas d'échec d'un déploiement. Vous pouvez définir deux actions :
+ `ROLLBACK` –
+ `DO_NOTHING` –
Cette fonctionnalité est disponible pour les versions 2.11.0 et ultérieures du. [Noyau de Greengrass](greengrass-nucleus-component.md)
**Sortie**
L’exemple suivant illustre la sortie produite lorsque vous exécutez cette commande.
```
$ sudo greengrass-cli deployment create \
--merge MyApp1=1.0.0 \
--merge MyApp2=1.0.0 --runWith MyApp2:posixUser=ggc_user \
--remove MyApp3 \
--recipeDir recipes/ \
--artifactDir artifacts/
Local deployment has been submitted! Deployment Id: 44d89f46-1a29-4044-ad89-5151213dfcbc
```
## annuler
Annule le déploiement spécifié.
Résumé
```
greengrass-cli deployment cancel
-i
```
Arguments
`-i`. Identifiant unique du déploiement à annuler. L'ID de déploiement est renvoyé dans la sortie de la `create` commande.
Output
+ Aucune
## liste
Récupérez l'état des 10 derniers déploiements locaux.
**Résumé**
```
greengrass-cli deployment list
```
**Arguments**
Aucun
**Sortie**
L’exemple suivant illustre la sortie produite lorsque vous exécutez cette commande. En fonction de l'état de votre déploiement, la sortie affiche l'une des valeurs d'état suivantes : `IN_PROGRESS``SUCCEEDED`, ou`FAILED`.
```
$ sudo greengrass-cli deployment list
44d89f46-1a29-4044-ad89-5151213dfcbc: SUCCEEDED
Created on: 6/27/23 11:05 AM
```
## status
Récupérez l'état d'un déploiement spécifique.
**Résumé**
```
greengrass-cli deployment status -i
```
**Arguments**
`-i`. ID du déploiement.
**Sortie**
L’exemple suivant illustre la sortie produite lorsque vous exécutez cette commande. En fonction de l'état de votre déploiement, la sortie affiche l'une des valeurs d'état suivantes : `IN_PROGRESS``SUCCEEDED`, ou`FAILED`.
```
$ sudo greengrass-cli deployment status -i 44d89f46-1a29-4044-ad89-5151213dfcbc
44d89f46-1a29-4044-ad89-5151213dfcbc: FAILED
Created on: 6/27/23 11:05 AM
Detailed Status:
Deployment Error Stack: List of error codes
Deployment Error Types: List of error types
Failure Cause: Cause
```
# journaux
Utilisez la `logs` commande pour analyser les journaux Greengrass sur votre appareil principal.
**Sous-commandes**
+ [get](#logs-get)
+ [listez les mots clés](#logs-list-keywords)
+ [list-log-files](#logs-list-log-files)
## get
Collectez, filtrez et visualisez les fichiers journaux de Greengrass. Cette commande prend uniquement en charge les fichiers journaux au format JSON. Vous pouvez spécifier le [format de journalisation](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-logging-format) dans la configuration du noyau.
**Résumé**
```
greengrass-cli logs get
[--log-dir path/to/a/log/folder]
[--log-file path/to/a/log/file]
[--follow true | false ]
[--filter ]
[--time-window , ]
[--verbose ]
[--no-color ]
[--before ]
[--after ]
[--syslog ]
[--max-long-queue-size ]
```
**Arguments**
+ `--log-dir`,`-ld`. Le chemin d'accès au répertoire dans lequel vérifier la présence de fichiers journaux, tels que**`/greengrass/v2`/logs**. Ne pas utiliser avec`--syslog`. Utilisez un argument distinct pour chaque répertoire supplémentaire à spécifier. Vous devez utiliser au moins l'un des `--log-dir` ou`--log-file`. Vous pouvez également utiliser les deux arguments dans une seule commande.
+ `--log-file`,`-lf`. Les chemins d'accès aux répertoires de journaux que vous souhaitez utiliser. Utilisez un argument distinct pour chaque répertoire supplémentaire à spécifier. Vous devez utiliser au moins l'un des `--log-dir` ou`--log-file`. Vous pouvez également utiliser les deux arguments dans une seule commande.
+ `--follow`,`-fol`. Afficher les mises à jour du journal dès qu'elles se produisent. Greengrass CLI continue de fonctionner et lit les journaux spécifiés. Si vous spécifiez une fenêtre temporelle, Greengrass CLI arrête de surveiller les journaux une fois toutes les fenêtres temporelles terminées.
+ `--filter`,`-f`. Le mot clé, les expressions régulières ou la paire clé-valeur à utiliser comme filtre. Fournissez cette valeur sous forme de chaîne, d'expression régulière ou de paire clé-valeur. Utilisez un argument distinct pour chaque filtre supplémentaire à spécifier.
Lors de l'évaluation, plusieurs filtres spécifiés dans un seul argument sont séparés par des opérateurs OR, et les filtres spécifiés dans des arguments supplémentaires sont combinés avec des opérateurs ET. Par exemple, si votre commande inclut`--filter "installed" --filter "name=alpha,name=beta"`, la CLI Greengrass filtrera et affichera les messages de journal contenant à la fois le mot clé `installed` et une `name` clé contenant les valeurs `alpha` ou. `beta`
+ `--time-window`,`-t`. La fenêtre temporelle pour laquelle les informations du journal doivent être affichées. Vous pouvez utiliser à la fois des horodatages exacts et des décalages relatifs. Vous devez fournir ces informations dans le format`,`. Si vous ne spécifiez ni l'heure de début ni l'heure de fin, la valeur de cette option est par défaut la date et l'heure actuelles du système. Utilisez un argument distinct pour chaque fenêtre temporelle supplémentaire à spécifier.
Greengrass CLI prend en charge les formats d'horodatage suivants :
+ `yyyy-MM-DD`, par exemple,`2020-06-30`. L'heure par défaut est 00:00:00 lorsque vous utilisez ce format.
`yyyyMMDD`, par exemple,`20200630`. L'heure par défaut est 00:00:00 lorsque vous utilisez ce format.
`HH:mm:ss`, par exemple,`15:30:45`. La date par défaut est la date système actuelle lorsque vous utilisez ce format.
`HH:mm:ssSSS`, par exemple,`15:30:45`. La date correspond par défaut à la date système actuelle lorsque vous utilisez ce format.
`YYYY-MM-DD'T'HH:mm:ss'Z'`, par exemple,`2020-06-30T15:30:45Z`.
`YYYY-MM-DD'T'HH:mm:ss`, par exemple,`2020-06-30T15:30:45`.
`yyyy-MM-dd'T'HH:mm:ss.SSS`, par exemple,`2020-06-30T15:30:45.250`.
Les décalages relatifs spécifient un décalage de période par rapport à l'heure actuelle du système. Greengrass CLI prend en charge le format suivant pour les décalages relatifs :. `+|-[h|hr|hours][valuem|min|minutes][value]s|sec|seconds`
Par exemple, l'argument suivant pour spécifier une fenêtre horaire comprise entre 1 heure et 2 heures 15 minutes avant l'heure actuelle`--time-window -2h15min,-1hr`.
+ `--verbose`. Afficher tous les champs des messages du journal. Ne pas utiliser avec`--syslog`.
+ `--no-color`,`-nc`. Supprimez le code couleur. Le code couleur par défaut pour les messages du journal utilise du texte rouge en gras. Supporte uniquement les terminaux de type Unix car il utilise des séquences d'échappement ANSI.
+ `--before`,`-b`. Le nombre de lignes à afficher avant une entrée de journal correspondante. La valeur par défaut est 0.
+ `--after`,`-a`. Le nombre de lignes à afficher après une entrée de journal correspondante. La valeur par défaut est 0.
+ `--syslog`. Traitez tous les fichiers journaux à l'aide du protocole syslog défini par. RFC3164 Ne pas utiliser avec `--log-dir` et`--verbose`. Le protocole Syslog utilise le format suivant :. `"<$Priority>$Timestamp $Host $Logger ($Class): $Message"` Si vous ne spécifiez pas de fichier journal, Greengrass CLI lit les messages de journal depuis les emplacements suivants : `/var/log/messages``/var/log/syslog`, ou le. `/var/log/system.log`
AWS IoT Greengrass ne prend actuellement pas en charge cette fonctionnalité sur les appareils Windows principaux.
+ `--max-log-queue-size`,`-m`. Nombre maximal d'entrées de journal à allouer à la mémoire. Utilisez cette option pour optimiser l'utilisation de la mémoire. La valeur par défaut est 100.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ sudo greengrass-cli logs get --verbose \
--log-file /greengrass/v2/logs/greengrass.log \
--filter deployment,serviceName=DeploymentService \
--filter level=INFO \
--time-window 2020-12-08T01:11:17,2020-12-08T01:11:22
2020-12-08T01:11:17.615Z [INFO] (pool-2-thread-14) com.aws.greengrass.deployment.DeploymentService: Current deployment finished. {DeploymentId=44d89f46-1a29-4044-ad89-5151213dfcbc, serviceName=DeploymentService, currentState=RUNNING}
2020-12-08T01:11:17.675Z [INFO] (pool-2-thread-14) com.aws.greengrass.deployment.IotJobsHelper: Updating status of persisted deployment. {Status=SUCCEEDED, StatusDetails={detailed-deployment-status=SUCCESSFUL}, ThingName=MyThing, JobId=22d89f46-1a29-4044-ad89-5151213dfcbc
```
## listez les mots clés
Afficher les mots-clés suggérés que vous pouvez utiliser pour filtrer les fichiers journaux.
**Résumé**
```
greengrass-cli logs list-keywords [arguments]
```
**Arguments**
Aucun
**Sortie**
Les exemples suivants montrent le résultat produit lorsque vous exécutez cette commande.
```
$ sudo greengrass-cli logs list-keywords
Here is a list of suggested keywords for Greengrass log:
level=$str
thread=$str
loggerName=$str
eventType=$str
serviceName=$str
error=$str
```
```
$ sudo greengrass-cli logs list-keywords --syslog
Here is a list of suggested keywords for syslog:
priority=$int
host=$str
logger=$str
class=$str
```
## list-log-files
Afficher les fichiers journaux situés dans un répertoire spécifié.
**Résumé**
```
greengrass-cli logs list-log-files [arguments]
```
**Arguments**
`--log-dir`,`-ld`. Le chemin d'accès au répertoire dans lequel vérifier la présence de fichiers journaux.
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ sudo greengrass-cli logs list-log-files -ld /greengrass/v2/logs/
/greengrass/v2/logs/aws.greengrass.Nucleus.log
/greengrass/v2/logs/main.log
/greengrass/v2/logs/greengrass.log
Total 3 files found.
```
# get-debug-password
Utilisez la `get-debug-password` commande pour imprimer un mot de passe généré aléatoirement pour le [composant de console de débogage local](local-debug-console-component.md) (`aws.greengrass.LocalDebugConsole`). Le mot de passe expire 8 heures après sa création.
**Résumé**
```
greengrass-cli get-debug-password
```
**Arguments**
Aucun
**Sortie**
L'exemple suivant montre le résultat produit lorsque vous exécutez cette commande.
```
$ sudo greengrass-cli get-debug-password
Username: debug
Password: bEDp3MOHdj8ou2w5de_sCBI2XAaguy3a8XxREXAMPLE
Password expires at: 2021-04-01T17:01:43.921999931-07:00
The local debug console is configured to use TLS security. The certificate is self-signed so you will need to bypass your web browser's security warnings to open the console.
Before you bypass the security warning, verify that the certificate fingerprint matches the following fingerprints.
SHA-256: 15 0B 2C E2 54 8B 22 DE 08 46 54 8A B1 2B 25 DE FB 02 7D 01 4E 4A 56 67 96 DA A6 CC B1 D2 C4 1B
SHA-1: BC 3E 16 04 D3 80 70 DA E0 47 25 F9 90 FA D6 02 80 3E B5 C1
```
# Utiliser le framework AWS IoT Greengrass de test
Greengrass Testing Framework (GTF) est un ensemble de composants qui soutiennent l' end-to-endautomatisation du point de vue du client. GTF utilise [Cucumber](https://cucumber.io) comme pilote de fonctionnalités. AWS IoT Greengrass utilise les mêmes éléments de base pour qualifier les modifications logicielles sur différents appareils. Pour plus d'informations, consultez [Greengrass Testing Framework sur](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1) Github.
Le GTF est implémenté à l'aide de Cucumber, un outil utilisé pour exécuter des tests automatisés, afin d'encourager un développement des composants piloté par le comportement (BDD). Dans Cucumber, les fonctionnalités de ce système sont décrites dans un type de fichier spécial appelé`feature`. Chaque fonctionnalité est décrite dans un format lisible par l'homme appelé scénarios, qui sont des spécifications pouvant être converties en tests automatisés. Chaque scénario est décrit comme une série d'étapes qui définissent les interactions et les résultats de ce système testé à l'aide d'un langage spécifique au domaine appelé Gherkin. Une [étape Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) est liée au code de programmation à l'aide d'une méthode appelée définition d'étape qui relie la spécification au flux de test. Les définitions d'étapes dans GTF sont implémentées avec Java.
**Topics**
+ [Comment ça marche](#gg-testing-framework-how-gtf-works)
+ [Journal des modifications](#gtf-changelog)
+ [Options de configuration du Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutoriel : Exécuter end-to-end des tests à l'aide du framework de test Greengrass et du kit de développement Greengrass](run-e2e-tests-tutorial.md)
+ [Tutoriel : Utiliser un test de confiance issu de la suite de tests de confiance](confidence-tests-tutorial.md)
## Comment ça marche
AWS IoT Greengrass distribue le GTF sous la forme d'un JAR autonome composé de plusieurs modules Java. Pour utiliser GTF pour end-to-end tester des composants, vous devez implémenter les tests dans un projet Java. L'ajout du JAR autonome de test en tant que dépendance dans votre projet Java vous permet d'utiliser les fonctionnalités existantes du GTF et de les étendre en écrivant vos propres cas de test personnalisés. Pour exécuter les scénarios de test personnalisés, vous pouvez créer votre projet Java et exécuter le fichier JAR cible avec les options de configuration décrites dans[Options de configuration du Greengrass Testing Framework](configuration-options-gtf.md).
### JAR autonome GTF
Greengrass utilise Cloudfront comme référentiel [Maven](https://maven.apache.org/) pour héberger différentes versions du JAR autonome GTF. Pour une liste complète des versions de GTF, voir les versions de [GTF.](https://github.com/aws-greengrass/aws-greengrass-testing/releases)
Le JAR autonome GTF inclut les modules suivants. Il n'est pas limité à ces seuls modules. Vous pouvez sélectionner chacune de ces dépendances séparément dans votre projet ou les inclure toutes en même temps dans le [fichier JAR autonome de test](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone).
+ `aws-greengrass-testing-resources`: Ce module fournit une abstraction permettant de gérer le cycle de vie d'une AWS ressource au cours d'un test. Vous pouvez l'utiliser pour définir vos AWS ressources personnalisées à l'aide de l'`ResourceSpec`abstraction afin que GTF puisse s'occuper de la création et de la suppression de ces ressources pour vous.
+ `aws-greengrass-testing-platform`: Ce module fournit une abstraction au niveau de la plate-forme pour le périphérique testé pendant le cycle de vie du test. Il permet APIs d'interagir avec le système d'exploitation indépendamment de la plate-forme et peut être utilisé pour simuler les commandes exécutées dans le shell de l'appareil.
+ `aws-greengrass-testing-components`: Ce module comprend des exemples de composants utilisés pour tester les fonctionnalités principales de Greengrass, telles que les déploiements, l'IPC et d'autres fonctionnalités.
+ `aws-greengrass-testing-features`: Ce module comprend des étapes communes réutilisables et leurs définitions qui sont utilisées pour les tests dans l'environnement Greengrass.
**Topics**
+ [Comment ça marche](#gg-testing-framework-how-gtf-works)
+ [Journal des modifications](#gtf-changelog)
+ [Options de configuration du Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutoriel : Exécuter end-to-end des tests à l'aide du framework de test Greengrass et du kit de développement Greengrass](run-e2e-tests-tutorial.md)
+ [Tutoriel : Utiliser un test de confiance issu de la suite de tests de confiance](confidence-tests-tutorial.md)
## Journal des modifications
Le tableau suivant décrit les modifications apportées à chaque version du GTF. Pour plus d'informations, consultez la [page des versions du GTF](https://github.com/aws-greengrass/aws-greengrass-testing/releases) sur GitHub.
| **Version** | **Modifications** |
| --- | --- |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.0.0 | Première version. |
# Options de configuration du Greengrass Testing Framework
## Options de configuration GTF
Greengrass Testing Framework (GTF) vous permet de configurer certains paramètres lors du lancement du processus de end-to-end test afin d'orchestrer le flux de test. Vous pouvez spécifier ces options de configuration en tant qu'arguments CLI pour le JAR autonome GTF.
Les versions 1.1.0 et ultérieures de GTF fournissent les options de configuration suivantes.
+ `additional-plugins`— (Facultatif) Plugins Cucumber supplémentaires
+ `aws-region`— Cible des points de terminaison régionaux spécifiques pour les AWS services. La valeur par défaut correspond à ce que le AWS SDK découvre.
+ `credentials-path`— Chemin d'accès facultatif aux informations d'identification du AWS profil. Par défaut, ce sont les informations d'identification découvertes sur l'environnement hôte.
+ `credentials-path-rotation`— Durée de rotation facultative pour les AWS informations d'identification. La valeur par défaut est 15 minutes ou`PT15M`.
+ `csr-path`— Le chemin du CSR à l'aide duquel le certificat de l'appareil sera généré.
+ `device-mode`— L'appareil cible testé. Par défaut, c'est le périphérique local.
+ `env-stage`— Cible l'environnement de déploiement de Greengrass. Par défaut, c'est la production.
+ `existing-device-cert-arn`— L'ARN d'un certificat existant que vous souhaitez utiliser comme certificat d'appareil pour Greengrass.
+ `feature-path`— Fichier ou répertoire contenant des fichiers de fonctionnalités supplémentaires. Par défaut, aucun fichier de fonctionnalités supplémentaire n'est utilisé.
+ `gg-cli-version`— Remplace la version de la CLI Greengrass. La valeur par défaut est celle trouvée dans. `ggc.version`
+ `gg-component-bucket`— Le nom d'un compartiment Amazon S3 existant qui héberge les composants Greengrass.
+ `gg-component-overrides`— Liste des remplacements de composants Greengrass.
+ `gg-persist`— Liste des éléments de test à conserver après un essai. Le comportement par défaut est de ne rien conserver. Les valeurs acceptées sont : `aws.resources``installed.software`, et`generated.files`.
+ `gg-runtime`— Une liste de valeurs destinées à influencer la manière dont le test interagit avec les ressources de test. Ces valeurs remplacent le paramètre. `gg.persist` Si la valeur par défaut est vide, cela suppose que toutes les ressources de test sont gérées par scénario de test, y compris le moteur d'exécution Greengrass installé. Les valeurs acceptées sont : `aws.resources``installed.software`, et`generated.files`.
+ `ggc-archive`— Le chemin d'accès au composant du noyau Greengrass archivé.
+ `ggc-install-root`— Répertoire pour installer le composant Greengrass nucleus. La valeur par défaut est test.temp.path et le dossier test run.
+ `ggc-log-level`— Définissez le niveau logarithmique du noyau Greengrass pour le test. La valeur par défaut est « INFO ».
+ `ggc-tes-rolename`— Le rôle IAM que AWS IoT Greengrass Core assumera pour accéder aux AWS services. Si aucun rôle portant un nom donné n'existe, un rôle sera créé avec une politique d'accès par défaut.
+ `ggc-trusted-plugins`— La liste séparée par des virgules des chemins (sur l'hôte) des plugins fiables qui doivent être ajoutés à Greengrass. Pour fournir le chemin sur le DUT lui-même, préfixez-le par « dut : »
+ `ggc-user-name`— La valeur POSIXUser de user:group pour le noyau Greengrass. La valeur par défaut est le nom d'utilisateur actuel connecté.
+ `ggc-version`— Remplace la version du composant Greengrass nucleus en cours d'exécution. La valeur par défaut est celle trouvée dans ggc.archive.
+ `log-level`— Niveau de journalisation du test. La valeur par défaut est « INFO ».
+ `parallel-config`— Ensemble d'index de lots et de nombre de lots sous forme de chaîne JSON. La valeur par défaut de l'index des lots est 0 et le nombre de lots est 1.
+ `proxy-url`— Configurez tous les tests pour acheminer le trafic via cette URL.
+ `tags`— Exécutez uniquement des balises de fonctionnalité. Peut être intersecté avec « & »
+ `test-id-prefix`— Un préfixe commun appliqué à toutes les ressources spécifiques au test, y compris les noms de AWS ressources et les balises. Le préfixe par défaut est « gg ».
+ `test-log-path`— Répertoire qui contiendra les résultats de l'ensemble du test. La valeur par défaut est « TestResults ».
+ `test-results-json`— Indicateur permettant de déterminer si le rapport Cucumber JSON résultant est généré écrit sur le disque. La valeur par défaut est true (vrai).
+ `test-results-log`— Indicateur permettant de déterminer si la sortie de console est générée écrite sur le disque. La valeur par défaut est false.
+ `test-results-xml`— Indicateur permettant de déterminer si le rapport JUnit XML obtenu est généré et écrit sur le disque. La valeur par défaut est true (vrai).
+ `test-temp-path`— Répertoire pour générer des artefacts de test locaux. La valeur par défaut est un répertoire temporaire aléatoire préfixé par gg-testing.
+ `timeout-multiplier`— Multiplicateur fourni à tous les délais d'expiration des tests. La valeur par défaut est 1,0.
# Tutoriel : Exécuter end-to-end des tests à l'aide du framework de test Greengrass et du kit de développement Greengrass
AWS IoT Greengrass Le Testing Framework (GTF) et le Greengrass Development Kit (GDK) offrent aux développeurs des moyens d'exécuter des tests. end-to-end Vous pouvez suivre ce didacticiel pour initialiser un projet GDK avec un composant, initialiser un projet GDK avec un module de end-to-end test et créer un cas de test personnalisé. Après avoir créé votre scénario de test personnalisé, vous pouvez exécuter le test.
Dans ce didacticiel, vous allez effectuer les opérations suivantes :
1. Initialisez un projet GDK avec un composant.
1. Initialisez un projet GDK avec un module de end-to-end test.
1. Créez un cas de test personnalisé.
1. Ajoutez une étiquette au nouveau scénario de test.
1. Créez le fichier JAR de test.
1. Exécutez le test .
**Topics**
+ [Conditions préalables](#run-e2e-tests-tutorial-prerequisites)
+ [Étape 1 : Initialisation d'un projet GDK avec un composant](#init-gdk-with-component)
+ [Étape 2 : Initialisation d'un projet GDK avec un module de test end-to-end](#init-gdk-with-e2e-test)
+ [Étape 3 : créer un cas de test personnalisé](#run-e2e-tests-tutorial-instructions)
+ [Étape 4 : ajouter un tag au nouveau scénario de test](#add-tag-to-test-case)
+ [Étape 5 : créer le fichier JAR de test](#build-test-jar)
+ [Étape 6 : Exécuter le test](#run-test-gtf)
+ [Exemple : création d'un scénario de test personnalisé](#build-test-case-example)
## Conditions préalables
Pour suivre ce didacticiel, vous aurez besoin des éléments suivants :
+ GDK version 1.3.0 ou ultérieure
+ Java
+ Maven
+ Git
## Étape 1 : Initialisation d'un projet GDK avec un composant
+ Initialisez un dossier vide avec un projet GDK. Téléchargez le `HelloWorld` composant implémenté en Python en exécutant la commande suivante.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Cette commande crée un nouveau répertoire nommé `HelloWorld` dans le répertoire en cours.
## Étape 2 : Initialisation d'un projet GDK avec un module de test end-to-end
+ GDK vous permet de télécharger le modèle du module de test composé d'une fonctionnalité et d'une implémentation par étapes. Exécutez la commande suivante pour ouvrir le `HelloWorld` répertoire et initialiser le projet GDK existant à l'aide d'un module de test.
```
cd HelloWorld
gdk test-e2e init
```
Cette commande crée un nouveau répertoire nommé `gg-e2e-tests` dans le `HelloWorld` répertoire. Ce répertoire de test est un projet [Maven](https://maven.apache.org/) qui dépend du JAR autonome de test Greengrass.
## Étape 3 : créer un cas de test personnalisé
La rédaction d'un scénario de test personnalisé comprend généralement deux étapes : créer un fichier de fonctionnalités avec un scénario de test et implémenter les définitions d'étapes. Pour un exemple de création d'un scénario de test personnalisé, voir[Exemple : création d'un scénario de test personnalisé](#build-test-case-example). Suivez les étapes suivantes pour créer votre scénario de test personnalisé :
1. Création d'un fichier de fonctionnalités avec un scénario de test
Une fonctionnalité décrit généralement une fonctionnalité spécifique du logiciel testé. Dans Cucumber, chaque fonctionnalité est spécifiée sous la forme d'un fichier de fonctionnalités individuel avec un titre, une description détaillée et un ou plusieurs exemples de cas spécifiques appelés scénarios. Chaque scénario comprend un titre, une description détaillée et une série d'étapes qui définissent les interactions et les résultats attendus. Les scénarios sont rédigés dans un format structuré à l'aide des mots clés « donné », « quand » et « alors ».
1. Mettre en œuvre les définitions des étapes
Une définition d'étape lie l'[étape Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) en langage clair au code programmatique. Lorsque Cucumber identifie une étape Gherkin dans un scénario, il recherche une définition d'étape correspondante à exécuter.
## Étape 4 : ajouter un tag au nouveau scénario de test
+ Vous pouvez attribuer des balises aux fonctionnalités et aux scénarios afin d'organiser le processus de test. Vous pouvez utiliser des balises pour classer les sous-ensembles de scénarios et également sélectionner les hooks à exécuter de manière conditionnelle. Les fonctionnalités et les scénarios peuvent comporter plusieurs balises séparées par un espace.
Dans cet exemple, nous utilisons le `HelloWorld` composant.
Dans le fichier de fonctionnalités, ajoutez une nouvelle balise nommée `@HelloWorld` à côté de la `@Sample` balise.
```
@Sample @HelloWorld
Scenario: As a developer, I can create a component and deploy it on my device
....
```
## Étape 5 : créer le fichier JAR de test
1. Construisez le composant. Vous devez créer le composant avant de créer le module de test.
```
gdk component build
```
1. Créez le module de test à l'aide de la commande suivante. Cette commande créera le fichier JAR de test dans le `greengrass-build` dossier.
```
gdk test-e2e build
```
## Étape 6 : Exécuter le test
Lorsque vous exécutez un scénario de test personnalisé, le GTF automatise le cycle de vie du test ainsi que la gestion des ressources créées pendant le test. Il approvisionne d'abord un appareil en cours de test (DUT) en tant qu' AWS IoT objet et y installe le logiciel de base Greengrass. Il créera ensuite un nouveau composant nommé `HelloWorld` en utilisant la recette spécifiée dans ce chemin. Le `HelloWorld` composant est ensuite déployé sur le périphérique principal par le biais d'un déploiement d'objets Greengrass. Il sera ensuite vérifié si le déploiement est réussi. L'état du déploiement passera à 3 `COMPLETED` minutes si le déploiement est réussi.
1. Accédez au `gdk-config.json` fichier dans le répertoire du projet pour cibler les tests avec la `HelloWorld` balise. Mettez à jour la `test-e2e` clé à l'aide de la commande suivante.
```
"test-e2e":{
"gtf_options" : {
"tags":"HelloWorld"
}
}
```
1. Avant d'exécuter les tests, vous devez fournir des AWS informations d'identification au périphérique hôte. GTF utilise ces informations d'identification pour gérer les AWS ressources pendant le processus de test. Assurez-vous que le rôle que vous fournissez dispose des autorisations nécessaires pour automatiser les opérations nécessaires incluses dans le test.
Exécutez les commandes suivantes pour fournir les AWS informations d'identification.
1.
------
#### [ Linux or Unix ]
```
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
------
#### [ Windows Command Prompt (CMD) ]
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
------
#### [ PowerShell ]
```
$env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
$env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
```
------
1. Exécutez le test à l'aide de la commande suivante.
```
gdk test-e2e run
```
Cette commande télécharge la dernière version du noyau Greengrass dans le `greengrass-build` dossier et exécute des tests en l'utilisant. Cette commande cible également uniquement les scénarios dotés de la `HelloWorld` balise et génère un rapport pour ces scénarios. Vous verrez que les AWS ressources créées lors de ce test sont supprimées à la fin du test.
## Exemple : création d'un scénario de test personnalisé
**Example**
Le module de test téléchargé dans le projet GDK se compose d'un exemple de fonctionnalité et d'un fichier d'implémentation des étapes.
Dans l'exemple suivant, nous créons un fichier de fonctionnalités pour tester la fonctionnalité de déploiement d'objets du logiciel Greengrass. Nous testons partiellement la fonctionnalité de cette fonctionnalité avec un scénario qui effectue le déploiement d'un composant via Greengrass AWS Cloud. Il s'agit d'une série d'étapes qui nous aident à comprendre les interactions et les résultats attendus de ce cas d'utilisation.
1.
**Création d'un fichier de fonctionnalités**
Accédez au `gg-e2e-tests/src/main/resources/greengrass/features` dossier dans le répertoire actuel. Vous pouvez trouver l'exemple `component.feature` qui ressemble à l'exemple suivant.
Dans ce fichier de fonctionnalités, vous pouvez tester la fonctionnalité de déploiement d'objets du logiciel Greengrass. Vous pouvez tester partiellement la fonctionnalité de cette fonctionnalité avec un scénario qui effectue le déploiement d'un composant via le cloud Greengrass. Le scénario est une série d'étapes qui aident à comprendre les interactions et les résultats attendus de ce cas d'utilisation.
```
Feature: Testing features of Greengrassv2 component
Background:
Given my device is registered as a Thing
And my device is running Greengrass
@Sample
Scenario: As a developer, I can create a component and deploy it on my device
When I create a Greengrass deployment with components
HelloWorld | /path/to/recipe/file
And I deploy the Greengrass deployment configuration
Then the Greengrass deployment is COMPLETED on the device after 180 seconds
And I call my custom step
```
GTF contient les définitions des étapes de toutes les étapes suivantes, à l'exception de l'étape nommée :`And I call my custom step`.
1.
**Mettre en œuvre les définitions des étapes**
Le fichier JAR autonome GTF contient les définitions d'étapes de toutes les étapes à l'exception d'une étape :. `And I call my custom step` Vous pouvez implémenter cette étape dans le module de test.
Accédez au code source du fichier de test. Vous pouvez lier votre étape personnalisée à l'aide d'une définition d'étape à l'aide de la commande suivante.
```
@And("I call my custom step")
public void customStep() {
System.out.println("My custom step was called ");
}
```
# Tutoriel : Utiliser un test de confiance issu de la suite de tests de confiance
AWS IoT Greengrass Le Testing Framework (GTF) et le Greengrass Development Kit (GDK) offrent aux développeurs des moyens d'exécuter des tests. end-to-end Vous pouvez suivre ce didacticiel pour initialiser un projet GDK avec un composant, initialiser un projet GDK avec un module de test et utiliser un end-to-end test de confiance issu de la suite de tests de confiance. Après avoir créé votre scénario de test personnalisé, vous pouvez exécuter le test.
Un test de confiance est un test générique fourni par Greengrass qui valide les comportements fondamentaux des composants. Ces tests peuvent être modifiés ou étendus pour répondre à des besoins de composants plus spécifiques.
Pour ce didacticiel, nous utiliserons un HelloWorld composant. Si vous utilisez un autre composant, remplacez-le par le HelloWorld vôtre.
Dans ce didacticiel, vous allez effectuer les opérations suivantes :
1. Initialisez un projet GDK avec un composant.
1. Initialisez un projet GDK avec un module de end-to-end test.
1. Utilisez un test issu de la suite de tests de confiance.
1. Ajoutez une étiquette au nouveau scénario de test.
1. Créez le fichier JAR de test.
1. Exécutez le test .
**Topics**
+ [Conditions préalables](#confidence-tests-tutorial-prerequisites)
+ [Étape 1 : Initialisation d'un projet GDK avec un composant](#init-gdk-with-component)
+ [Étape 2 : Initialisation d'un projet GDK avec un module de test end-to-end](#init-gdk-with-e2e-test)
+ [Étape 3 : Utiliser un test issu de la suite de tests de confiance](#confidence-tests-tutorial-instructions)
+ [Étape 4 : ajouter un tag au nouveau scénario de test](#add-tag-to-test-case)
+ [Étape 5 : créer le fichier JAR de test](#build-test-jar)
+ [Étape 6 : Exécuter le test](#run-test-gtf)
+ [Exemple : utiliser un test de confiance](#build-confidence-test-case-example)
## Conditions préalables
Pour suivre ce didacticiel, vous aurez besoin des éléments suivants :
+ GDK version 1.6.0 ou ultérieure
+ Java
+ Maven
+ Git
## Étape 1 : Initialisation d'un projet GDK avec un composant
+ Initialisez un dossier vide avec un projet GDK. Téléchargez le `HelloWorld` composant implémenté en Python en exécutant la commande suivante.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Cette commande crée un nouveau répertoire nommé `HelloWorld` dans le répertoire en cours.
## Étape 2 : Initialisation d'un projet GDK avec un module de test end-to-end
+ GDK vous permet de télécharger le modèle du module de test composé d'une fonctionnalité et d'une implémentation par étapes. Exécutez la commande suivante pour ouvrir le `HelloWorld` répertoire et initialiser le projet GDK existant à l'aide d'un module de test.
```
cd HelloWorld
gdk test-e2e init
```
Cette commande crée un nouveau répertoire nommé `gg-e2e-tests` dans le `HelloWorld` répertoire. Ce répertoire de test est un projet [Maven](https://maven.apache.org/) qui dépend du JAR autonome de test Greengrass.
## Étape 3 : Utiliser un test issu de la suite de tests de confiance
La rédaction d'un scénario de test de confiance consiste à utiliser le fichier de fonctionnalités fourni et, si nécessaire, à modifier les scénarios. Pour un exemple d'utilisation d'un test de confiance, voir[Exemple : création d'un scénario de test personnalisé](run-e2e-tests-tutorial.md#build-test-case-example). Pour utiliser un test de confiance, procédez comme suit :
+ Utilisez le fichier de fonctionnalités fourni.
Accédez au `gg-e2e-tests/src/main/resources/greengrass/features` dossier dans le répertoire actuel. Ouvrez le `confidenceTest.feature` fichier d'exemple pour utiliser le test de confiance.
## Étape 4 : ajouter un tag au nouveau scénario de test
+ Vous pouvez attribuer des balises aux fonctionnalités et aux scénarios afin d'organiser le processus de test. Vous pouvez utiliser des balises pour classer les sous-ensembles de scénarios et également sélectionner les hooks à exécuter de manière conditionnelle. Les fonctionnalités et les scénarios peuvent comporter plusieurs balises séparées par un espace.
Dans cet exemple, nous utilisons le `HelloWorld` composant.
Chaque scénario est étiqueté avec`@ConfidenceTest`. Modifiez ou ajoutez des balises si vous souhaitez exécuter uniquement un sous-ensemble de la suite de tests. Chaque scénario de test est décrit en haut de chaque test de confiance. Le scénario est une série d'étapes qui aident à comprendre les interactions et les résultats attendus de chaque cas de test. Vous pouvez étendre ces tests en ajoutant vos propres étapes ou en modifiant les étapes existantes.
```
@ConfidenceTest
Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected
....
```
## Étape 5 : créer le fichier JAR de test
1. Construisez le composant. Vous devez créer le composant avant de créer le module de test.
```
gdk component build
```
1. Créez le module de test à l'aide de la commande suivante. Cette commande créera le fichier JAR de test dans le `greengrass-build` dossier.
```
gdk test-e2e build
```
## Étape 6 : Exécuter le test
Lorsque vous exécutez un test de confiance, le GTF automatise le cycle de vie du test ainsi que la gestion des ressources créées pendant le test. Il approvisionne d'abord un appareil en cours de test (DUT) en tant qu' AWS IoT objet et y installe le logiciel de base Greengrass. Il créera ensuite un nouveau composant nommé `HelloWorld` en utilisant la recette spécifiée dans ce chemin. Le `HelloWorld` composant est ensuite déployé sur le périphérique principal par le biais d'un déploiement d'objets Greengrass. Il sera ensuite vérifié si le déploiement est réussi. L'état du déploiement passera à 3 `COMPLETED` minutes si le déploiement est réussi.
1. Accédez au `gdk-config.json` fichier dans le répertoire du projet pour cibler les tests avec le `ConfidenceTest` tag ou le tag yo8u spécifié à l'étape 4. Mettez à jour la `test-e2e` clé à l'aide de la commande suivante.
```
"test-e2e":{
"gtf_options" : {
"tags":"ConfidenceTest"
}
}
```
1. Avant d'exécuter les tests, vous devez fournir des AWS informations d'identification au périphérique hôte. GTF utilise ces informations d'identification pour gérer les AWS ressources pendant le processus de test. Assurez-vous que le rôle que vous fournissez dispose des autorisations nécessaires pour automatiser les opérations nécessaires incluses dans le test.
Exécutez les commandes suivantes pour fournir les AWS informations d'identification.
1.
------
#### [ Linux or Unix ]
```
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
------
#### [ Windows Command Prompt (CMD) ]
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
------
#### [ PowerShell ]
```
$env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
$env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
```
------
1. Exécutez le test à l'aide de la commande suivante.
```
gdk test-e2e run
```
Cette commande télécharge la dernière version du noyau Greengrass dans le `greengrass-build` dossier et exécute des tests en l'utilisant. Cette commande cible également uniquement les scénarios dotés de la `ConfidenceTest` balise et génère un rapport pour ces scénarios. Vous verrez que les AWS ressources créées lors de ce test sont supprimées à la fin du test.
## Exemple : utiliser un test de confiance
**Example**
Le module de test téléchargé dans le projet GDK consiste en un fichier de fonctionnalités fourni.
Dans l'exemple suivant, nous utilisons un fichier de fonctionnalités pour tester la fonctionnalité de déploiement d'objets du logiciel Greengrass. Nous testons partiellement la fonctionnalité de cette fonctionnalité avec un scénario qui effectue le déploiement d'un composant via Greengrass AWS Cloud. Il s'agit d'une série d'étapes qui nous aident à comprendre les interactions et les résultats attendus de ce cas d'utilisation.
+
**Utilisez le fichier de fonctionnalités fourni.**
Accédez au `gg-e2e-tests/src/main/resources/greengrass/features` dossier dans le répertoire actuel. Vous pouvez trouver l'exemple `confidenceTest.feature` qui ressemble à l'exemple suivant.
```
Feature: Confidence Test Suite
Background:
Given my device is registered as a Thing
And my device is running Greengrass
@ConfidenceTest
Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected
When I create a Greengrass deployment with components
| GDK_COMPONENT_NAME | GDK_COMPONENT_RECIPE_FILE |
| aws.greengrass.Cli | LATEST |
And I deploy the Greengrass deployment configuration
Then the Greengrass deployment is COMPLETED on the device after 180 seconds
# Update component state accordingly. Possible states: {RUNNING, FINISHED, BROKEN, STOPPING}
And I verify the GDK_COMPONENT_NAME component is RUNNING using the greengrass-cli
```
Chaque scénario de test est décrit en haut de chaque test de confiance. Le scénario est une série d'étapes qui aident à comprendre les interactions et les résultats attendus de chaque cas de test. Vous pouvez étendre ces tests en ajoutant vos propres étapes ou en modifiant les étapes existantes. Chacun des scénarios inclut des commentaires qui vous aideront à effectuer ces ajustements.