Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# AWS IoT Greengrass herramientas de desarrollo
Utilice las herramientas de AWS IoT Greengrass desarrollo para crear, probar, compilar, publicar e implementar componentes personalizados de Greengrass.
+ **[CLI del kit de desarrollo de Greengrass](greengrass-development-kit-cli.md)**
Utilice la interfaz de línea de comandos del kit de AWS IoT Greengrass desarrollo (CLI de GDK) en su entorno de desarrollo local para crear componentes a partir de plantillas y componentes de la comunidad en el catálogo de software de [Greengrass](greengrass-software-catalog.md). Puede usar la CLI de GDK para crear el componente y publicarlo en el AWS IoT Greengrass servicio como un componente privado en su Cuenta de AWS.
+ **[Interfaz de la línea de comandos de Greengrass](gg-cli.md)**
Utilice la interfaz de la línea de comandos de Greengrass (CLI de Greengrass) en los dispositivos principales de Greengrass para implementar y depurar los componentes de Greengrass. La CLI de Greengrass es un componente que puede implementar en los dispositivos principales para crear implementaciones locales, ver detalles sobre los componentes instalados y explorar los archivos de registro.
+ **[Consola de depuración local](local-debug-console-component.md)**
Utilice la consola de depuración local de los dispositivos principales de Greengrass para implementar y depurar los componentes de Greengrass mediante una interfaz web de panel local. La consola de depuración local es un componente que puede implementar en los dispositivos principales para crear implementaciones locales y ver detalles sobre los componentes instalados.
AWS IoT Greengrass también proporciona lo siguiente SDKs que puede utilizar en los componentes personalizados de Greengrass:
+ El SDK para dispositivos con AWS IoT y el SDK de AWS IoT Greengrass componentes, que contienen la biblioteca de comunicación entre procesos (IPC). Para obtener más información, consulte [Úselo SDK para dispositivos con AWS IoT para comunicarse con el núcleo de Greengrass, otros componentes y AWS IoT CoreComuníquese con el núcleo de Greengrass, otros componentes y AWS IoT Core](interprocess-communication.md).
+ El SDK del administrador de flujos, que puede utilizar para transferir flujos de datos a la Nube de AWS. Para obtener más información, consulte [Administración de flujos de datos en los dispositivos principales de Greengrass](manage-data-streams.md).
**Topics**
+ [Interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass](greengrass-development-kit-cli.md)
+ [Interfaz de la línea de comandos de Greengrass](gg-cli.md)
+ [Utilice el marco AWS IoT Greengrass de pruebas](gg-testing-framework.md)
# Interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass
La interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass (CLI del GDK) proporciona características que lo ayudan a desarrollar [componentes personalizados de Greengrass](develop-greengrass-components.md). Puede usar la CLI del GDK para crear, compilar y publicar componentes personalizados. Al crear un repositorio de componentes con la CLI del GDK, puede partir de una plantilla o un componente de comunidad del [catálogo de software de Greengrass](greengrass-software-catalog.md). A continuación, puede elegir un sistema de compilación que agrupe los archivos como archivos ZIP, utilice un script de compilación de Maven o Gradle o ejecute un comando de compilación personalizado. Luego de crear un componente, puede usar la CLI del GDK para publicarlo en el servicio de AWS IoT Greengrass, de modo que puede usar la consola de AWS IoT Greengrass o la API para implementar el componente en los dispositivos principales de Greengrass.
Al desarrollar componentes de Greengrass sin la CLI del GDK, debe actualizar los URI de versión y artefacto del [archivo de recetas del componente](component-recipe-reference.md) cada vez que cree una nueva versión del componente. Al utilizar la CLI del GDK, esta puede actualizar automáticamente los URI de versión y artefacto cada vez que publique una nueva versión del componente.
La CLI del GDK es de código abierto y está disponible en GitHub. Puede personalizar y ampliar la CLI del GDK para lograr los objetivos de desarrollo de componentes. Lo invitamos a consultar por incidencias y solicitudes de cambios en el repositorio de GitHub. Puede encontrar el origen de la CLI del GDK en el siguiente enlace: [https://github.com/aws-greengrass/aws-greengrass-gdk-cli](https://github.com/aws-greengrass/aws-greengrass-gdk-cli).
## Requisitos previos
Para instalar y usar la CLI del kit de desarrollo de Greengrass, necesita lo siguiente:
+ Un Cuenta de AWS. Si no dispone de una, consulte [Configura un Cuenta de AWS](setting-up.md#set-up-aws-account).
+ Una computadora de desarrollo similar a Windows, macOS o Unix con conexión a Internet.
+ Para la versión 1.1.0 de la CLI del GDK o versiones posteriores, debe tener [Python](https://www.python.org/downloads/) 3.6 instalada en la computadora de desarrollo.
Para la versión 1.0.0 de la CLI del GDK, debe tener [Python](https://www.python.org/downloads/) 3.8 instalada en la computadora de desarrollo.
+ [Git](https://git-scm.com/) instalado en su computadora de desarrollo.
+ AWS Command Line Interface (AWS CLI) instalado y configurado con credenciales en su computadora de desarrollo. Para obtener más información, consulte [Instalar, actualizar y desinstalar la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) y [Configurar la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) en la *Guía del usuario de AWS Command Line Interface*.
**nota**
Si usa una Raspberry Pi u otro dispositivo ARM de 32 bits, instale la versión 1 de AWS CLI. AWS CLI La versión 2 no está disponible para dispositivos ARM de 32 bits. Para obtener más información, consulte [Instalar, actualizar y desinstalar la versión 1 de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html).
+ Para usar la CLI del GDK para publicar componentes en el servicio de AWS IoT Greengrass, debe contar con los siguientes permisos:
+ `s3:CreateBucket`
+ `s3:GetBucketLocation`
+ `s3:PutObject`
+ `greengrass:CreateComponentVersion`
+ `greengrass:ListComponentVersions`
+ Para usar la CLI de GDK para crear un componente cuyos artefactos existan en un bucket de S3 y no en el sistema de archivos local, debe tener los siguientes permisos:
+ `s3:ListBucket`
Esta característica está disponible para la versión 1.1.0 y posteriores de la CLI de GDK.
## Registro de cambios
En la siguiente tabla, se describen los cambios en cada versión de la CLI del GDK. Para obtener más información, consulte la [página de lanzamientos de la CLI del GDK](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases) en GitHub.
| **Versión** | **Cambios** |
| --- | --- |
| 1.6.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.0.0 | Versión inicial. |
# Instalación o actualización de la interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass
La interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass (CLI del GDK) se basa en Python, por lo que puede utilizar `pip` para instalarla en su computadora de desarrollo.
**sugerencia**
También puede instalar la CLI del GDK en un entorno virtual de Python, como [venv](https://docs.python.org/3/library/venv.html#module-venv). Para obtener más información, consulte [Entornos y paquetes virtuales](https://docs.python.org/3/tutorial/venv.html) en la *documentación de Python 3*.
**Cómo instalar o actualizar la CLI del GDK**
1. Ejecute el siguiente comando para instalar la versión más reciente de la CLI del GDK desde el [repositorio de GitHub](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
```
**nota**
Para instalar una versión específica de la CLI del GDK, sustituya *versionTag* por la etiqueta de versión que desee instalar. Puede ver las etiquetas de versión de la CLI del GDK en su [repositorio de GitHub](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. Ejecute los siguientes comandos para verificar que la CLI del GDK se instaló correctamente.
```
gdk --help
```
Si no se encuentra el comando `gdk`, agregue su carpeta a PATH.
+ En dispositivos Linux, agregue `/home/MyUser/.local/bin` a PATH y sustituya *MyUser* por el nombre de su usuario.
+ En dispositivos Windows, agregue `PythonPath\\Scripts` a PATH y sustituya *PythonPath* por la ruta a la carpeta Python de su dispositivo.
Ahora puede usar la CLI del GDK para crear, compilar y publicar componentes de Greengrass. Para obtener más información acerca de cómo utilizar la CLI del GDK, consulte [Comandos de la interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass](greengrass-development-kit-cli-commands.md).
# Comandos de la interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass
La interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass (CLI del GDK) proporciona una interfaz de línea de comandos que puede utilizar para crear, compilar y publicar componentes de Greengrass en la computadora de desarrollo. Los comandos de la CLI del GDK utilizan el siguiente formato.
```
gdk [arguments]
```
Al [instalar la CLI del GDK](install-greengrass-development-kit-cli.md), el instalador agrega `gdk` a la PATH para que pueda ejecutar la CLI del GDK desde la línea de comandos.
Puede utilizar los siguientes argumentos con cualquier comando:
+ Utilice `-h` o `--help` para obtener información sobre un comando de la CLI del GDK.
+ Utilice `-v` o `--version` para ver qué versión de la CLI del GDK está instalada.
+ Utilice `-d` o `--debug` para generar registros detallados que pueda usar para depurar la CLI del GDK.
En esta sección, se describen los comandos de la CLI del GDK y se proporcionan ejemplos para cada comando. La sinopsis de cada comando muestra sus argumentos y cómo se utilizan. Los argumentos opcionales deben ir entre corchetes.
**Topics**
+ [componente](greengrass-development-kit-cli-component.md)
+ [config](greengrass-development-kit-cli-config.md)
+ [test-e2e](greengrass-development-kit-cli-test.md)
# componente
Utilice el comando `component` en la interfaz de línea de comandos del kit de desarrollo (CLI del GDK) AWS IoT Greengrass para crear, compilar y publicar componentes personalizados de Greengrass.
**Topics**
+ [init](#greengrass-development-kit-cli-component-init)
+ [build](#greengrass-development-kit-cli-component-build)
+ [publish](#greengrass-development-kit-cli-component-publish)
+ [list](#greengrass-development-kit-cli-component-list)
## init
Inicialice una carpeta de componentes de Greengrass desde una plantilla de componentes o un componente de la comunidad.
La CLI del GDK recupera los componentes de la comunidad del [catálogo de software de Greengrass](greengrass-software-catalog.md) y las plantillas de componentes del [repositorio de plantillas de componentes de AWS IoT Greengrass en GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates).
**nota**
Si usa la versión 1.0.0 de la CLI de GDK, debe ejecutar este comando en una carpeta vacía. La CLI de GDK descarga la plantilla o el componente de comunidad en la carpeta actual.
Si usa la versión 1.1.0 de la CLI de GDK o una versión posterior, puede especificar el argumento `--name` para especificar la carpeta en la que la CLI de GDK descarga la plantilla o el componente de comunidad. Si usa este argumento, especifique una carpeta que no existe. La CLI de GDK crea la carpeta por usted. Si no se especifica este argumento, la CLI de GDK usa la carpeta actual, que debe estar vacía.
Si el componente usa el [sistema de compilación zip](gdk-cli-configuration-file.md#gdk-cli-configuration-file-build-system), la CLI del GDK comprime ciertos archivos de la carpeta del componente en un archivo zip con el mismo nombre que la carpeta del componente. Por ejemplo, si el nombre de la carpeta del componente es `HelloWorld`, la CLI de GDK crea un archivo zip denominado `HelloWorld.zip`. En la receta del componente, el nombre del artefacto zip debe coincidir con el nombre de la carpeta del componente. Si usa la versión 1.0.0 de la CLI de GDK en un dispositivo Windows, los nombres de las carpetas y los archivos zip de los componentes deben contener solo letras minúsculas.
Si inicializa una plantilla o un componente de comunidad que utiliza el sistema de compilación zip en una carpeta con un nombre diferente al de la plantilla o el componente, debe cambiar el nombre del artefacto zip en la receta del componente. Actualice las definiciones `Artifacts` y `Lifecycle` de forma que el nombre del archivo zip coincida con el nombre de la carpeta del componente. Los siguientes ejemplos resaltan el nombre del archivo zip en las definiciones `Artifacts` y `Lifecycle`.
```
{
...
"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}"
```
**Sinopsis**
```
$ gdk component init
[--language]
[--template]
[--repository]
[--name]
```
**Argumentos (se inicializan desde la plantilla del componente)**
+ `-l`, `--language`: el lenguaje de programación que se utilizará para la plantilla que especifique.
Debe especificar `--repository` o `--language` y `--template`.
+ `-t`, `--template`: la plantilla de componentes que se utilizará en un proyecto de componentes locales. Utilice el comando [list](#greengrass-development-kit-cli-component-list) para ver las plantillas disponibles.
Debe especificar `--repository` o `--language` y `--template`.
+ `-n`, `--name`: (opcional) el nombre de la carpeta local en la que la CLI del GDK inicializa el componente. Especifique una carpeta que no existe. La CLI de GDK crea la carpeta por usted.
Esta característica está disponible para la versión 1.1.0 y posteriores de la CLI de GDK.
**Argumentos (se inicializan desde el componente de la comunidad)**
+ `-r`, `--repository`: el componente de la comunidad que se va a incluir en la carpeta local. Para ver los componentes de la comunidad disponibles, utilice el comando [list](#greengrass-development-kit-cli-component-list).
Debe especificar `--repository` o `--language` y `--template`.
+ `-n`, `--name`: (opcional) el nombre de la carpeta local en la que la CLI del GDK inicializa el componente. Especifique una carpeta que no existe. La CLI de GDK crea la carpeta por usted.
Esta característica está disponible para la versión 1.1.0 y posteriores de la CLI de GDK.
**Output**
El siguiente ejemplo muestra el resultado que se produce al ejecutar este comando para inicializar una carpeta de componentes desde la plantilla Hello World de Python.
```
$ 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.
```
El siguiente ejemplo muestra el resultado que se produce al ejecutar este comando para inicializar una carpeta de un componente de la comunidad.
```
$ 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
Convierta el código de origen de un componente en una receta y artefactos que pueda publicar en el servicio de AWS IoT Greengrass. La CLI del GDK ejecuta el sistema de compilación que especifique en el [archivo de configuración de la CLI del GDK](gdk-cli-configuration-file.md), `gdk-config.json`. Debe ejecutar este comando en la misma carpeta en la que se encuentra el archivo `gdk-config.json`.
Al ejecutar este comando, la CLI del GDK crea una receta y artefactos en la carpeta `greengrass-build` de la carpeta del componente. La CLI del GDK guarda la receta en la carpeta `greengrass-build/recipes` y guarda los artefactos en la carpeta `greengrass-build/artifacts/componentName/componentVersion`.
Si usa la CLI del GDK versión 1.1.0 o una versión posterior, la receta del componente puede especificar los artefactos que existen en un bucket de S3, pero no en la carpeta de compilación del componente local. Puede utilizar esta característica para reducir el uso del ancho de banda cuando desarrolle componentes con artefactos de gran tamaño, como los modelos de machine learning.
Después de crear un componente, puede realizar una de las siguientes acciones para probarlo en un dispositivo principal de Greengrass:
+ Si desarrolla en un dispositivo diferente al que ejecuta el software AWS IoT Greengrass Core, debe publicar el componente para implementarlo en un dispositivo principal de Greengrass. Publique el componente en el servicio de AWS IoT Greengrass e impleméntelo en el dispositivo principal de Greengrass. Para obtener más información, consulte los comandos [publish](#greengrass-development-kit-cli-component-build) y [Crear implementaciones](create-deployments.md).
+ Si desarrolla el servicio en el mismo dispositivo en el que ejecuta el software AWS IoT Greengrass Core, puede publicar el componente en el servicio de AWS IoT Greengrass que desea implementar o puede crear una implementación local para instalar y ejecutar el componente. Para crear una implementación local, utilice la CLI de Greengrass. Para obtener más información, consulte [Interfaz de la línea de comandos de Greengrass](gg-cli.md) y [Prueba de los componentes de AWS IoT Greengrass con implementaciones locales](test-components.md). Al crear la implementación local, especifique `greengrass-build/recipes` como carpeta de recetas y `greengrass-build/artifacts` como carpeta de artefactos.
**Sinopsis**
```
$ gdk component build
```
**Argumentos**
Ninguno
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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'.
```
## publish
Publique el componente en el servicio de AWS IoT Greengrass. Este comando carga los artefactos de compilación en un bucket de S3, actualiza el URI del artefacto en la receta y crea una nueva versión del componente a partir de la receta. La CLI del GDK utiliza el bucket de S3 y la región de AWS que se especifican en el [archivo de configuración de la CLI del GDK](gdk-cli-configuration-file.md), `gdk-config.json`. Debe ejecutar este comando en la misma carpeta en la que se encuentra el archivo `gdk-config.json`.
Si usa la versión 1.1.0 o posteriores de la CLI de GDK, puede especificar el argumento `--bucket` para especificar el bucket de S3 en el que la CLI de GDK carga los artefactos del componente. Si no especifica este argumento, la CLI de GDK se carga en el bucket de S3 cuyo nombre es `bucket-region-accountId`, donde *bucket* y *region* son los valores que especifica en `gdk-config.json` y *acountId* es el ID de su Cuenta de AWS. La CLI de GDK crea el bucket si no existe.
Si utiliza la versión 1.2.0 de la CLI del GDK o una versión posterior, puede anular la Región de AWS especificada en el archivo de configuración de la CLI del GDK mediante el parámetro `--region`. También puede especificar opciones adicionales mediante el parámetro `--options`. Para ver la lista de opciones disponibles, consulte [Archivo de configuración la CLI del kit de desarrollo de Greengrass](gdk-cli-configuration-file.md).
Al ejecutar este comando, la CLI del GDK publica el componente con la versión que especifique en la receta. Si especifica `NEXT_PATCH`, la CLI del GDK utilizará la siguiente versión de parche que aún no exista. Las versiones semánticas siguen un sistema de números de *major*.*minor*.*patch*. Para obtener más información, consulte la [especificación semántica de la versión](https://semver.org/).
**nota**
Si utiliza la versión 1.1.0 de la CLI del GDK o una versión posterior, al ejecutar este comando, la CLI del GDK comprueba si el componente está creado. Si el componente no está compilado, la CLI del GDK [lo compila](#greengrass-development-kit-cli-component-build) antes de publicarlo.
**Sinopsis**
```
$ gdk component publish
[--bucket] [--region] [--options]
```
**Argumentos**
+ `-b`, `--bucket`: (opcional) especifique el nombre del bucket de S3 en el que la CLI del GDK publica los artefactos de los componentes.
Si no especifica este argumento, la CLI de GDK se carga en el bucket de S3 cuyo nombre es `bucket-region-accountId`, donde *bucket* y *region* son los valores que especifica en `gdk-config.json` y *acountId* es el ID de su Cuenta de AWS. La CLI de GDK crea el bucket si no existe.
La CLI de GDK crea el bucket si no existe.
Esta característica está disponible para la versión 1.1.0 y posteriores de la CLI de GDK.
+ `-r`, `--region`: (opcional) especifique el nombre de la Región de AWS para cuando el componente se crea. Este argumento anula el nombre de la región en la configuración de la CLI del GDK.
Esta característica está disponible para la versión 1.2.0 y versiones posteriores de la CLI de GDK.
+ `-o`, `--options` (opcional) Especifique una lista de opciones para publicar un componente. El argumento debe ser una cadena JSON válida o una ruta de archivo a un archivo JSON que contenga las opciones de publicación. Este argumento anula las opciones en la configuración de la CLI del GDK.
Esta característica está disponible para la versión 1.2.0 y versiones posteriores de la CLI de GDK.
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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'.
```
## list
Recupere la lista de plantillas de componentes y componentes de comunidad disponibles.
La CLI del GDK recupera los componentes de la comunidad del [catálogo de software de Greengrass](greengrass-software-catalog.md) y las plantillas de componentes del [repositorio de plantillas de componentes de AWS IoT Greengrass en GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates).
Puede pasar el resultado de este comando al comando [init](#greengrass-development-kit-cli-component-init) para inicializar los repositorios de componentes a partir de plantillas y componentes de la comunidad.
**Sinopsis**
```
$ gdk component list
[--template]
[--repository]
```
**Argumentos**
+ `-t`, `--template`: (opcional) especifique este argumento para enumerar las plantillas de componentes disponibles. Este comando muestra el nombre y el lenguaje de cada plantilla en el formato `name-language`. Por ejemplo, en `HelloWorld-python`, el nombre de la plantilla es `HelloWorld` y el lenguaje es `python`.
+ `-r`, `--repository`: (opcional) especifique este argumento para enumerar los repositorios de componentes de la comunidad disponibles.
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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
Utilice el comando `config` de la interfaz de la línea de comandos del kit de desarrollo de AWS IoT Greengrass (CLI del GDK) para modificar la configuración del GDK en el archivo de configuración, `gdk-config.json`.
**Topics**
+ [actualización](#greengrass-development-kit-cli-config-update)
## actualización
Inicie una petición interactiva para modificar los campos de un archivo de configuración del GDK existente.
**Sinopsis**
```
$ gdk config update
[--component]
```
**Argumentos**
+ `-c`, `--component`: Para actualizar los campos relacionados con los componentes del archivo `gdk-config.json`. Este argumento es obligatorio porque es la única opción.
**Output**
El siguiente ejemplo muestra el resultado obtenido luego de ejecutar este comando para configurar un componente.
```
$ 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
Utilice el comando `test-e2e` de la interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass (CLI del GDK) para inicializar, compilar y ejecutar módulos de prueba integrales en el proyecto del GDK.
**Topics**
+ [init](#greengrass-development-kit-cli-test-init)
+ [build](#greengrass-development-kit-cli-test-build)
+ [ejecutar](#greengrass-development-kit-cli-test-run)
## init
Inicie un proyecto de la CLI del GDK existente con un módulo de pruebas que utiliza Greengrass Testing Framework (GTF).
De forma predeterminada, la CLI del GDK recupera la plantilla del módulo maven del [repositorio de plantillas de componentes de AWS IoT Greengrass en GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates). Este módulo maven viene con una dependencia en el archivo JAR `aws-greengrass-testing-standalone`.
Este comando crea un nuevo directorio llamado `gg-e2e-tests` dentro del proyecto GDK. Si el directorio del módulo de pruebas ya existe y no está vacío, el comando se cierra sin hacer nada. Esta carpeta `gg-e2e-tests` contiene las definiciones de las características y los pasos de Cucumber estructurados en un proyecto de Maven.
Por defecto, este comando intentará usar la última versión de GTF.
**Sinopsis**
```
$ gdk test-e2e init
[--gtf-version]
```
**Argumentos**
+ `-ov`, `--gtf-version`: (opcional) la versión del GTF que se utilizará con el módulo de pruebas integrales del proyecto GDK. Este valor debe ser una de las versiones del GTF de [los lanzamientos](https://github.com/aws-greengrass/aws-greengrass-testing/releases). Este argumento anula la `gtf_version` en la configuración de la CLI del GDK.
**Output**
El siguiente ejemplo muestra el resultado que se obtiene al ejecutar este comando para inicializar el proyecto GDK con el módulo de pruebas.
```
$ 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
**nota**
Debe compilar el componente ejecutando **gdk component build** antes de compilar el módulo de prueba integral.
Creación del módulo de pruebas integral. La CLI del GDK crea el módulo de pruebas mediante el sistema de compilación que especifica en el [archivo de configuración de la CLI del GDK](gdk-cli-configuration-file.md), `gdk-config.json`, según la propiedad `test-e2e`. Debe ejecutar este comando en la misma carpeta en la que se encuentra el archivo `gdk-config.json`.
De forma predeterminada, la CLI del GDK usa el sistema de compilación Maven para crear el módulo de pruebas. Se requiere [Maven](https://maven.apache.org/) para ejecutar el comando `gdk test-e2e build`.
Debe compilar el componente ejecutando **gdk-component-build** antes de compilar el módulo de prueba, si los archivos de características de prueba tienen variables como `GDK_COMPONENT_NAME` y `GDK_COMPONENT_RECIPE_FILE` para interpolar.
Al ejecutar este comando, la CLI del GDK interpola todas las variables de la configuración del proyecto de GDK y crea el módulo `gg-e2e-tests` para generar el archivo JAR de prueba final.
**Sinopsis**
```
$ gdk test-e2e build
```
**Argumentos**
Ninguno
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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'
.........
```
## ejecutar
Ejecute el módulo de pruebas con las opciones de prueba del archivo de configuración del GDK.
**nota**
Debe compilar el módulo de pruebas ejecutando **gdk test-e2e build** antes de ejecutar las pruebas integrales.
**Sinopsis**
```
$ gdk test-e2e run
[--gtf-options]
```
**Argumentos**
+ `-oo`, `--gtf-options`: (opcional) especifique una lista de opciones para ejecutar las pruebas integrales. El argumento debe ser una cadena JSON válida o una ruta de archivo a un archivo JSON que contenga las opciones de GTF. Las opciones que se proporcionan en el archivo de configuración se combinan con las que se proporcionan en los argumentos del comando. Si una opción está presente en ambos lugares, la que se encuentra en el argumento tiene prioridad sobre la del archivo de configuración.
Si la opción `tags` no se especifica en este comando, GDK utiliza `Sample` para las etiquetas. Si `ggc-archive` no se especifica, GDK descarga la última versión del archivo del núcleo de Greengrass.
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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
.......
```
# Archivo de configuración la CLI del kit de desarrollo de Greengrass
La interfaz de línea de comandos del kit de desarrollo de AWS IoT Greengrass (CLI del GDK) lee un archivo de configuración denominado `gdk-config.json` para crear y publicar componentes. Este archivo de configuración debe estar en la raíz del repositorio del componente. Puede utilizar el [comando init](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-init) de la CLI del GDK para inicializar los repositorios de componentes con este archivo de configuración.
**Topics**
+ [Formato de archivo de configuración de la CLI del GDK](#gdk-config-format)
+ [Ejemplos de archivo de configuración de la CLI del GDK](#gdk-config-examples)
## Formato de archivo de configuración de la CLI del GDK
Al definir un archivo de configuración de la CLI del GDK para un componente, se especifica la siguiente información en formato JSON.
`gdk_version`
La versión mínima de la CLI del GDK que es compatible con este componente. Este valor debe ser una de las versiones de la CLI del GDK de los [lanzamientos](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases).
`component`
La configuración de este componente.
`componentName`
`author`
El autor o publicador del componente.
`version`
Esta es la versión del componente. Especifique uno de los siguientes valores:
+ `NEXT_PATCH`: al elegir esta opción, la CLI de GDK establece la versión al publicar el componente. La CLI de GDK consulta el servicio de AWS IoT Greengrass para identificar la versión más reciente publicada del componente. A continuación, establece la versión en la siguiente versión del parche posterior a esa versión. Si no ha publicado el componente antes, la CLI de GDK usa la versión `1.0.0`.
Si elige esta opción, no podrá usar la [CLI de Greengrass](greengrass-cli-component.md) para implementar y probar localmente el componente en su computadora de desarrollo local que ejecuta el software AWS IoT Greengrass Core. Para habilitar las implementaciones locales, debe especificar una versión semántica en su lugar.
+ Una versión semántica, como **1.0.0**. Las versiones semánticas siguen un sistema de números de *major*.*minor*.*patch*. Para obtener más información, consulte la [especificación semántica de la versión](https://semver.org/).
Si desarrolla componentes en un dispositivo principal de Greengrass en el que desee implementar y probar el componente, elija esta opción. Debe compilar el componente con una versión específica para crear implementaciones locales con la [CLI de Greengrass](greengrass-cli-component.md).
`build`
La configuración que se utilizará para convertir el origen de este componente en artefactos. Este objeto contiene la siguiente información:
`build_system`
El sistema de compilación que se va a utilizar. Puede elegir entre las siguientes opciones:
+ `zip`: empaqueta la carpeta del componente en un archivo ZIP para definirla como el único artefacto del componente. Elija esta opción para los siguientes tipos de componentes:
+ Componentes que usan lenguajes de programación interpretados, como Python o JavaScript.
+ Componentes que empaquetan archivos distintos del código, como modelos de machine learning u otros recursos.
La CLI de GDK comprime la carpeta del componente en un archivo zip con el mismo nombre que la carpeta del componente. Por ejemplo, si el nombre de la carpeta del componente es `HelloWorld`, la CLI de GDK crea un archivo zip denominado `HelloWorld.zip`.
**nota**
Si usa la versión 1.0.0 de la CLI de GDK en un dispositivo Windows, los nombres de las carpetas y los archivos zip de los componentes deben contener solo letras minúsculas.
Cuando la CLI de GDK comprime la carpeta del componente en un archivo zip, omite los siguientes archivos:
+ El archivo `gdk-config.json`
+ El archivo de receta (`recipe.json` o `recipe.yaml`)
+ Carpetas de compilación, como `greengrass-build`
+ `maven`: ejecuta el comando `mvn clean package` para compilar el origen del componente en artefactos. Elija esta opción para los componentes que usan [Maven](https://maven.apache.org/), como los componentes de Java.
En dispositivos Windows, esta característica está disponible para la versión 1.1.0 y posteriores de la CLI de GDK.
+ `gradle`: ejecuta el comando `gradle build` para compilar el origen del componente en artefactos. Elija esta opción para los componentes que usan [Gradle](https://gradle.org/). Esta característica está disponible para la versión 1.1.0 y posteriores de la CLI de GDK.
El sistema de compilación `gradle` admite Kotlin DSL como archivo de compilación. Esta característica está disponible para la versión 1.2.0 y versiones posteriores de la CLI de GDK.
+ `gradlew`: ejecuta el comando `gradlew` para compilar el origen del componente en artefactos. Elija esta opción para los componentes que usan el [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html).
Esta característica está disponible para la versión 1.2.0 y versiones posteriores de la CLI de GDK.
+ `custom`: ejecuta un comando personalizado para compilar el origen del componente en una receta y artefactos. Especifique el comando personalizado en el parámetro `custom_build_command`.
`custom_build_command`
(Opcional) El comando de compilación personalizado que se ejecuta en un sistema de compilación personalizado. Debe especificar este parámetro si especifica `custom` para `build_system`.
Este comando debe crear una receta y artefactos en las siguientes carpetas de la carpeta del componente. La CLI de GDK crea estas carpetas automáticamente al ejecutar el [comando component build](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build).
+ Carpeta de recetas: `greengrass-build/recipes`
+ Carpeta de artefactos: `greengrass-build/artifacts/componentName/componentVersion`
Sustituya *componentName* por el nombre del componente y sustituya *componentVersion* por la versión del componente o `NEXT_PATCH`.
Puede especificar una sola cadena o una lista de cadenas, donde cada cadena es una palabra del comando. Por ejemplo, para ejecutar un comando de compilación personalizado para un componente de C\$1\$1, puede especificar **cmake --build build --config Release** o **["cmake", "--build", "build", "--config", "Release"]**.
Para ver un ejemplo de un sistema de compilación personalizado, consulte [aws.greengrass.labs.LocalWebServer community component en GitHub](https://github.com/awslabs/aws-greengrass-labs-local-web-server).
`options`
(Opcional) Se utilizan opciones de configuración adicionales durante el proceso de creación del componente.
Esta característica está disponible para la versión 1.2.0 y versiones posteriores de la CLI de GDK.
`excludes`
Una lista de patrones globales que definen qué archivos se deben excluir del directorio de componentes al crear el archivo zip. Válido solo cuando `build_system` es `zip`.
En las versiones 1.4.0 y anteriores de la CLI del GDK, cualquier archivo que coincida con una entrada de la lista de exclusiones se excluye de todos los subdirectorios del componente. Para lograr el mismo comportamiento en las versiones 1.5.0 y posteriores de la CLI del GDK, anteponga `**/` a las entradas existentes en la lista de exclusiones. Por ejemplo, `*.txt` excluirá los archivos de texto solo del directorio; `**/*.txt` excluirá los archivos de texto de todos los directorios y subdirectorios.
En las versiones 1.5.0 y posteriores de la CLI del GDK, es posible que vea una advertencia durante la compilación del componente cuando `excludes` esté definido en el archivo de configuración del GDK. Para deshabilitar esta advertencia, defina la variable de entorno `GDK_EXCLUDES_WARN_IGNORE` en `true`.
La CLI del GDK siempre excluye los siguientes archivos del archivo zip:
+ El archivo `gdk-config.json`
+ El archivo de receta (`recipe.json` o `recipe.yaml`)
+ Carpetas de compilación, como `greengrass-build`
De forma predeterminada, se excluyen los siguientes archivos. Sin embargo, puede controlar cuáles de estos archivos se excluyen con la opción `excludes`.
+ Cualquier carpeta que comience con el prefijo “test” (`test*`)
+ Todos los archivos ocultos
+ La carpeta `node_modules`
Si especifica la opción `excludes`, la CLI del GDK excluirá solo los archivos que configuró con la opción `excludes`. Si no especifica la opción `excludes`, la CLI del GDK excluye los archivos y carpetas predeterminados indicados anteriormente.
`zip_name`
El nombre del archivo zip que se utilizará al crear un artefacto zip durante el proceso de creación. Válido solo cuando `build_system` es `zip`. Si `build_system` está vacío, el nombre del componente se utiliza como nombre del archivo zip.
`publish`
La configuración que se utilizará para publicar este componente en el servicio de AWS IoT Greengrass.
Si usa la versión 1.1.0 o posteriores de la CLI de GDK, puede especificar el argumento `--bucket` para especificar el bucket de S3 en el que la CLI de GDK carga los artefactos del componente. Si no especifica este argumento, la CLI de GDK se carga en el bucket de S3 cuyo nombre es `bucket-region-accountId`, donde *bucket* y *region* son los valores que especifica en `gdk-config.json` y *acountId* es el ID de su Cuenta de AWS. La CLI de GDK crea el bucket si no existe.
Este objeto contiene la siguiente información:
`bucket`
El nombre del bucket de S3 que se utilizará para alojar los artefactos de los componentes.
`region`
La Región de AWS donde la CLI del GDK publica este componente.
Esta propiedad es opcional si utiliza la CLI del GDK versión 1.3.0 o versiones posteriores.
`options`
(Opcional) Se utilizan opciones de configuración adicionales durante la creación de la versión del componente.
Esta característica está disponible para la versión 1.2.0 y versiones posteriores de la CLI de GDK.
`file_upload_args`
Una estructura JSON que contiene argumentos que se envían a Amazon S3 al cargar archivos a un bucket, como metadatos y mecanismos de cifrado. Para obtener una lista de los argumentos permitidos, consulte la clase [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) en la *documentación de Boto3*.
`test-e2e`
(Opcional) La configuración que se utilizará durante las pruebas integrales del componente. Esta característica está disponible para la CLI del GDK de versión 1.3.0 y versiones posteriores.
`build`
`build_system`: el sistema de compilación que se va a utilizar. La opción predeterminada es `maven`. Puede elegir entre las siguientes opciones:
+ `maven`: ejecuta el comando `mvn package` para compilar el módulo de pruebas. Elija esta opción para compilar el módulo de pruebas que usa [Maven](https://maven.apache.org/).
+ `gradle`: ejecuta el comando `gradle build` para compilar el módulo de pruebas. Elige esta opción para el módulo de pruebas que usa [Gradle](https://gradle.org/).
`gtf_version`
(Opcional) La versión del Greengrass Testing Framework (GTF) que se utilizará como dependencia del módulo de pruebas de extremo a extremo al inicializar el proyecto GDK con GTF. Este valor debe ser una de las versiones del GTF de [los lanzamientos](https://github.com/aws-greengrass/aws-greengrass-testing/releases). El valor predeterminado es la versión 1.1.0 de GTF.
`gtf_options`
(Opcional) Opciones de configuración adicionales utilizadas durante las pruebas integrales del componente.
En la siguiente lista, se incluyen las opciones que puede utilizar con la versión 1.1.0 de GTF.
+ `additional-plugins`: (opcional) complementos de Cucumber adicionales
+ `aws-region`: apunta a puntos de conexión regionales específicos para los servicios de AWS. El valor predeterminado es lo que detecta el SDK de AWS.
+ `credentials-path`: ruta de credenciales de perfil de AWS opcional. El valor predeterminado son las credenciales detectadas en el entorno host.
+ `credentials-path-rotation`: duración de rotación opcional para las credenciales de AWS. El valor predeterminado es de 15 minutos o `PT15M`.
+ `csr-path`: la ruta de la CSR mediante la cual se generará el certificado del dispositivo.
+ `device-mode`: el dispositivo objetivo que se está probando. El valor predeterminado es el dispositivo local.
+ `env-stage`: apunta al entorno de implementación de Greengrass. El valor predeterminado es de producción.
+ `existing-device-cert-arn`: el ARN de un certificado existente que desee usar como certificado de dispositivo para Greengrass.
+ `feature-path`: archivo o directorio que contiene archivos de características adicionales. El valor predeterminado es que no se usan archivos de características adicionales.
+ `gg-cli-version`: anula la versión de la CLI de Greengrass. El valor predeterminado es el que se encuentra en `ggc.version`.
+ `gg-component-bucket`: el nombre de un bucket de Amazon S3 existente que aloja los componentes de Greengrass.
+ `gg-component-overrides`: una lista de anulaciones de componentes de Greengrass.
+ `gg-persist`: una lista de elementos de prueba que persisten tras una ejecución de la prueba. El comportamiento predeterminado es no conservar nada. Los valores aceptados son: `aws.resources`, `installed.software` y `generated.files`.
+ `gg-runtime`: una lista de valores para influir en la forma en que la prueba interactúa con los recursos de la prueba. Estos valores sustituyen al parámetro `gg.persist`. Si el valor predeterminado está vacío, se asume que todos los recursos de prueba se administran por caso de prueba, incluido el tiempo de ejecución de Greengrass instalado. Los valores aceptados son: `aws.resources`, `installed.software` y `generated.files`.
+ `ggc-archive`: la ruta hacia el componente del núcleo de Greengrass archivado.
+ `ggc-install-root`: directorio para instalar el componente núcleo de Greengrass. Los valores predeterminados son test.temp.path y la carpeta de ejecución de la prueba.
+ `ggc-log-level`: establece el nivel de registro del núcleo de Greengrass para la ejecución de la prueba. El valor predeterminado es “INFO”.
+ `ggc-tes-rolename`: el rol de IAM que asumirá AWS IoT Greengrass Core para acceder a los servicios de AWS. Si no existe un rol con un nombre dado, se creará uno con una política de acceso predeterminada.
+ `ggc-trusted-plugins`: la lista separada por comas de las rutas (en el host) de los complementos de confianza que deben agregarse a Greengrass. Para indicar la ruta en el propio DUT, agregue el prefijo “dut:” a la ruta
+ `ggc-user-name`: el valor user:group posixUser para el núcleo de Greengrass. El valor predeterminado es el nombre de usuario actual con el que se ha iniciado sesión.
+ `ggc-version`: anula la versión del componente núcleo de Greengrass en ejecución. El valor predeterminado es el que se encuentra en ggc.archive.
+ `log-level`: nivel de registro de la ejecución de la prueba. El valor predeterminado es “INFO”.
+ `parallel-config`: conjunto de índices de lotes y número de lotes como cadena JSON. El valor predeterminado del índice de lotes es 0 y el número de lotes es 1.
+ `proxy-url`: configura todas las pruebas para enrutar el tráfico a través de esta URL.
+ `tags`: ejecuta únicamente etiquetas de características. Se puede intersecar con “&”
+ `test-id-prefix`: un prefijo común que se aplica a todos los recursos específicos de la prueba, incluidos los nombres y las etiquetas de los recursos de AWS. El prefijo predeterminado es “gg”.
+ `test-log-path`: directorio que contendrá los resultados de toda la ejecución de la prueba. El valor predeterminado es “testResults”.
+ `test-results-json`: marcador para determinar si se genera un informe JSON de Cucumber resultante escrito en el disco. El valor predeterminado es true (verdadero).
+ `test-results-log`: marcador para determinar si la salida de la consola se genera escrita en el disco. El valor predeterminado es falso.
+ `test-results-xml`: marcador para determinar si se genera un informe XML de JUnit resultante escrito en el disco. El valor predeterminado es true (verdadero).
+ `test-temp-path`: directorio para generar artefactos de prueba locales. El valor predeterminado es un directorio temporal aleatorio con el prefijo gg-testing.
+ `timeout-multiplier`: multiplicador proporcionado para todos los tiempos de espera de las pruebas. El valor predeterminado es 1.0.
## Ejemplos de archivo de configuración de la CLI del GDK
Puede hacer referencia a los siguientes ejemplos de archivos de configuración de la CLI del GDK para ayudarlo a configurar los entornos de componentes de Greengrass.
### Hello World (Python)
El siguiente archivo de configuración de la CLI del GDK admite un componente Hello world que ejecuta un script de Python. Este archivo de configuración utiliza el sistema de compilación `zip` para empaquetar el script de Python del componente en un archivo ZIP que la CLI del GDK carga como un artefacto.
```
{
"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"
}
}
```
### Hello World (Java)
El siguiente archivo de configuración de la CLI del GDK admite un componente Hello world que ejecuta una aplicación Java. Este archivo de configuración utiliza el sistema de compilación `maven` para empaquetar el código de origen Java del componente en un archivo JAR que la CLI de GDK carga como un artefacto.
```
{
"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"
}
}
```
### Componentes de la comunidad
Varios componentes de la comunidad del [catálogo de software de Greengrass](greengrass-software-catalog.md) utilizan la CLI del GDK. Puede explorar los archivos de configuración de la CLI del GDK en los repositorios de estos componentes.
**Cómo ver los archivos de configuración de la CLI del GDK de los componentes de la comunidad**
1. Ejecute el siguiente comando para mostrar en una lista los componentes de la comunidad que utilizan la CLI del GDK.
```
gdk component list --repository
```
La respuesta muestra el nombre del repositorio de GitHub para cada componente de la comunidad que usa la CLI del GDK. Cada repositorio existe en la organización `awslabs`.
```
[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. Abra el repositorio de GitHub de un componente de la comunidad en la siguiente URL. Sustituya *community-component-name* por el nombre de un componente de la comunidad del paso anterior.
```
https://github.com/awslabs/community-component-name
```
# Interfaz de la línea de comandos de Greengrass
La interfaz de la línea de comandos (CLI) de Greengrass le permite interactuar con AWS IoT Greengrass Core en el dispositivo para desarrollar componentes y depurar problemas de forma local. Por ejemplo, puede usar la CLI de Greengrass para crear una implementación local y reiniciar un componente en el dispositivo principal.
Implemente el [componente CLI de Greengrass](greengrass-cli-component.md) (`aws.greengrass.Cli`) para instalar la CLI de Greengrass en el dispositivo principal.
**importante**
Se recomienda usar este componente solo en entornos de desarrollo y no en entornos de producción. Este componente brinda acceso a información y operaciones que, por lo general, no necesitará en un entorno de producción. Siga el principio de privilegio mínimo al implementar este componente solo en los dispositivos principales donde lo necesite.
**Topics**
+ [Instalación de la CLI de Greengrass](install-gg-cli.md)
+ [Comandos de la CLI de Greengrass](gg-cli-reference.md)
# Instalación de la CLI de Greengrass
Puede instalar la CLI de Greengrass de una de las siguientes maneras:
+ Utilice `--deploy-dev-tools` este argumento la primera vez que configure el software AWS IoT Greengrass Core en su dispositivo. También debe especificar `--provision true` si desea aplicar este argumento.
+ Implemente el componente de la CLI de Greengrass (`aws.greengrass.Cli`) en su dispositivo.
En esta sección, se describen los pasos para implementar el componente de la CLI de Greengrass. Para obtener información acerca de la instalación de la CLI de Greengrass durante la configuración inicial, consulte [Tutorial: Introducción a AWS IoT Greengrass V2](getting-started.md).
## Requisitos previos
Para implementar el componente de la CLI de Greengrass, asegúrese de que cumple los siguientes requisitos:
+ AWS IoT Greengrass El software principal está instalado y configurado en el dispositivo principal. Para obtener más información, consulte [Tutorial: Introducción a AWS IoT Greengrass V2](getting-started.md).
+ Para utilizar el AWS CLI para implementar la CLI de Greengrass, debe haber instalado y configurado el. AWS CLI Para obtener más información, consulte [Configuración de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) en la *Guía del usuario de AWS Command Line Interface *.
+ Debe estar autorizado a utilizar la CLI de Greengrass para interactuar con el software AWS IoT Greengrass principal. Realice una de las siguientes acciones para usar la CLI de Greengrass:
+ Utilice el usuario del sistema que ejecuta el software AWS IoT Greengrass Core.
+ Utilice un usuario con permisos raíz o administrativos. En los dispositivos principales de Linux, puede utilizar `sudo` para obtener permisos de raíz.
+ Utilice un usuario del sistema que esté en un grupo que especifique en los parámetros de configuración `AuthorizedPosixGroups` o `AuthorizedWindowsGroups` al implementar el componente. Para obtener más información, consulte [Configuración del componente de la CLI de Greengrass](greengrass-cli-component.md#greengrass-cli-component-configuration).
## Implementación del componente de la CLI de Greengrass
Complete los siguientes pasos para implementar el componente de la CLI de Greengrass en su dispositivo principal:
### Cómo implementar el componente de la CLI de Greengrass (consola)
1. Inicie sesión en la [consola de AWS IoT Greengrass](https://console.aws.amazon.com/greengrass).
1. En el menú de navegación, elija **Componentes**.
1. En la página **Componentes**, en la pestaña **Componentes públicos**, elija `aws.greengrass.Cli`.
1. En la página **aws.greengrass.Cli**, elija **Implementar**.
1. En **Agregar a la implementación**, elija **Crear nueva implementación**.
1. En la página **Especificar destino**, en **Objetivos de implementación**, en la lista **Nombre de destino**, elija el grupo de Greengrass en el que desee realizar la implementación y elija **Siguiente**.
1. En la página **Seleccionar componentes**, compruebe que el componente **aws.greengrass.Cli** esté seleccionado y elija **Siguiente**.
1. En la página **Configurar componentes**, mantenga los ajustes de configuración predeterminados y seleccione **Siguiente**.
1. En la página **Configurar ajustes avanzados**, mantenga los ajustes de configuración predeterminados y seleccione **Siguiente**.
1. En la página **Revisar**, elija **Implementar**.
### Cómo implementar el componente de la CLI de Greengrass (AWS CLI)
1. En su dispositivo, cree un archivo `deployment.json` que defina la configuración de implementación del componente de la CLI de Greengrass. Este archivo debería tener el siguiente aspecto:
```
{
"targetArn":"targetArn",
"components": {
"aws.greengrass.Cli": {
"componentVersion": "2.17.0",
"configurationUpdate": {
"merge": "{\"AuthorizedPosixGroups\":\",,...,\",\"AuthorizedWindowsGroups\":\",,...,\"}"
}
}
}
}
```
+ En el campo `target`, sustituya `targetArn` por el Nombre de recurso de Amazon (ARN) del objeto o grupo de objetos a la que apunte la implementación, en el siguiente formato:
+ Cosa: `arn:aws:iot:region:account-id:thing/thingName`
+ Grupo de cosas: `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
+ En el objeto del componente `aws.greengrass.Cli`, especifique los valores de la siguiente manera:
`version`
La versión del componente de la CLI de Greengrass.
`configurationUpdate.AuthorizedPosixGroups`
(Opcional) Una cadena que contiene una lista de grupos de sistema separados por comas. Usted autoriza a estos grupos de sistemas a utilizar la CLI de Greengrass para interactuar con el software AWS IoT Greengrass principal. Puede especificar los nombres de los grupos o grupos IDs. Por ejemplo, `group1,1002,group3` autoriza a tres grupos de sistemas (`group1`, `1002` y `group3`) a utilizar la CLI de Greengrass.
Si no especifica ningún grupo para autorizarlo, puede usar la CLI de Greengrass como usuario root (`sudo`) o como usuario del sistema que ejecuta el software AWS IoT Greengrass Core.
`configurationUpdate.AuthorizedWindowsGroups`
(Opcional) Una cadena que contiene una lista de grupos de sistema separados por comas. Usted autoriza a estos grupos de sistemas a utilizar la CLI de Greengrass para interactuar con el software AWS IoT Greengrass principal. Puede especificar los nombres de los grupos o grupos IDs. Por ejemplo, `group1,1002,group3` autoriza a tres grupos de sistemas (`group1`, `1002` y `group3`) a utilizar la CLI de Greengrass.
Si no especifica ningún grupo para autorizarlo, puede usar la CLI de Greengrass como administrador o como usuario del sistema que ejecuta el software AWS IoT Greengrass principal.
1. Ejecute el siguiente comando para implementar los componentes de la CLI de Greengrass en el dispositivo:
```
$ aws greengrassv2 create-deployment --cli-input-json file://path/to/deployment.json
```
Durante la instalación, el componente agrega un enlace simbólico a `greengrass-cli` en la carpeta `/greengrass/v2/bin` del dispositivo y usted ejecuta la CLI de Greengrass desde esta ruta. Para ejecutar la CLI de Greengrass sin su ruta absoluta, agregue la carpeta `/greengrass/v2/bin` a la variable PATH. Para verificar la instalación de la CLI de Greengrass, ejecute el comando siguiente:
------
#### [ Linux or Unix ]
```
/greengrass/v2/bin/greengrass-cli help
```
------
#### [ Windows ]
```
C:\greengrass\v2\bin\greengrass-cli help
```
------
Debería ver los siguientes datos de salida:
```
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.
```
Si no encuentra `greengrass-cli`, es posible que la implementación no haya podido instalar la CLI de Greengrass. Para obtener más información, consulte [Solución de problemas AWS IoT Greengrass V2](troubleshooting.md).
# Comandos de la CLI de Greengrass
La CLI de Greengrass proporciona una interfaz de línea de comandos para interactuar localmente con el dispositivo principal de AWS IoT Greengrass. Los comandos de la CLI de Greengrass utilizan el siguiente formato.
```
$ greengrass-cli [arguments]
```
De forma predeterminada, el archivo ejecutable `greengrass-cli` de la carpeta `/greengrass/v2/bin/` interactúa con la versión del software AWS IoT Greengrass Core que se ejecuta en la carpeta `/greengrass/v2`. Si llama a un archivo ejecutable que no se encuentra en esta ubicación o si desea interactuar con el software AWS IoT Greengrass Core en una ubicación diferente, debe utilizar uno de los siguientes métodos para especificar de forma explícita la ruta raíz del software AWS IoT Greengrass Core con el que desea interactuar:
+ Establezca la variable de entorno `GGC_ROOT_PATH` en `/greengrass/v2`.
+ Agregue los argumentos `--ggcRootPath /greengrass/v2` a su comando como se muestra en el siguiente ejemplo.
```
greengrass-cli --ggcRootPath /greengrass/v2 [arguments]
```
Puede utilizar los siguientes argumentos con cualquier comando:
+ Utilice `--help` para obtener información sobre un comando de la CLI específico de Greengrass.
+ Utilice `--version` para obtener información sobre la versión de la CLI de Greengrass.
En esta sección, se describen los comandos de la CLI de Greengrass y se proporcionan ejemplos de estos comandos. La sinopsis de cada comando muestra sus argumentos y cómo se utilizan. Los argumentos opcionales deben ir entre corchetes.
**Topics**
+ [componente](gg-cli-component.md)
+ [Implementación](gg-cli-deployment.md)
+ [registros](gg-cli-logs.md)
+ [get-debug-password](gg-cli-get-debug-password.md)
# componente
Utilice el comando `component` para interactuar con los componentes locales del dispositivo principal.
**Subcomandos**
+ [Detalles](#component-details)
+ [list](#component-list)
+ [reiniciar](#component-restart)
+ [parar](#component-stop)
## Detalles
Recupera la versión, el estado y la configuración de un componente.
**Sinopsis**
```
greengrass-cli component details --name
```
**Argumentos**
`--name`, `-n`. El nombre del componente.
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ sudo greengrass-cli component details --name MyComponent
Component Name: MyComponent
Version: 1.0.0
State: RUNNING
Configuration: null
```
## list
Recupera el nombre, la versión, el estado y la configuración de cada componente instalado en el dispositivo.
**Sinopsis**
```
greengrass-cli component list
```
**Argumentos**
Ninguno
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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"}
```
## reiniciar
Reinicie los componentes.
**Sinopsis**
```
greengrass-cli component restart --names ,...
```
**Argumentos**
`--names`, `-n`. El nombre del componente. Se requiere al menos el nombre de un componente. Puede especificar nombres de componentes adicionales, separando cada nombre con una coma.
**Output**
Ninguno
## parar
Detenga la ejecución de los componentes.
**Sinopsis**
```
greengrass-cli component stop --names ,...
```
**Argumentos**
`--names`, `-n`. El nombre del componente. Se requiere al menos el nombre de un componente. Si es necesario, puede especificar nombres de componentes adicionales, separando cada nombre con una coma.
**Output**
Ninguno
# Implementación
Utilice el comando `deployment` para interactuar con los componentes locales del dispositivo principal.
Para supervisar el progreso de una implementación local, use el subcomando `status`. No puede supervisar el progreso de una implementación local mediante la consola.
**Subcomandos**
+ [crear](#deployment-create)
+ [cancelar](#deployment-cancel)
+ [list](#deployment-list)
+ [status](#deployment-status)
## crear
Cree o actualice una implementación local mediante recetas de componentes, artefactos y argumentos de tiempo de ejecución específicos.
**Sinopsis**
```
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 ]
```
**Argumentos**
+ `--recipeDir`, `-r`. La ruta completa a la carpeta que contiene los archivos de recetas de los componentes.
+ `--artifactDir`, `-a`. La ruta completa a la carpeta que contiene los archivos de artefactos que desea incluir en su implementación. La carpeta de artefactos debe contener la siguiente estructura de directorios:
```
/path/to/artifact/folder///
```
+ `--update-config`, `-c`. Los argumentos de configuración de la implementación, proporcionados como una cadena JSON o un archivo JSON. La cadena JSON debe tener el siguiente formato:
```
{ \
"componentName": { \
"MERGE": {"config-key": "config-value"}, \
"RESET": ["path/to/reset/"] \
} \
}
```
`MERGE` y `RESET` distinguen entre mayúsculas y minúsculas y deben estar en mayúsculas.
+ `--groupId`, `-g`. El grupo de objetos de destino de la implementación.
+ `--merge`, `-m`. El nombre y la versión del componente de destino que desea agregar o actualizar. Debe proporcionar la información del componente en el formato `=`. Utilice un argumento diferente para cada componente adicional que desee especificar. Si es necesario, utilice el argumento `--runWith` para proporcionar información de `posixUser`, `posixGroup` y `windowsUser` para ejecutar el componente.
+ `--runWith`. La información de `posixUser`, `posixGroup` y `windowsUser` para ejecutar un componente genérico o de Lambda. Debe proporcionar la información con el formato `:{posixUser|windowsUser}=[:<=posixGroup>]`. Por ejemplo, puede especificar **HelloWorld:posixUser=ggc\$1user:ggc\$1group** o **HelloWorld:windowsUser=ggc\$1user**. Utilice un argumento diferente para cada opción adicional que desee especificar.
Para obtener más información, consulte [Configuración del usuario que ejecuta los componentes](configure-greengrass-core-v2.md#configure-component-user).
+ `--systemLimits`. Los límites de recursos del sistema que se aplicarán a los procesos de los componentes de Lambda genéricos y no contenerizados en el dispositivo principal. Puede configurar la cantidad máxima de uso de CPU y RAM que cada proceso de un componente puede utilizar. Especifique un objeto JSON serializado o la ruta de un archivo a un archivo JSON. El objeto JSON debe incluir el siguiente formato.
```
{ \
"componentName": { \
"cpus": cpuTimeLimit, \
"memory": memoryLimitInKb \
} \
}
```
Puede configurar los siguientes límites de recursos del sistema para cada componente:
+ `cpus`: la cantidad máxima de tiempo de CPU que los procesos de este componente pueden usar en el dispositivo principal. El tiempo total de CPU de un dispositivo principal equivale a la cantidad de núcleos de CPU del dispositivo. Por ejemplo, en un dispositivo principal con 4 núcleos de CPU, puede establecer este valor en `2` para limitar los procesos del componente al 50 % de uso de cada núcleo de CPU. En un dispositivo con 1 núcleo de CPU, puede establecer este valor en `0.25` para limitar los procesos del componente al 25 % de uso de la CPU. Si establece este valor en un número superior al número de núcleos de la CPU, el software AWS IoT Greengrass Core no limita el uso de la CPU del componente.
+ `memory`: la cantidad máxima de RAM, expresada en kilobytes, que los procesos de un componente pueden usar en el dispositivo principal.
Para obtener más información, consulte [Configuración de los límites de recursos del sistema para los componentes](configure-greengrass-core-v2.md#configure-component-system-resource-limits).
Esta función está disponible para la versión 2.4.0 y versiones posteriores del [componente núcleo de Greengrass y la CLI de Greengrass](greengrass-nucleus-component.md) en los dispositivos principales de Linux. AWS IoT Greengrass actualmente no admite esta función en los dispositivos principales de Windows.
+ `--remove`. El nombre del componente de destino que desea eliminar de una implementación local. Si el componente define un paso [del ciclo de vida de la desinstalación](component-recipe-reference.md#uninstall-lifecycle-definition), el software AWS IoT Greengrass principal ejecuta el script de desinstalación antes de eliminar el componente. Para eliminar un componente que se combinó de una implementación en la nube, debe proporcionar el ID de grupo del grupo de objetos de destino en el siguiente formato:
------
#### [ Greengrass nucleus v2.4.0 and later ]
```
--remove --groupId
```
------
#### [ Earlier than v2.4.0 ]
```
--remove --groupId thinggroup/
```
------
+ `--failure-handling-policy`. Defina la acción que se lleva a cabo cuando una implementación da error. Hay dos acciones que puede especificar:
+ `ROLLBACK` –
+ `DO_NOTHING` –
Esta característica está disponible para versión 2.11.0 y versiones posteriores de [Núcleo de Greengrass](greengrass-nucleus-component.md).
**Salida**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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
```
## cancelar
Cancela la implementación especificada.
Sinopsis
```
greengrass-cli deployment cancel
-i
```
Argumentos
`-i`. El identificador único de la implementación que se va a cancelar. El ID de implementación se devuelve en el resultado del comando `create`.
Output
+ Ninguno
## list
Recupere el estado de las últimas 10 implementaciones locales.
**Sinopsis**
```
greengrass-cli deployment list
```
**Argumentos**
Ninguno
**Salida**
El siguiente ejemplo muestra los resultados del comando. Según el estado de la implementación, el resultado muestra uno de los siguientes valores de estado: `IN_PROGRESS`, `SUCCEEDED` o `FAILED`.
```
$ sudo greengrass-cli deployment list
44d89f46-1a29-4044-ad89-5151213dfcbc: SUCCEEDED
Created on: 6/27/23 11:05 AM
```
## status
Recupere el estado de una implementación específica.
**Sinopsis**
```
greengrass-cli deployment status -i
```
**Argumentos**
`-i`. El ID de la implementación.
**Salida**
El siguiente ejemplo muestra los resultados del comando. Según el estado de la implementación, el resultado muestra uno de los siguientes valores de estado: `IN_PROGRESS`, `SUCCEEDED` o `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
```
# registros
Utilice el `logs` comando para analizar los registros de Greengrass en el dispositivo principal.
**Subcomandos**
+ [introducción](#logs-get)
+ [list-keywords](#logs-list-keywords)
+ [list-log-files](#logs-list-log-files)
## introducción
Recopile, filtre y visualice los archivos de registro de Greengrass. Este comando solo admite archivos de registro con formato JSON. Puede especificar el [formato de registro](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-logging-format) en la configuración del núcleo.
**Sinopsis**
```
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 ]
```
**Argumentos**
+ `--log-dir`, `-ld`. La ruta al directorio para comprobar si hay archivos de registro, por ejemplo, **`/greengrass/v2`/logs**. No lo use con `--syslog`. Utilice un argumento diferente para cada directorio adicional que desee especificar. Debe especificar al menos una opción entre `--log-dir` o `--log-file`. También puede utilizar ambos argumentos en un único comando.
+ `--log-file`, `-lf`. Las rutas de los directorios de registro que desee utilizar. Utilice un argumento diferente para cada directorio adicional que desee especificar. Debe especificar al menos una opción entre `--log-dir` o `--log-file`. También puede utilizar ambos argumentos en un único comando.
+ `--follow`, `-fol`. Muestra las actualizaciones de registro a medida que se producen. La CLI de Greengrass continúa ejecutándose y lee los registros especificados. Si especifica un intervalo de tiempo, la CLI de Greengrass deja de inspeccionar los registros una vez finalizados todos los intervalos de tiempo.
+ `--filter`, `-f`. La palabra clave, las expresiones regulares o el par clave-valor que se va a utilizar como filtro. Proporcione este valor como cadena, expresión regular o par clave-valor. Utilice un argumento diferente para cada filtro adicional que desee especificar.
Cuando se evalúan, los filtros múltiples especificados en un único argumento se separan mediante operadores OR y los filtros especificados en argumentos adicionales se combinan con los operadores AND. Por ejemplo, si su comando incluye `--filter "installed" --filter "name=alpha,name=beta"`, la CLI de Greengrass filtrará y mostrará los mensajes de registro que contengan tanto la palabra clave `installed` como una clave `name` que incluya los valores `alpha` o `beta`.
+ `--time-window`, `-t`. El intervalo de tiempo durante el que se mostrará la información del registro. Puede utilizar tanto marcas temporales exactas como compensaciones relativas. Debe proporcionar la información con el formato `,`. Si no especifica la hora de inicio ni la hora de finalización, el valor de esa opción se establece de forma predeterminada en la fecha y hora actuales del sistema. Utilice un argumento diferente para cada intervalo de tiempo adicional que desee especificar.
La CLI de Greengrass admite los siguientes formatos para las marcas temporales:
+ `yyyy-MM-DD`, por ejemplo, `2020-06-30`. La hora predeterminada es 00:00:00 cuando se utiliza este formato.
`yyyyMMDD`, por ejemplo, `20200630`. La hora predeterminada es 00:00:00 cuando se utiliza este formato.
`HH:mm:ss`, por ejemplo, `15:30:45`. La fecha por defecto es la fecha actual del sistema cuando se utiliza este formato.
`HH:mm:ssSSS`, por ejemplo, `15:30:45`. La fecha establece de forma predeterminada la fecha actual del sistema cuando se utiliza este formato.
`YYYY-MM-DD'T'HH:mm:ss'Z'`, por ejemplo, `2020-06-30T15:30:45Z`.
`YYYY-MM-DD'T'HH:mm:ss`, por ejemplo, `2020-06-30T15:30:45`.
`yyyy-MM-dd'T'HH:mm:ss.SSS`, por ejemplo, `2020-06-30T15:30:45.250`.
Las compensaciones relativas especifican un desfase del periodo con respecto a la hora actual del sistema. La CLI de Greengrass admite el siguiente formato para las compensaciones relativas: `+|-[h|hr|hours][valuem|min|minutes][value]s|sec|seconds`.
Por ejemplo, el siguiente argumento para especificar un intervalo de tiempo entre 1 hora y 2 horas y 15 minutos antes de la hora actual es `--time-window -2h15min,-1hr`.
+ `--verbose`. Muestre todos los campos de los mensajes de registro. No lo use con `--syslog`.
+ `--no-color`, `-nc`. Elimine el código de colores. El código de colores predeterminado para los mensajes de registro utiliza texto rojo en negrita. Solo admite terminales tipo UNIX porque utiliza secuencias de escape ANSI.
+ `--before`, `-b`. El número de líneas que se deben mostrar antes de una entrada de registro coincidente. El valor predeterminado es 0.
+ `--after`, `-a`. El número de líneas que se muestran después de una entrada de registro coincidente. El valor predeterminado es 0.
+ `--syslog`. Procese todos los archivos de registro mediante el protocolo syslog definido en el RFC3164. No lo use con `--log-dir` y `--verbose`. El protocolo syslog usa el siguiente formato: `"<$Priority>$Timestamp $Host $Logger ($Class): $Message"`. Si no especifica un archivo de registro, la CLI de Greengrass lee los mensajes de registro de las siguientes ubicaciones: `/var/log/messages`, `/var/log/syslog` o `/var/log/system.log`.
AWS IoT Greengrass actualmente no admite esta característica en los dispositivos principales de Windows.
+ `--max-log-queue-size`, `-m`. El número máximo de entradas de registro que se van a asignar a la memoria. Utilice esta opción para optimizar el uso de la memoria. El valor predeterminado es 100.
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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
```
## list-keywords
Muestra las palabras clave sugeridas que puede usar para filtrar los archivos de registro.
**Sinopsis**
```
greengrass-cli logs list-keywords [arguments]
```
**Argumentos**
Ninguno
**Output**
Los siguientes ejemplos muestran los resultados del comando.
```
$ 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
Muestra los archivos de registro que se encuentran en el directorio especificado.
**Sinopsis**
```
greengrass-cli logs list-log-files [arguments]
```
**Argumentos**
`--log-dir`, `-ld`. La ruta al directorio para comprobar los archivos de registro.
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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
Utilice el comando `get-debug-password` para imprimir una contraseña generada aleatoriamente para el [componente de la consola de depuración local](local-debug-console-component.md) (`aws.greengrass.LocalDebugConsole`). La contraseña caduca 8 horas después de generarse.
**Sinopsis**
```
greengrass-cli get-debug-password
```
**Argumentos**
Ninguno
**Output**
El siguiente ejemplo muestra los resultados del comando.
```
$ 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
```
# Utilice el marco AWS IoT Greengrass de pruebas
Greengrass Testing Framework (GTF) es un conjunto de componentes básicos que respaldan la end-to-end automatización desde la perspectiva del cliente. GTF utiliza [Cucumber como motor](https://cucumber.io) de funciones. AWS IoT Greengrass utiliza los mismos componentes básicos para calificar los cambios de software en varios dispositivos. Para obtener más información, consulte [Greengrass Testing Framework en Github](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1).
El GTF se implementa con Cucumber, una herramienta que se utiliza para ejecutar pruebas automatizadas, a fin de fomentar un desarrollo impulsado por el comportamiento (BDD) de los componentes. En Cucumber, las características de este sistema se describen en un tipo especial de archivo llamado `feature`. Cada característica se describe en un formato legible por humanos llamado escenarios, que son especificaciones que se pueden convertir en pruebas automatizadas. Cada escenario se describe como una serie de pasos que definen las interacciones y los resultados del sistema que se está probando con un lenguaje de dominio específico llamado Gherkin. Un [paso de Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) se vincula al código de programación mediante un método llamado definición de pasos que conecta la especificación al flujo de prueba. Las definiciones de pasos en GTF se implementan con Java.
**Topics**
+ [Funcionamiento](#gg-testing-framework-how-gtf-works)
+ [Registros de cambios](#gtf-changelog)
+ [Opciones de configuración de Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutorial: Ejecute end-to-end pruebas con Greengrass Testing Framework y Greengrass Development Kit](run-e2e-tests-tutorial.md)
+ [Tutorial: Uso de una prueba de confianza del conjunto de pruebas de confianza](confidence-tests-tutorial.md)
## Funcionamiento
AWS IoT Greengrass distribuye el GTF como un JAR independiente que consta de varios módulos de Java. Para utilizar el GTF para end-to-end probar componentes, debe implementar las pruebas en un proyecto de Java. Agregar el JAR compatible con las pruebas como dependencia en el proyecto de Java le permite utilizar la funcionalidad existente del GTF y ampliarla mediante la escritura de sus propios casos de prueba personalizados. Para ejecutar los casos de prueba personalizados, puede crear el proyecto Java y ejecutar el JAR de destino con las opciones de configuración que se describen en [Opciones de configuración de Greengrass Testing Framework](configuration-options-gtf.md).
### JAR independiente del GTF
Greengrass utiliza Cloudfront como repositorio de [Maven](https://maven.apache.org/) para alojar diferentes versiones del JAR independiente del GTF. Para obtener una lista completa de las versiones del GTF, consulte los [lanzamientos de GTF](https://github.com/aws-greengrass/aws-greengrass-testing/releases).
El JAR independiente del GTF incluye los siguientes módulos. No se limita solo a estos módulos. Puede seleccionar cada una de estas dependencias por separado en su proyecto o incluirlas todas a la vez en el [archivo JAR independiente de prueba](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone).
+ `aws-greengrass-testing-resources`: Este módulo proporciona una abstracción para gestionar el ciclo de vida de un AWS recurso durante el transcurso de una prueba. Puedes usarlo para definir tus AWS recursos personalizados mediante la `ResourceSpec` abstracción, de modo que GTF pueda encargarse de crear y eliminar esos recursos por ti.
+ `aws-greengrass-testing-platform`: este módulo proporciona una abstracción en la plataforma para el dispositivo que se prueba durante el ciclo de vida de la prueba. Contiene una herramienta APIs para interactuar con el sistema operativo independientemente de la plataforma y se puede utilizar para simular los comandos que se ejecutan en la consola del dispositivo.
+ `aws-greengrass-testing-components`: este módulo consta de componentes de muestra que se utilizan para probar las características principales de Greengrass, como las implementaciones, el IPC y otras características.
+ `aws-greengrass-testing-features`: este módulo consta de pasos comunes reutilizables y las definiciones que se utilizan para realizar pruebas en el entorno de Greengrass.
**Topics**
+ [Funcionamiento](#gg-testing-framework-how-gtf-works)
+ [Registros de cambios](#gtf-changelog)
+ [Opciones de configuración de Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutorial: Ejecute end-to-end pruebas con Greengrass Testing Framework y Greengrass Development Kit](run-e2e-tests-tutorial.md)
+ [Tutorial: Uso de una prueba de confianza del conjunto de pruebas de confianza](confidence-tests-tutorial.md)
## Registros de cambios
En la siguiente tabla, se describen los cambios en cada versión del GTF. Para obtener más información, consulte la [página de versiones de GTF](https://github.com/aws-greengrass/aws-greengrass-testing/releases) en GitHub.
| **Versión** | **Cambios** |
| --- | --- |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.0.0 | Versión inicial. |
# Opciones de configuración de Greengrass Testing Framework
## Opciones de configuración de GTF
Greengrass Testing Framework (GTF) le permite configurar ciertos parámetros durante el inicio del proceso de prueba integral para orquestrar el flujo de pruebas. Puede especificar estas opciones de configuración como argumentos de la CLI para el JAR independiente de GTF.
La versión 1.1.0 y posteriores de GTF ofrecen las siguientes opciones de configuración.
+ `additional-plugins`: (opcional) complementos de Cucumber adicionales
+ `aws-region`: apunta a puntos de conexión regionales específicos para los servicios de AWS. El valor predeterminado es lo que detecta el SDK de AWS.
+ `credentials-path`: ruta de credenciales de perfil de AWS opcional. El valor predeterminado son las credenciales detectadas en el entorno host.
+ `credentials-path-rotation`: duración de rotación opcional para las credenciales de AWS. El valor predeterminado es de 15 minutos o `PT15M`.
+ `csr-path`: la ruta de la CSR mediante la cual se generará el certificado del dispositivo.
+ `device-mode`: el dispositivo objetivo que se está probando. El valor predeterminado es el dispositivo local.
+ `env-stage`: apunta al entorno de implementación de Greengrass. El valor predeterminado es de producción.
+ `existing-device-cert-arn`: el ARN de un certificado existente que desee usar como certificado de dispositivo para Greengrass.
+ `feature-path`: archivo o directorio que contiene archivos de características adicionales. El valor predeterminado es que no se usan archivos de características adicionales.
+ `gg-cli-version`: anula la versión de la CLI de Greengrass. El valor predeterminado es el que se encuentra en `ggc.version`.
+ `gg-component-bucket`: el nombre de un bucket de Amazon S3 existente que aloja los componentes de Greengrass.
+ `gg-component-overrides`: una lista de anulaciones de componentes de Greengrass.
+ `gg-persist`: una lista de elementos de prueba que persisten tras una ejecución de la prueba. El comportamiento predeterminado es no conservar nada. Los valores aceptados son: `aws.resources`, `installed.software` y `generated.files`.
+ `gg-runtime`: una lista de valores para influir en la forma en que la prueba interactúa con los recursos de la prueba. Estos valores sustituyen al parámetro `gg.persist`. Si el valor predeterminado está vacío, se asume que todos los recursos de prueba se administran por caso de prueba, incluido el tiempo de ejecución de Greengrass instalado. Los valores aceptados son: `aws.resources`, `installed.software` y `generated.files`.
+ `ggc-archive`: la ruta hacia el componente del núcleo de Greengrass archivado.
+ `ggc-install-root`: directorio para instalar el componente núcleo de Greengrass. Los valores predeterminados son test.temp.path y la carpeta de ejecución de la prueba.
+ `ggc-log-level`: establece el nivel de registro del núcleo de Greengrass para la ejecución de la prueba. El valor predeterminado es “INFO”.
+ `ggc-tes-rolename`: el rol de IAM que asumirá AWS IoT Greengrass Core para acceder a los servicios de AWS. Si no existe un rol con un nombre dado, se creará uno con una política de acceso predeterminada.
+ `ggc-trusted-plugins`: la lista separada por comas de las rutas (en el host) de los complementos de confianza que deben agregarse a Greengrass. Para indicar la ruta en el propio DUT, agregue el prefijo “dut:” a la ruta
+ `ggc-user-name`: el valor user:group posixUser para el núcleo de Greengrass. El valor predeterminado es el nombre de usuario actual con el que se ha iniciado sesión.
+ `ggc-version`: anula la versión del componente núcleo de Greengrass en ejecución. El valor predeterminado es el que se encuentra en ggc.archive.
+ `log-level`: nivel de registro de la ejecución de la prueba. El valor predeterminado es “INFO”.
+ `parallel-config`: conjunto de índices de lotes y número de lotes como cadena JSON. El valor predeterminado del índice de lotes es 0 y el número de lotes es 1.
+ `proxy-url`: configura todas las pruebas para enrutar el tráfico a través de esta URL.
+ `tags`: ejecuta únicamente etiquetas de características. Se puede intersecar con “&”
+ `test-id-prefix`: un prefijo común que se aplica a todos los recursos específicos de la prueba, incluidos los nombres y las etiquetas de los recursos de AWS. El prefijo predeterminado es “gg”.
+ `test-log-path`: directorio que contendrá los resultados de toda la ejecución de la prueba. El valor predeterminado es “testResults”.
+ `test-results-json`: marcador para determinar si se genera un informe JSON de Cucumber resultante escrito en el disco. El valor predeterminado es true (verdadero).
+ `test-results-log`: marcador para determinar si la salida de la consola se genera escrita en el disco. El valor predeterminado es falso.
+ `test-results-xml`: marcador para determinar si se genera un informe XML de JUnit resultante escrito en el disco. El valor predeterminado es true (verdadero).
+ `test-temp-path`: directorio para generar artefactos de prueba locales. El valor predeterminado es un directorio temporal aleatorio con el prefijo gg-testing.
+ `timeout-multiplier`: multiplicador proporcionado para todos los tiempos de espera de las pruebas. El valor predeterminado es 1.0.
# Tutorial: Ejecute end-to-end pruebas con Greengrass Testing Framework y Greengrass Development Kit
AWS IoT Greengrass Testing Framework (GTF) y Greengrass Development Kit (GDK) ofrecen a los desarrolladores formas de ejecutar pruebas. end-to-end Puede completar este tutorial para inicializar un proyecto de GDK con un componente, inicializar un proyecto de GDK con un módulo de prueba y crear un caso de end-to-end prueba personalizado. Una vez que haya compilado su caso de prueba personalizado, podrá ejecutar la prueba.
En este tutorial, aprenderá a hacer lo siguiente:
1. Inicialice un proyecto de GDK con un componente.
1. Inicialice un proyecto de GDK con un módulo de prueba. end-to-end
1. Cree un caso de prueba personalizado.
1. Agregue una etiqueta al nuevo caso de prueba.
1. Compile el JAR de prueba.
1. Ejecute la prueba .
**Topics**
+ [Requisitos previos](#run-e2e-tests-tutorial-prerequisites)
+ [Paso 1: Inicializar un proyecto de GDK con un componente](#init-gdk-with-component)
+ [Paso 2: inicializar un proyecto de GDK con un módulo de prueba end-to-end](#init-gdk-with-e2e-test)
+ [Paso 3: Crear un caso de prueba personalizado](#run-e2e-tests-tutorial-instructions)
+ [Paso 4: Agregar una etiqueta al nuevo caso de prueba](#add-tag-to-test-case)
+ [Paso 5: Compilar el JAR de prueba](#build-test-jar)
+ [Paso 6: Ejecutar la prueba](#run-test-gtf)
+ [Ejemplo: crear un caso de prueba personalizado](#build-test-case-example)
## Requisitos previos
Necesitará lo siguiente para completar este tutorial:
+ GDK versión 1.3.0 o posterior
+ Java
+ Maven
+ Git
## Paso 1: Inicializar un proyecto de GDK con un componente
+ Inicialice una carpeta vacía con un proyecto de GDK. Para descargar el componente `HelloWorld` implementado en Python, ejecute el siguiente comando.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Este comando crea un directorio denominado `HelloWorld` en el directorio actual.
## Paso 2: inicializar un proyecto de GDK con un módulo de prueba end-to-end
+ GDK le permite descargar la plantilla del módulo de pruebas que consta de una característica y una implementación escalonada. Ejecute el siguiente comando para abrir el directorio `HelloWorld` e inicializar el proyecto GDK existente mediante un módulo de pruebas.
```
cd HelloWorld
gdk test-e2e init
```
Este comando crea un directorio denominado `gg-e2e-tests` dentro del directorio `HelloWorld`. Este directorio de pruebas es un proyecto de [Maven](https://maven.apache.org/) que depende del JAR independiente de pruebas de Greengrass.
## Paso 3: Crear un caso de prueba personalizado
La redacción de un caso de prueba personalizado consta, en líneas generales, de dos pasos: crear un archivo de características con un escenario de prueba e implementar las definiciones de los pasos. Para ver un ejemplo de cómo crear un caso de prueba personalizado, consulte [Ejemplo: crear un caso de prueba personalizado](#build-test-case-example). Siga los pasos que se describen a continuación para crear un caso de prueba personalizado:
1. Cree un archivo de características con un escenario de prueba
Por lo general, una característica describe una funcionalidad específica del software que se está probando. En Cucumber, cada característica se especifica como un archivo de características individual con un título, una descripción detallada y uno o más ejemplos de casos específicos denominados escenarios. Cada escenario consta de un título, una descripción detallada y una serie de pasos que definen las interacciones y los resultados esperados. Los escenarios se escriben en un formato estructurado con las palabras clave “dado”, “cuándo” y “entonces”.
1. Implementación de definiciones de pasos
Una definición de paso vincula el [paso de Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) en lenguaje sencillo con el código programático. Cuando Cucumber identifique un paso de Gherkin en un escenario, buscará una definición de paso coincidente para ejecutarlo.
## Paso 4: Agregar una etiqueta al nuevo caso de prueba
+ Puede asignar etiquetas a las características y escenarios para organizar el proceso de prueba. Puede usar etiquetas para categorizar los subconjuntos de escenarios y también seleccionar los enlaces de forma condicional para que se ejecuten. Las características y los escenarios pueden tener varias etiquetas separadas por un espacio.
En este ejemplo, estamos usando el componente `HelloWorld`.
En el archivo de características, agrega una nueva etiqueta con un nombre `@HelloWorld` junto a la etiqueta `@Sample`.
```
@Sample @HelloWorld
Scenario: As a developer, I can create a component and deploy it on my device
....
```
## Paso 5: Compilar el JAR de prueba
1. Compile el componente. Debe compilar el componente antes de crear el módulo de prueba.
```
gdk component build
```
1. Compile el módulo de prueba con el siguiente comando. Este comando compilará el JAR de prueba en la carpeta `greengrass-build`.
```
gdk test-e2e build
```
## Paso 6: Ejecutar la prueba
Cuando realiza una prueba de confianza, el GTF automatiza el ciclo de vida de la prueba y administra los recursos que se crearon durante la prueba. Primero aprovisiona un dispositivo bajo prueba (DUT) como una AWS IoT cosa e instala el software principal de Greengrass en él. A continuación, creará un nuevo componente denominado `HelloWorld` con la receta especificada en esa ruta. A continuación, el componente `HelloWorld` se implementa en el dispositivo principal mediante una implementación de objeto de Greengrass. A continuación, se verificará si la implementación se realiza correctamente. El estado de la implementación cambiará a `COMPLETED` dentro de 3 minutos si la implementación se realiza correctamente.
1. Vaya al archivo `gdk-config.json` en el directorio del proyecto para apuntar a las pruebas con la etiqueta `HelloWorld`. Actualice la clave `test-e2e` mediante el siguiente comando.
```
"test-e2e":{
"gtf_options" : {
"tags":"HelloWorld"
}
}
```
1. Antes de ejecutar las pruebas, debe proporcionar AWS las credenciales al dispositivo anfitrión. El GTF usa estas credenciales para administrar los AWS recursos durante el proceso de prueba. Asegúrese de que el rol que proporcione tenga los permisos para automatizar las operaciones necesarias que se incluyen en la prueba.
Ejecute los siguientes comandos para proporcionar las AWS credenciales.
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. Ejecute la prueba con el siguiente comando.
```
gdk test-e2e run
```
Este comando descarga la última versión del núcleo de Greengrass de la carpeta `greengrass-build` y ejecuta pruebas con ella. Este comando también se dirige solo a los escenarios con la etiqueta `HelloWorld` y genera un informe para esos escenarios. Verá que los AWS recursos que se crearon durante esta prueba se descartan al final de la prueba.
## Ejemplo: crear un caso de prueba personalizado
**Example**
El módulo de pruebas descargado en el proyecto GDK consta de un archivo de características proporcionado.
En el siguiente ejemplo, utilizamos un archivo de características para probar la característica de implementación del objeto del software Greengrass. Probamos parcialmente la funcionalidad de esta característica con un escenario que realiza la implementación de un componente a través de la Nube de AWS de Greengrass. Se trata de una serie de pasos que nos ayudan a entender las interacciones y los resultados esperados de este caso de uso.
1.
**Creación de un archivo de características**
Navegue hasta la carpeta `gg-e2e-tests/src/main/resources/greengrass/features` del directorio actual. Puede encontrar el ejemplo `component.feature` con el aspecto del siguiente ejemplo.
En este archivo de características, puede probar la característica de implementación de objetos del software Greengrass. Puede probar parcialmente la funcionalidad de esta característica con un escenario que realice la implementación de un componente a través de la nube de Greengrass. El escenario consiste en una serie de pasos que ayudan a comprender las interacciones y los resultados esperados de cada caso de prueba.
```
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
```
El GTF contiene las definiciones de todos los pasos siguientes, excepto el paso denominado: `And I call my custom step`.
1.
**Implementación de definiciones de pasos**
El JAR independiente de GTF contiene las definiciones de todos los pasos excepto uno: `And I call my custom step`. Puede implementar este paso en el módulo de pruebas.
Navegue hasta el código de origen del archivo de prueba. Puede vincular su paso personalizado mediante una definición de paso utilizando el siguiente comando.
```
@And("I call my custom step")
public void customStep() {
System.out.println("My custom step was called ");
}
```
# Tutorial: Uso de una prueba de confianza del conjunto de pruebas de confianza
AWS IoT Greengrass Testing Framework (GTF) y Greengrass Development Kit (GDK) ofrecen a los desarrolladores formas de ejecutar pruebas. end-to-end Puede completar este tutorial para inicializar un proyecto de GDK con un componente, inicializar un proyecto de GDK con un módulo de prueba y utilizar una end-to-end prueba de confianza del conjunto de pruebas de confianza. Una vez que haya compilado su caso de prueba personalizado, podrá ejecutar la prueba.
Una prueba de confianza es una prueba genérica proporcionada por Greengrass que valida los comportamientos de los componentes fundamentales. Estas pruebas se pueden modificar o ampliar para adaptarlas a necesidades de componentes más específicas.
Para este tutorial utilizaremos un componente. HelloWorld Si está utilizando otro componente, sustituya el HelloWorld componente por el suyo.
En este tutorial, aprenderá a hacer lo siguiente:
1. Inicialice un proyecto de GDK con un componente.
1. Inicialice un proyecto de GDK con un módulo de end-to-end prueba.
1. Use una prueba del conjunto de pruebas de confianza.
1. Agregue una etiqueta al nuevo caso de prueba.
1. Compile el JAR de prueba.
1. Ejecute la prueba .
**Topics**
+ [Requisitos previos](#confidence-tests-tutorial-prerequisites)
+ [Paso 1: Inicializar un proyecto de GDK con un componente](#init-gdk-with-component)
+ [Paso 2: inicializar un proyecto de GDK con un módulo de prueba end-to-end](#init-gdk-with-e2e-test)
+ [Paso 3: Usar una prueba del conjunto de pruebas de confianza](#confidence-tests-tutorial-instructions)
+ [Paso 4: Agregar una etiqueta al nuevo caso de prueba](#add-tag-to-test-case)
+ [Paso 5: Compilar el JAR de prueba](#build-test-jar)
+ [Paso 6: Ejecutar la prueba](#run-test-gtf)
+ [Ejemplo: uso de una prueba de confianza](#build-confidence-test-case-example)
## Requisitos previos
Necesitará lo siguiente para completar este tutorial:
+ GDK versión 1.6.0 o posterior
+ Java
+ Maven
+ Git
## Paso 1: Inicializar un proyecto de GDK con un componente
+ Inicialice una carpeta vacía con un proyecto de GDK. Para descargar el componente `HelloWorld` implementado en Python, ejecute el siguiente comando.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Este comando crea un directorio denominado `HelloWorld` en el directorio actual.
## Paso 2: inicializar un proyecto de GDK con un módulo de prueba end-to-end
+ GDK le permite descargar la plantilla del módulo de pruebas que consta de una característica y una implementación escalonada. Ejecute el siguiente comando para abrir el directorio `HelloWorld` e inicializar el proyecto GDK existente mediante un módulo de pruebas.
```
cd HelloWorld
gdk test-e2e init
```
Este comando crea un directorio denominado `gg-e2e-tests` dentro del directorio `HelloWorld`. Este directorio de pruebas es un proyecto de [Maven](https://maven.apache.org/) que depende del JAR independiente de pruebas de Greengrass.
## Paso 3: Usar una prueba del conjunto de pruebas de confianza
La redacción de un caso de prueba de confianza consiste en usar el archivo de características proporcionado y, si es necesario, modificar los escenarios. Para ver un ejemplo de uso de una prueba de confianza, consulte [Ejemplo: crear un caso de prueba personalizado](run-e2e-tests-tutorial.md#build-test-case-example). Siga los pasos a continuación para usar una prueba de confianza:
+ Use el archivo de características proporcionado.
Navegue hasta la carpeta `gg-e2e-tests/src/main/resources/greengrass/features` del directorio actual. Abra el archivo de muestra `confidenceTest.feature` para usar la prueba de confianza.
## Paso 4: Agregar una etiqueta al nuevo caso de prueba
+ Puede asignar etiquetas a las características y escenarios para organizar el proceso de prueba. Puede usar etiquetas para categorizar los subconjuntos de escenarios y también seleccionar los enlaces de forma condicional para que se ejecuten. Las características y los escenarios pueden tener varias etiquetas separadas por un espacio.
En este ejemplo, estamos usando el componente `HelloWorld`.
Cada escenario está etiquetado con `@ConfidenceTest`. Cambie o agregue etiquetas si desea ejecutar solo un subconjunto del conjunto de pruebas. Cada escenario de prueba se describe en la parte superior de cada prueba de confianza. El escenario consiste en una serie de pasos que ayudan a comprender las interacciones y los resultados esperados de cada caso de prueba. Puede ampliar estas pruebas al agregar sus propios pasos o modificar los existentes.
```
@ConfidenceTest
Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected
....
```
## Paso 5: Compilar el JAR de prueba
1. Compile el componente. Debe compilar el componente antes de crear el módulo de prueba.
```
gdk component build
```
1. Compile el módulo de prueba con el siguiente comando. Este comando compilará el JAR de prueba en la carpeta `greengrass-build`.
```
gdk test-e2e build
```
## Paso 6: Ejecutar la prueba
Cuando realiza una prueba de confianza, el GTF automatiza el ciclo de vida de la prueba y administra los recursos que se crearon durante la prueba. Primero aprovisiona un dispositivo bajo prueba (DUT) como una AWS IoT cosa e instala el software principal de Greengrass en él. A continuación, creará un nuevo componente denominado `HelloWorld` con la receta especificada en esa ruta. A continuación, el componente `HelloWorld` se implementa en el dispositivo principal mediante una implementación de objeto de Greengrass. A continuación, se verificará si la implementación se realiza correctamente. El estado de la implementación cambiará a `COMPLETED` dentro de 3 minutos si la implementación se realiza correctamente.
1. Vaya al archivo `gdk-config.json` del directorio del proyecto para seleccionar las pruebas con la etiqueta `ConfidenceTest` o cualquier etiqueta que haya especificado en el Paso 4. Actualice la clave `test-e2e` mediante el siguiente comando.
```
"test-e2e":{
"gtf_options" : {
"tags":"ConfidenceTest"
}
}
```
1. Antes de ejecutar las pruebas, debe proporcionar AWS las credenciales al dispositivo anfitrión. El GTF usa estas credenciales para administrar los AWS recursos durante el proceso de prueba. Asegúrese de que el rol que proporcione tenga los permisos para automatizar las operaciones necesarias que se incluyen en la prueba.
Ejecute los siguientes comandos para proporcionar las AWS credenciales.
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. Ejecute la prueba con el siguiente comando.
```
gdk test-e2e run
```
Este comando descarga la última versión del núcleo de Greengrass de la carpeta `greengrass-build` y ejecuta pruebas con ella. Este comando también se dirige solo a los escenarios con la etiqueta `ConfidenceTest` y genera un informe para esos escenarios. Verá que los AWS recursos que se crearon durante esta prueba se descartan al final de la prueba.
## Ejemplo: uso de una prueba de confianza
**Example**
El módulo de pruebas descargado en el proyecto del GDK consta de un archivo de características proporcionado.
En el siguiente ejemplo, usamos un archivo de características para probar la característica de implementación del objeto del software Greengrass. Probamos parcialmente la funcionalidad de esta característica con un escenario que realiza la implementación de un componente a través de la Nube de AWS de Greengrass. Se trata de una serie de pasos que nos ayudan a entender las interacciones y los resultados esperados de este caso de uso.
+
**Use el archivo de características proporcionado.**
Navegue hasta la carpeta `gg-e2e-tests/src/main/resources/greengrass/features` del directorio actual. Puede encontrar el ejemplo `confidenceTest.feature` con el aspecto del siguiente ejemplo.
```
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
```
Cada escenario de prueba se describe en la parte superior de cada prueba de confianza. El escenario consiste en una serie de pasos que ayudan a comprender las interacciones y los resultados esperados de cada caso de prueba. Puede ampliar estas pruebas al agregar sus propios pasos o modificar los existentes. Cada uno de los escenarios incluye comentarios que lo ayudan a realizar estos ajustes.