As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# AWS IoT Greengrass ferramentas de desenvolvimento
Use ferramentas de AWS IoT Greengrass desenvolvimento para criar, testar, criar, publicar e implantar componentes personalizados do Greengrass.
+ **[CLI do kit de desenvolvimento do Greengrass](greengrass-development-kit-cli.md)**
[Use a interface de linha de comando do kit de AWS IoT Greengrass desenvolvimento (GDK CLI) em seu ambiente de desenvolvimento local para criar componentes a partir de modelos e componentes da comunidade no catálogo de software do Greengrass.](greengrass-software-catalog.md) Você pode usar a CLI do GDK para criar o componente e publicá-lo AWS IoT Greengrass no serviço como um componente privado no seu. Conta da AWS
+ **[Interface de linha de comando do Greengrass](gg-cli.md)**
Use a interface de linha de comando do Greengrass (CLI do Greengrass) nos dispositivos principais do Greengrass para implantar e depurar componentes do Greengrass. A CLI do Greengrass é um componente que você pode implantar em seus dispositivos principais para criar implantações locais, visualizar detalhes sobre os componentes instalados e explorar arquivos de log.
+ **[Console de depuração local](local-debug-console-component.md)**
Use o console de depuração local nos dispositivos principais do Greengrass para implantar e depurar componentes do Greengrass usando uma interface web de painel local. O console de depuração local é um componente que você pode implantar em seus dispositivos principais para criar implantações locais e visualizar detalhes sobre os componentes instalados.
AWS IoT Greengrass também fornece o seguinte SDKs que você pode usar em componentes personalizados do Greengrass:
+ O AWS IoT Device SDK e o AWS IoT Greengrass Component SDK, que contém a biblioteca de comunicação entre processos (IPC). Para obter mais informações, consulte [Use o AWS IoT Device SDK para se comunicar com o núcleo do Greengrass, outros componentes e AWS IoT CoreComunique-se com o núcleo do Greengrass, outros componentes e AWS IoT Core](interprocess-communication.md).
+ O Stream Manager SDK, que você pode usar para transferir fluxos de dados para a Nuvem AWS. Para obter mais informações, consulte [Gerenciar fluxos de dados no nos dispositivos principais do Greengrass](manage-data-streams.md).
**Topics**
+ [Interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass](greengrass-development-kit-cli.md)
+ [Interface de linha de comando do Greengrass](gg-cli.md)
+ [Use a estrutura AWS IoT Greengrass de teste](gg-testing-framework.md)
# Interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass
A interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass (CLI do GDK) fornece recursos que ajudam você a desenvolver [componentes personalizados do Greengrass.](develop-greengrass-components.md) É possível usar a CLI do GDK para criar, construir e publicar componentes personalizados. Ao criar um repositório de componentes com a CLI do GDK, você pode começar a partir de um modelo ou de um componente da comunidade do [Catálogo de Software do Greengrass](greengrass-software-catalog.md). Em seguida, você pode escolher um sistema de compilação que empacote arquivos em ZIP, use um script de compilação do Maven ou do Gradle ou execute um comando de compilação personalizado. Depois de criar um componente, você pode usar a CLI do GDK para publicá-lo no serviço do AWS IoT Greengrass. Assim, você pode usar o console ou a API do AWS IoT Greengrass para implantar o componente em seus dispositivos principais do Greengrass.
Ao desenvolver componentes do Greengrass sem a CLI do GDK, você deve atualizar os URIs da versão e do artefato no [arquivo de fórmula do componente](component-recipe-reference.md) sempre que criar uma nova versão dele. Quando você usa a CLI do GDK, ela pode atualizar automaticamente os URIs de versão e artefato sempre que você publica uma nova versão do componente.
A CLI do GDK é de código aberto e está disponível no GitHub. Você pode personalizar e estender a CLI do GDK para atender às suas necessidades de desenvolvimento de componentes. Convidamos você a criar questões e pull requests no repositório do GitHub. Você pode encontrar a fonte da CLI do GDK no seguinte link: [https://github.com/aws-greengrass/aws-greengrass-gdk-cli.](https://github.com/aws-greengrass/aws-greengrass-gdk-cli)
## Pré-requisitos
Para instalar e usar a CLI do kit de desenvolvimento do Greengrass, você precisa do seguinte:
+ Um Conta da AWS. Se você não tiver uma, consulte [Configurar um Conta da AWS](setting-up.md#set-up-aws-account).
+ Um computador de desenvolvimento semelhante ao Windows, macOS ou Unix com conexão à Internet.
+ Para a CLI do GDK versão 1.1.0 ou posterior, o [Python](https://www.python.org/downloads/) 3.6 ou posterior, instalado no computador de desenvolvimento.
Para a CLI do GDK versão 1.0.0, o [Python](https://www.python.org/downloads/) 3.8 ou posterior, instalado no computador de desenvolvimento.
+ O [Git](https://git-scm.com/) instalado no seu computador de desenvolvimento.
+ A AWS Command Line Interface(AWS CLI) instalada e configurada com credenciais no computador de desenvolvimento. Para mais informações, consulte [Instalar, atualizar e desinstalar a AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Configuração da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) no *Guia do usuário da AWS Command Line Interface*.
**nota**
Se você usa um Raspberry Pi ou outro dispositivo ARM de 32 bits, instale a AWS CLI V1. AWS CLI A V2 não está disponível para dispositivos ARM de 32 bits. Para obter mais informações, consulte [Instalar, atualizar e desinstalar a AWS CLI versão 1](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html).
+ Para usar a CLI do GDK para publicar componentes no serviço do AWS IoT Greengrass, você precisa das seguintes permissões:
+ `s3:CreateBucket`
+ `s3:GetBucketLocation`
+ `s3:PutObject`
+ `greengrass:CreateComponentVersion`
+ `greengrass:ListComponentVersions`
+ Para usar a CLI do GDK para criar um componente cujos artefatos existem em um bucket do S3 e não no sistema de arquivos local, você precisa das seguintes permissões:
+ `s3:ListBucket`
Este atributo está disponível para a CLI do GDK v1.1.0 e posteriores.
## Changelog
A tabela a seguir descreve as alterações em cada versão da CLI do GDK. Para mais informações, consulte a [Página de lançamentos da CLI do GDK](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases) no GitHub.
| **Versão** | **Alterações** |
| --- | --- |
| 1.6.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.0.0 | Versão inicial. |
# Instale ou atualize a interface de linha de comando do kit de AWS IoT Greengrass desenvolvimento
A interface de linha de comando do kit de AWS IoT Greengrass desenvolvimento (GDK CLI) é construída em Python, então você pode `pip` usá-la para instalá-la em seu computador de desenvolvimento.
**dica**
[Você também pode instalar a CLI do GDK em ambientes virtuais Python, como venv.](https://docs.python.org/3/library/venv.html#module-venv) Para obter mais informações, consulte [Ambientes e pacotes virtuais](https://docs.python.org/3/tutorial/venv.html) na documentação do *Python 3*.
**Para instalar ou atualizar a CLI do GDK:**
1. Execute o comando a seguir para instalar a versão mais recente da CLI do GDK no seu [repositório no 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 uma versão específica da CLI do GDK, substitua *versionTag* pela tag de versão a ser instalada. Você pode ver as tags de versão da CLI do GDK em seu [repositório do 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. Execute o comando a seguir para verificar se a instalação da CLI do GDK foi bem-sucedida.
```
gdk --help
```
Se o comando `gdk` não for encontrado, adicione sua pasta ao PATH.
+ Em dispositivos Linux, adicione `/home/MyUser/.local/bin` ao PATH e substitua *MyUser* pelo nome do seu usuário.
+ Em dispositivos Windows, adicione `PythonPath\\Scripts` ao PATH e substitua *PythonPath* pelo caminho para a pasta Python no seu dispositivo.
Agora é possível usar a CLI do GDK para criar, construir e publicar componentes do Greengrass. Para obter mais informações sobre como usar a CLI do GDK, consulte [Comandos da interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass](greengrass-development-kit-cli-commands.md).
# Comandos da interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass
A interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass (CLI do GDK) fornece uma interface de linha de comando que você pode usar para criar e publicar componentes do Greengrass em seu computador de desenvolvimento. Os comandos da CLI do GDK usam o formato a seguir.
```
gdk [arguments]
```
Quando você [instala a CLI do GDK](install-greengrass-development-kit-cli.md), o instalador adiciona `gdk` ao PATH para que você possa executar a CLI do GDK na linha de comando.
É possível usar os argumentos a seguir com qualquer comando:
+ Use `-h` ou `--help` para ter informações sobre um comando da CLI do GDK.
+ Use `-v` ou `--version` para ver qual versão da CLI do GDK está instalada.
+ Use `-d` ou `--debug` para gerar logs detalhados que você pode usar para depurar a CLI do GDK.
Esta seção descreve os comandos da CLI do GDK e fornece exemplos para cada comando. A sinopse de cada comando mostra argumentos dela e o uso. Os argumentos opcionais são mostrados dentro de colchetes.
**Topics**
+ [componente](greengrass-development-kit-cli-component.md)
+ [config](greengrass-development-kit-cli-config.md)
+ [teste-e2e](greengrass-development-kit-cli-test.md)
# componente
Use o comando `component` na interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass (GDK CLI) para criar e publicar componentes personalizados do Greengrass.
**Topics**
+ [init](#greengrass-development-kit-cli-component-init)
+ [build](#greengrass-development-kit-cli-component-build)
+ [publicar](#greengrass-development-kit-cli-component-publish)
+ [list](#greengrass-development-kit-cli-component-list)
## init
Inicialize uma pasta de componentes do Greengrass a partir de um modelo de componente ou componente da comunidade.
A CLI do GDK recupera componentes da comunidade do [Catálogo de Software do Greengrass](greengrass-software-catalog.md) e modelos de componentes do [repositório de modelos de componentes do AWS IoT Greengrass no GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates).
**nota**
Se você usa a CLI do GDK v1.0.0, deve executar esse comando em uma pasta vazia. A CLI do GDK baixa o modelo ou componente da comunidade para a pasta atual.
Se você usa a CLI do GDK v1.1.0 ou posterior, pode especificar o argumento `--name` para especificar a pasta em que a CLI do GDK baixa o modelo ou o componente da comunidade. Se você usar esse argumento, especifique uma pasta que não existe. A CLI do GDK cria a pasta para você. Se você não especificar esse argumento, a CLI do GDK usa a pasta atual, que deve estar vazia.
Se o componente usa o [sistema de compilação zip](gdk-cli-configuration-file.md#gdk-cli-configuration-file-build-system), a CLI do GDK compacta determinados arquivos na pasta do componente em um arquivo zip com o mesmo nome da pasta do componente. Por exemplo, se o nome da pasta do componente for `HelloWorld`, a CLI do GDK cria um arquivo zip chamado `HelloWorld.zip`. Na fórmula do componente, o nome do artefato zip deve corresponder ao nome da pasta do componente. Se você usa a CLI do GDK versão 1.0.0 em um dispositivo Windows, a pasta do componente e os nomes dos arquivos zip devem conter somente letras minúsculas.
Se você inicializar um modelo ou componente da comunidade que usa o sistema de compilação zip em uma pasta com um nome diferente do modelo ou componente, deverá alterar o nome do artefato zip na fórmula do componente. Atualize as definições `Artifacts` e `Lifecycle` de modo que o nome do arquivo zip corresponda ao nome da pasta do componente. O exemplo a seguir destaca o nome do arquivo zip nas definições `Artifacts` e `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}"
```
**Resumo**
```
$ gdk component init
[--language]
[--template]
[--repository]
[--name]
```
**Argumentos (inicializar a partir do modelo do componente)**
+ `-l`, `--language`: a linguagem de programação a ser usada para o modelo que você especificar.
Especifique `--repository` ou `--language` e `--template`.
+ `-t`, `--template`: o modelo de componente a ser usado em um projeto de componente local. Para visualizar os modelos disponíveis, use o comando [list](#greengrass-development-kit-cli-component-list).
Especifique `--repository` ou `--language` e `--template`.
+ `-n`, `--name`: (opcional) o nome da pasta local em que a CLI do GDK inicializa o componente. Especifique uma pasta que não existe. A CLI do GDK cria a pasta para você.
Este atributo está disponível para a CLI do GDK v1.1.0 e posteriores.
**Argumentos (inicializar a partir do componente da comunidade)**
+ `-r`, `--repository`: o componente da comunidade a ser verificado na pasta local. Para visualizar os componentes disponíveis da comunidade, use o comando [list](#greengrass-development-kit-cli-component-list).
Especifique `--repository` ou `--language` e `--template`.
+ `-n`, `--name`: (opcional) o nome da pasta local em que a CLI do GDK inicializa o componente. Especifique uma pasta que não existe. A CLI do GDK cria a pasta para você.
Este atributo está disponível para a CLI do GDK v1.1.0 e posteriores.
**Saída**
O exemplo a seguir mostra a saída produzida quando você executa esse comando para inicializar uma pasta de componentes a partir do modelo Hello World do 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.
```
O exemplo a seguir mostra a saída produzida quando você executa este comando para inicializar uma pasta de componente de um componente da comunidade.
```
$ 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
Crie a fonte de um componente em uma fórmula e artefatos que você possa publicar no serviço do AWS IoT Greengrass. A CLI do GDK executa o sistema de compilação que você especifica no arquivo de configuração da [CLI do GDK](gdk-cli-configuration-file.md), `gdk-config.json`. Você deve executar esse comando na mesma pasta em que o arquivo `gdk-config.json` existe.
Quando você executa esse comando, a CLI do GDK cria uma fórmula e artefatos na pasta `greengrass-build` do componente. A CLI do GDK salva a fórmula na pasta `greengrass-build/recipes` e salva os artefatos na pasta `greengrass-build/artifacts/componentName/componentVersion`.
Se você usa a CLI do GDK v1.1.0 ou posterior, a fórmula do componente pode especificar artefatos que existem em um bucket do S3, mas não na pasta de criação do componente local. Você pode usar esse atributo para reduzir o uso de largura de banda ao desenvolver componentes com grandes artefatos, como modelos de machine learning.
Depois de criar um componente, você pode fazer o seguinte para testá-lo em um dispositivo principal do Greengrass:
+ Se você desenvolve em um dispositivo diferente daquele em que executa o software AWS IoT Greengrass Core, você deve publicar o componente para implantá-lo em um dispositivo principal do Greengrass. Publique o componente no serviço do AWS IoT Greengrass e implante-o no dispositivo principal do Greengrass. Para obter mais informações, veja o comando [publish](#greengrass-development-kit-cli-component-build) e [Criar implantações](create-deployments.md).
+ Se você desenvolve no mesmo dispositivo em que executa o software AWS IoT Greengrass Core, pode publicar o componente no serviço do AWS IoT Greengrass para implantação ou criar uma implantação local para instalar e executar o componente. Para criar uma implantação local, use a CLI do Greengrass. Para obter mais informações, consulte [Interface de linha de comando do Greengrass](gg-cli.md) e [Testar os componentes do AWS IoT Greengrass com implantações locais](test-components.md). Ao criar a implantação local, especifique `greengrass-build/recipes` como pasta de fórmulas e `greengrass-build/artifacts` como pasta de artefatos.
**Resumo**
```
$ gdk component build
```
**Argumentos**
Nenhum
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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'.
```
## publicar
Publique esse componente no serviço do AWS IoT Greengrass. Esse comando carrega artefatos de construção em um bucket do S3, atualiza o URI do artefato na fórmula e cria uma nova versão do componente a partir dela. A CLI do GDK usa o bucket do S3 e a região da AWS que você especifica no [arquivo de configuração da CLI do GDK](gdk-cli-configuration-file.md), `gdk-config.json`. Você deve executar esse comando na mesma pasta em que o arquivo `gdk-config.json` existe.
Se você usar a CLI do GDK v1.1.0 ou posterior, poderá especificar o argumento `--bucket` para especificar o bucket do S3 em que a CLI do GDK carrega os artefatos do componente. Se você não especificar esse argumento, a CLI do GDK será carregada no bucket do S3 cujo nome é `bucket-region-accountId`, em que *bucket* e *região* são os valores que você especifica em `gdk-config.json`, e *accountId* é seu ID da Conta da AWS. A CLI do GDK criará o bucket, se ele não existir.
Se você usa a CLI do GDK v1.2.0 ou posterior, você pode substituir a Região da AWS especificada no arquivo de configuração da CLI do GDK usando o parâmetro `--region`. É possível especificar opções adicionais usando o parâmetro `--options`. Para uma lista de opções disponíveis, consulte [Arquivo de configuração da CLI do kit de desenvolvimento do Greengrass](gdk-cli-configuration-file.md).
Quando você executa esse comando, a CLI do GDK publica o componente com a versão especificada na fórmula. Se você especificar `NEXT_PATCH`, a CLI do GDK usará a próxima versão do patch que ainda não existe. As versões semânticas usam um sistema de numeração *principal*.*secundário*.*patch*. Para mais informações, consulte a [especificação de versão semântica](https://semver.org/).
**nota**
Se você usa a CLI do GDK v1.1.0 ou posterior, ao executar esse comando, ela verifica se o componente foi criado. Se o componente não for criado, a CLI do GDK [cria o componente](#greengrass-development-kit-cli-component-build) antes de publicá-lo.
**Resumo**
```
$ gdk component publish
[--bucket] [--region] [--options]
```
**Argumentos**
+ `-b`, `--bucket`: (opcional) especifique o nome do bucket do S3 em que a CLI do GDK publica artefatos do componente.
Se você não especificar esse argumento, a CLI do GDK será carregada no bucket do S3 cujo nome é `bucket-region-accountId`, em que *bucket* e *região* são os valores que você especifica em `gdk-config.json`, e *accountId* é seu ID da Conta da AWS. A CLI do GDK criará o bucket, se ele não existir.
A CLI do GDK criará o bucket, se ele não existir.
Este atributo está disponível para a CLI do GDK v1.1.0 e posteriores.
+ `-r`, `--region`: (opcional) especifique o nome da Região da AWS para quando o componente for criado. Esse argumento substitui o nome da região na configuração da CLI do GDK.
Este atributo está disponível para a CLI do GDK v1.2.0 e posteriores.
+ `-o`, `--options`: (opcional) especifique uma lista de opções para publicar um componente. O argumento deve ser uma string JSON válida ou um caminho de arquivo para um arquivo JSON contendo as opções de publicação. Este argumento substitui as opções na configuração da CLI do GDK.
Este atributo está disponível para a CLI do GDK v1.2.0 e posteriores.
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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 a lista de modelos de componentes e componentes da comunidade disponíveis.
A CLI do GDK recupera componentes da comunidade do [Catálogo de Software do Greengrass](greengrass-software-catalog.md) e modelos de componentes do [repositório de modelos de componentes do AWS IoT Greengrass no GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates).
Você pode passar a saída desse comando para o comando [init](#greengrass-development-kit-cli-component-init) para inicializar repositórios de componentes a partir de modelos e componentes da comunidade.
**Resumo**
```
$ gdk component list
[--template]
[--repository]
```
**Argumentos**
+ `-t`, `--template`: (opcional) especifique esse argumento para listar os modelos de componentes disponíveis. Esse comando gera o nome e a linguagem de cada modelo no formato `name-language`. Por exemplo, em `HelloWorld-python`, o nome do modelo é `HelloWorld` e a linguagem é `python`.
+ `-r`, `--repository`: (opcional) especifique esse argumento para listar os repositórios de componentes da comunidade disponíveis.
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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
Use o comando `config` na interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass (CLI do GDK) para modificar a configuração do GDK no arquivo de configuração, `gdk-config.json`.
**Topics**
+ [atualizar](#greengrass-development-kit-cli-config-update)
## atualizar
Inicie um prompt interativo para modificar campos em um arquivo de configuração existente do GDK.
**Resumo**
```
$ gdk config update
[--component]
```
**Argumentos**
+ `-c`, `--component`: para atualizar os campos relacionados ao componente no arquivo `gdk-config.json`. Esse argumento é obrigatório, pois é a única opção.
**Saída**
O exemplo a seguir mostra a saída produzida quando você executa esse comando para configurar um 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...
```
# teste-e2e
Use o comando `test-e2e` na interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass (CLI do CLI) para inicializar, criar e executar módulos de teste de ponta a ponta no projeto do GDK.
**Topics**
+ [init](#greengrass-development-kit-cli-test-init)
+ [build](#greengrass-development-kit-cli-test-build)
+ [executar](#greengrass-development-kit-cli-test-run)
## init
Inicialize um projeto existente da CLI do GDK com um módulo de teste que usa a Estrutura de testes do Greengrass (GTF).
Por padrão, a CLI do GDK recupera o modelo do módulo maven do [repositório de modelos de componentes do AWS IoT Greengrass no GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates). Esse módulo maven vem com uma dependência do arquivo JAR `aws-greengrass-testing-standalone`.
Esse comando cria um novo diretório chamado `gg-e2e-tests` dentro do projeto do GDK. Se o diretório do módulo de teste já existir e não estiver vazio, o comando será encerrado sem fazer nada. Essa pasta `gg-e2e-tests` contém o atributo Cucumber e as definições de etapas estruturadas em um projeto maven.
Por padrão, esse comando tentará usar a versão mais recente do GTF.
**Resumo**
```
$ gdk test-e2e init
[--gtf-version]
```
**Argumentos**
+ `-ov`, `--gtf-version`: (opcional) a versão do GTF a ser usada com o módulo de teste de ponta a ponta no projeto do GDK. Esse valor deve ser uma das versões do GTF dos [lançamentos](https://github.com/aws-greengrass/aws-greengrass-testing/releases). Este argumento substitui `gtf_version` na configuração da CLI do GDK.
**Saída**
O exemplo a seguir mostra a saída produzida quando você executa esse comando para inicializar o projeto do GDK com o módulo de teste.
```
$ 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**
Você deve criar o componente executando **gdk component build** antes de criar o módulo de teste de ponta a ponta.
Crie o módulo de testes completo. A CLI do GDK cria o módulo de teste usando o sistema de compilação que você especifica no [arquivo de configuração da CLI do GDK](gdk-cli-configuration-file.md), `gdk-config.json`, na propriedade `test-e2e`. Você deve executar esse comando na mesma pasta em que o arquivo `gdk-config.json` existe.
Por padrão, a CLI do GDK usa o sistema de compilação maven para criar o módulo de teste. O [Maven](https://maven.apache.org/) é necessário para executar o comando `gdk test-e2e build`.
Você deve criar o componente executando **gdk-component-build** antes de criar o módulo de teste, caso os arquivos de atributos de teste tiverem variáveis como `GDK_COMPONENT_NAME` e `GDK_COMPONENT_RECIPE_FILE` para interpolar.
Quando você executa esse comando, a CLI do GDK interpola todas as variáveis da configuração do projeto do GDK e cria o módulo `gg-e2e-tests` para gerar o arquivo JAR de teste final.
**Resumo**
```
$ gdk test-e2e build
```
**Argumentos**
Nenhum
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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'
.........
```
## executar
Execute o módulo de teste com as opções de teste no arquivo de configuração do GDK.
**nota**
Você deve criar o módulo de teste executando **gdk test-e2e build** antes de executar os testes de ponta a ponta
**Resumo**
```
$ gdk test-e2e run
[--gtf-options]
```
**Argumentos**
+ `-oo`, `--gtf-options`: (opcional) especifique uma lista de opções para executar os testes de ponta a ponta. O argumento deve ser uma string JSON válida ou um caminho de arquivo para um arquivo JSON contendo as opções do GTF. As opções fornecidas no arquivo de configuração são mescladas com as fornecidas nos argumentos do comando. Se uma opção estiver presente em ambos os lugares, a do argumento terá precedência sobre a do arquivo de configuração.
Se a opção `tags` não for especificada nesse comando, o GDK usará `Sample` para tags. Se `ggc-archive` não for especificado, o GDK baixa a versão mais recente do arquivo do núcleo do Greengrass.
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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
.......
```
# Arquivo de configuração da CLI do kit de desenvolvimento do Greengrass
A interface de linha de comando do kit de desenvolvimento do AWS IoT Greengrass(CLI do GDK) lê um arquivo de configuração chamado `gdk-config.json` para criar e publicar componentes. Esse arquivo de configuração precisa estar na raiz do repositório de componentes. Você pode usar o [comando init](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-init) da CLI do GDK para inicializar repositórios de componentes com esse arquivo de configuração.
**Topics**
+ [Formato do arquivo de configuração da CLI do GDK](#gdk-config-format)
+ [Exemplos de arquivos de configuração da CLI do GDK](#gdk-config-examples)
## Formato do arquivo de configuração da CLI do GDK
Ao definir um arquivo de configuração da CLI do GDK para um componente, você especifica as seguintes informações no formato JSON.
`gdk_version`
A versão mínima da CLI do GDK compatível com esse componente. Esse valor deve ser uma das versões da CLI do GDK dos [lançamentos](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases).
`component`
A configuração desse componente.
`componentName`
`author`
O autor ou publicador do componente.
`version`
A versão do componente. Especifique um dos seguintes:
+ `NEXT_PATCH`: quando você escolhe essa opção, a CLI do GDK define a versão quando você publica o componente. A CLI do GDK consulta o serviço do AWS IoT Greengrass para identificar a versão mais recente publicada do componente. Em seguida, ela define a versão para a próxima versão de patch após essa versão. Se você não publicou o componente antes, a CLI do GDK usa a versão `1.0.0`.
Se você escolher essa opção, não poderá usar a [CLI do Greengrass](greengrass-cli-component.md) para implantar e testar localmente o componente em seu computador de desenvolvimento local que executa o software AWS IoT Greengrass Core. Para habilitar implantações locais, você deve especificar uma versão semântica em vez disso.
+ Uma versão semântica, como **1.0.0**. As versões semânticas usam um sistema de numeração *principal*.*secundário*.*patch*. Para mais informações, consulte a [especificação de versão semântica](https://semver.org/).
Se você desenvolver componentes em um dispositivo principal do Greengrass para implantar e testar o componente, escolha essa opção. Você deve criar o componente com uma versão específica para criar implantações locais com a [CLI do Greengrass](greengrass-cli-component.md).
`build`
A configuração a ser usada para criar a fonte desse componente em artefatos. Esse objeto contém as informações a seguir:
`build_system`
O sistema de compilação a ser usado. Escolha uma das seguintes opções:
+ `zip`: empacota a pasta do componente em um arquivo ZIP para definir como o único artefato do componente. Escolha essa opção para os seguintes tipos de componentes:
+ Componentes que usam linguagens de programação interpretadas, como Python ou JavaScript.
+ Componentes que empacotam arquivos que não sejam código, como modelos de machine learning ou outros recursos.
A CLI do GDK compacta a pasta do componente em um arquivo zip com o mesmo nome da pasta do componente. Por exemplo, se o nome da pasta do componente for `HelloWorld`, a CLI do GDK cria um arquivo zip chamado `HelloWorld.zip`.
**nota**
Se você usa a CLI do GDK versão 1.0.0 em um dispositivo Windows, a pasta do componente e os nomes dos arquivos zip devem conter somente letras minúsculas.
Quando a CLI do GDK compacta a pasta do componente em um arquivo zip, ela ignora os seguintes arquivos:
+ O arquivo `gdk-config.json`
+ O arquivo da fórmula (`recipe.json` ou `recipe.yaml`)
+ Crie pastas, como `greengrass-build`
+ `maven`: executa o comando `mvn clean package` para transformar a fonte do componente em artefatos. Escolha essa opção para componentes que usam o [Maven](https://maven.apache.org/), como componentes Java.
Em dispositivos Windows, esse recurso está disponível para a CLI do GDK v1.1.0 e versões posteriores.
+ `gradle`: executa o comando `gradle build` para transformar a fonte do componente em artefatos. Escolha essa opção para componentes que usam o [Gradle.](https://gradle.org/) Este atributo está disponível para a CLI do GDK v1.1.0 e posteriores.
O sistema de compilação do `gradle` é compatível com o Kotlin DSL como arquivo de compilação. Este atributo está disponível para a CLI do GDK v1.2.0 e posteriores.
+ `gradlew`: executa o comando `gradlew` para transformar a fonte do componente em artefatos. Escolha essa opção para componentes que usam o [Wrapper Gradle](https://docs.gradle.org/current/userguide/gradle_wrapper.html).
Este atributo está disponível para a CLI do GDK v1.2.0 e posteriores.
+ `custom`: executa um comando personalizado para transformar a fonte do componente em uma fórmula e artefatos. Especifique o comando personalizado no parâmetro `custom_build_command`.
`custom_build_command`
(Opcional) O comando de compilação personalizado a ser executado em um sistema de compilação personalizado. Você deve especificar este parâmetro se especificar `custom` para `build_system`.
Esse comando deve criar uma fórmula e artefatos nas seguintes pastas dentro da pasta do componente. A CLI do GDK cria essas pastas para você quando você executa o [comando de compilação do componente](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build).
+ Pasta de fórmula: `greengrass-build/recipes`
+ Pasta de artefatos: `greengrass-build/artifacts/componentName/componentVersion`
Substitua *componentName* pelo nome do componente e substitua *componentVersion* pela versão do componente ou `NEXT_PATCH`.
Você pode especificar uma única string ou uma lista de strings, em que cada string é uma palavra no comando. Por exemplo, para executar um comando de compilação personalizado para um componente C\$1\$1, especifique **cmake --build build --config Release** ou **["cmake", "--build", "build", "--config", "Release"]**.
Para ver um exemplo de um sistema de compilação personalizado, consulte [aws.greengrass.labs.LocalWebServer community component no GitHub](https://github.com/awslabs/aws-greengrass-labs-local-web-server).
`options`
(Opcional) Opções de configuração adicionais usadas durante o processo de compilação do componente.
Este atributo está disponível para a CLI do GDK v1.2.0 e posteriores.
`excludes`
Uma lista de padrões globais que definem quais arquivos excluir do diretório de componentes ao criar o arquivo zip. Válido somente quando a `build_system` é `zip`.
Nas versões 1.4.0 e anteriores da CLI do GDK, qualquer arquivo que corresponda a uma entrada na lista de exclusões é excluído de todos os subdiretórios do componente. Para ter o mesmo comportamento nas versões 1.5.0 e posteriores da CLI do GDK, acrescente as entradas `**/` existentes na lista de exclusões. Por exemplo, `*.txt` excluirá arquivos de texto apenas do diretório e `**/*.txt` excluirá arquivos de texto de todos os diretórios e subdiretórios.
Nas versões 1.5.0 e posteriores da CLI do GDK, você pode ver um aviso durante a compilação do componente quando `excludes` é definido no arquivo de configuração do GDK. Para desativar esse aviso, defina a variável de ambiente `GDK_EXCLUDES_WARN_IGNORE` como`true`.
A CLI do GDK sempre exclui os seguintes arquivos do arquivo zip:
+ O arquivo `gdk-config.json`
+ O arquivo da fórmula (`recipe.json` ou `recipe.yaml`)
+ Crie pastas, como `greengrass-build`
Os arquivos a seguir são excluídos por padrão. No entanto, você pode controlar quais desses arquivos são excluídos com a opção `excludes`.
+ Qualquer pasta que comece com o prefixo “test” (`test*`)
+ Todos os arquivos ocultos
+ A pasta `node_modules`.
Se você especificar a opção `excludes`, a CLI do GDK excluirá somente os arquivos definidos com a opção `excludes`. Se você não especificar a opção `excludes`, a CLI do GDK excluirá os arquivos e pastas padrão mencionados anteriormente.
`zip_name`
O nome do arquivo zip a ser usado ao criar um artefato zip durante o processo de compilação. Válido somente quando a `build_system` é `zip`. Se `build_system` estiver vazio, o nome do componente será usado para o nome do arquivo zip.
`publish`
A configuração a ser usada para publicar esse componente no serviço do AWS IoT Greengrass.
Se você usar o GDK CLI v1.1.0 ou posterior, poderá especificar o argumento `--bucket` para especificar o bucket do S3 em que o GDK CLI carrega os artefatos do componente. Se você não especificar esse argumento, a CLI do GDK será carregada no bucket do S3 cujo nome é `bucket-region-accountId`, em que *bucket* e *região* são os valores que você especifica em `gdk-config.json`, e *accountId* é seu ID da Conta da AWS. A CLI do GDK criará o bucket, se ele não existir.
Esse objeto contém as informações a seguir:
`bucket`
O nome do bucket do S3 a ser usado para hospedar artefatos de componentes.
`region`
A Região da AWS em que a CLI do GDK publica este componente.
Essa propriedade é opcional se você estiver usando a CLI do GDK v1.3.0 ou posterior.
`options`
(Opcional) Opções de configuração adicionais usadas durante o processo de compilação do componente.
Este atributo está disponível para a CLI do GDK v1.2.0 e posteriores.
`file_upload_args`
Uma estrutura JSON contendo argumentos enviados ao Amazon S3 durante o upload de arquivos para um bucket, como metadados e mecanismos de criptografia. Para ter uma lista dos argumentos permitidos, consulte a classe [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) na *documentação do Boto3*.
`test-e2e`
(Opcional) A configuração a ser usada durante o teste ponta a ponta do componente. Este atributo está disponível para a CLI do GDK v1.3.0 e posteriores.
`build`
`build_system`: o sistema de compilação a ser usado. A opção padrão é `maven`. Escolha uma das seguintes opções:
+ `maven`: executa o comando `mvn package` para criar o módulo de teste. Escolha essa opção para criar o módulo de teste que usa o [Maven](https://maven.apache.org/).
+ `gradle`: executa o comando `gradle build` para criar o módulo de teste. Escolha essa opção para o módulo de teste que usa o [Gradle](https://gradle.org/).
`gtf_version`
(Opcional) A versão da estrutura de testes do Greengrass (GTF) a ser usada como dependência do módulo de teste de ponta a ponta ao inicializar o projeto do GDK com GTF. Esse valor deve ser uma das versões do GTF dos [lançamentos](https://github.com/aws-greengrass/aws-greengrass-testing/releases). O padrão é GTF versão 1.1.0.
`gtf_options`
(Opcional) Opções de configuração adicionais usadas durante o teste de ponta a ponta do componente.
A lista a seguir inclui as opções que você pode usar com o GTF para a versão 1.1.0.
+ `additional-plugins`: (opcional) plug-ins adicionais do Cucumber
+ `aws-region`: tem como alvo endpoints regionais específicos para serviços da AWS. O padrão é o que o SDK da AWS descobre.
+ `credentials-path`: caminho opcional de credenciais do perfil da AWS. O padrão é credenciais descobertas no ambiente do host.
+ `credentials-path-rotation`: duração de rotação opcional para credenciais da AWS. O valor padrão é 15 minutos ou `PT15M`.
+ `csr-path`: o caminho para o CSR usando qual certificado do dispositivo será gerado.
+ `device-mode`: o dispositivo alvo em teste. O padrão é o dispositivo local.
+ `env-stage`: tem como alvo o ambiente de implantação do Greengrass. O padrão é produção.
+ `existing-device-cert-arn`: o arn de um certificado existente que você deseja usar como certificado de dispositivo para o Greengrass.
+ `feature-path`: arquivo ou diretório contendo arquivos de atributos adicionais. O padrão é não usar nenhum arquivo de atributo adicional.
+ `gg-cli-version`: substitui a versão da CLI do Greengrass. O padrão é o valor encontrado em `ggc.version`.
+ `gg-component-bucket`: o nome de um bucket existente do Amazon S3 que abriga os componentes do Greengrass.
+ `gg-component-overrides`: uma lista de substituições de componentes do Greengrass.
+ `gg-persist`: uma lista de elementos de teste a serem persistidos após a execução do teste. O comportamento padrão é não persistir em nada. Os valores aceitos são `aws.resources`, `installed.software` e `generated.files`.
+ `gg-runtime`: uma lista de valores para influenciar a forma como o teste interage com os recursos do teste. Esses valores substituem o parâmetro `gg.persist`. Se o padrão for vazio, ele presume que todos os recursos de teste são gerenciados pelo caso de teste, incluindo o runtime do Greengrass instalado. Os valores aceitos são `aws.resources`, `installed.software` e `generated.files`.
+ `ggc-archive`: o caminho para o componente do núcleo arquivado do Greengrass.
+ `ggc-install-root`: diretório para instalar o componente do núcleo do Greengrass. O padrão é test.temp.path e pasta de execução de teste.
+ `ggc-log-level`: defina o nível de log do núcleo do Greengrass para a execução do teste. O padrão é "INFO".
+ `ggc-tes-rolename`: o perfil do IAM que o AWS IoT Greengrass Core assumirá para acessar os serviços da AWS. Se um perfil com o nome fornecido não existir, será criada uma política de acesso padrão.
+ `ggc-trusted-plugins`: a lista separada por vírgula dos caminhos (no host) dos plug-ins confiáveis que precisam ser adicionados ao Greengrass. Para fornecer o caminho no próprio DUT, adicione o prefixo o caminho com 'dut':
+ `ggc-user-name`: o valor de user:group PosixUser para o núcleo do Greengrass. O padrão é o nome de usuário atual que está conectado.
+ `ggc-version`: substitui a versão do componente do núcleo do Greengrass em execução. O padrão é o valor encontrado em ggc.archive.
+ `log-level`: nível de log da execução do teste. O padrão é "INFO".
+ `parallel-config`: conjunto de índice de lote e número de lotes como uma string JSON. O valor padrão do índice do lote é 0 e o número de lotes é 1.
+ `proxy-url`: configure todos os testes para rotear o tráfego por meio desse URL.
+ `tags`: executa apenas tags de recursos. Pode ser cruzado com '&'
+ `test-id-prefix`: um prefixo comum aplicado a todos os recursos específicos do teste, incluindo nomes e tags de recursos da AWS. O padrão é um prefixo "gg".
+ `test-log-path`: diretório que conterá os resultados de toda a execução do teste. O padrão é "testResults".
+ `test-results-json`: sinalize para determinar se um relatório JSON do Cucumber resultante foi gerado e gravado no disco. O valor padrão é verdadeiro.
+ `test-results-log`: sinalize para determinar se a saída do console foi gerada e gravada no disco. O padrão é falso.
+ `test-results-xml`: sinalize para determinar se um relatório XML JUnit resultante é gerado e gravado em disco. O valor padrão é verdadeiro.
+ `test-temp-path`: diretório para gerar artefatos de teste locais. O padrão é um diretório temporário aleatório prefixado com gg-testing.
+ `timeout-multiplier`: multiplicador fornecido para todos os tempos limite de teste. O padrão é 1.0.
## Exemplos de arquivos de configuração da CLI do GDK
Você pode consultar os seguintes exemplos de arquivos de configuração da CLI do GDK para configurar ambientes de componentes do Greengrass.
### Hello World (Python)
O arquivo de configuração da CLI do GDK a seguir é compatível com um componente Hello World que executa um script Python. Esse arquivo de configuração usa o sistema de compilação `zip` para empacotar o script Python do componente em um arquivo ZIP que a CLI do GDK carrega como um artefato.
```
{
"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)
O arquivo de configuração da CLI do GDK a seguir é compatível com um componente Hello World que executa uma aplicação Java. Este arquivo de configuração usa o sistema de compilação `maven` para empacotar o código-fonte Java do componente em um arquivo JAR que a CLI do GDK carrega como um artefato.
```
{
"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 da comunidade
Vários componentes da comunidade no [Catálogo do Software do Greengrass](greengrass-software-catalog.md) usam a CLI do GDK. Você pode explorar os arquivos de configuração da CLI do GDK nos repositórios desses componentes.
**Para visualizar os arquivos de configuração da CLI do GDK dos componentes da comunidade**
1. Execute o seguinte comando para listar os componentes da comunidade que usam a CLI do GDK.
```
gdk component list --repository
```
A resposta lista o nome do repositório do GitHub para cada componente da comunidade que usa a CLI do GDK. Cada repositório existe na organização `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 o repositório GitHub de um componente da comunidade na seguinte URL. Substitua *community-component-name* pelo nome de um componente da comunidade da etapa anterior.
```
https://github.com/awslabs/community-component-name
```
# Interface de linha de comando do Greengrass
A interface de linha de comandos (CLI) do Greengrass permite que você interaja com o AWS IoT Greengrass Core em seu dispositivo para desenvolver componentes localmente e depurar problemas. Por exemplo, você pode usar a CLI do Greengrass para criar uma implantação local e reiniciar um componente no dispositivo principal.
Implante o [componente da CLI do Greengrass](greengrass-cli-component.md) (`aws.greengrass.Cli`) para instalar a CLI do Greengrass em seu dispositivo principal.
**Importante**
Recomendamos que você use este componente somente em ambientes de desenvolvimento, não em ambientes de produção. Este componente fornece acesso a informações e operações que você normalmente não precisará em um ambiente de produção. Siga o princípio do privilégio mínimo implantando este componente somente nos dispositivos principais em que você precisar dele.
**Topics**
+ [Instalar a Greengrass CLI](install-gg-cli.md)
+ [Comandos da CLI do Greengrass](gg-cli-reference.md)
# Instalar a Greengrass CLI
É possível instalar a CLI do Greengrass de uma das seguintes maneiras:
+ Use o `--deploy-dev-tools` argumento ao configurar o software AWS IoT Greengrass Core pela primeira vez em seu dispositivo. Você também deve especificar `--provision true` para aplicar esse argumento.
+ Implante o componente CLI do Greengrass (`aws.greengrass.Cli`) em seu dispositivo.
Esta seção descreve as etapas para implantar o componente Greengrass CLI. Para obter informações sobre como instalar a Greengrass CLI durante a configuração inicial, consulte [Tutorial: Conceitos básicos do AWS IoT Greengrass V2](getting-started.md).
## Pré-requisitos
Para implantar o componente Greengrass CLI, é necessário atender aos seguintes requisitos:
+ AWS IoT Greengrass Software principal instalado e configurado em seu dispositivo principal. Para obter mais informações, consulte [Tutorial: Conceitos básicos do AWS IoT Greengrass V2](getting-started.md).
+ Para usar o AWS CLI para implantar a CLI do Greengrass, você deve ter instalado e configurado o. AWS CLI Para obter mais informações, consulte [Configuração da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) no *Guia do usuário da AWS Command Line Interface *.
+ Você deve estar autorizado a usar a CLI do Greengrass para interagir com o software principal. AWS IoT Greengrass Siga um dos seguintes procedimentos para usar a Greengrass CLI:
+ Use o usuário do sistema que executa o software AWS IoT Greengrass Core.
+ Use um usuário com permissões de root ou administrativas. Nos dispositivos principais do Linux, você pode usar `sudo` para obter permissões de root.
+ Use um usuário do sistema que esteja em um grupo que você especifica nos parâmetros de `AuthorizedWindowsGroups` configuração `AuthorizedPosixGroups` ou ao implantar o componente. Para mais informações, consulte [Configuração do componente da CLI do Greengras](greengrass-cli-component.md#greengrass-cli-component-configuration).
## Implemente o componente CLI do Greengrass
Conclua as etapas a seguir para implantar o componente Greengrass CLI em seu dispositivo principal:
### Para implantar o componente Greengrass CLI (console)
1. Faça login no [console do AWS IoT Greengrass](https://console.aws.amazon.com/greengrass).
1. No menu de navegação, escolha **Componentes**.
1. Na página **Componentes**, na guia **Componentes públicos**, escolha `aws.greengrass.Cli`.
1. Na página **aws.greengrass.Cli**, escolha **Implantar**.
1. Em **Adicionar à implementação**, selecione **Criar nova implementação**.
1. **Na página **Especificar destino**, em **Alvos de implantação**, na lista **Nome do alvo**, escolha o grupo Greengrass no qual você deseja implantar e escolha Avançar.**
1. Na página **Selecionar componentes**, verifique se o componente **aws.greengrass.Cli** está selecionado e escolha **Avançar**.
1. Na página **Configurar componentes**, mantenha as configurações padrão e escolha **Avançar**.
1. Na página **Definir configurações avançadas**, mantenha as configurações padrão e escolha **Avançar**.
1. Na página **Revisar**, escolha **Implantar**.
### Para implantar o componente CLI do Greengrass ()AWS CLI
1. No seu dispositivo, crie um `deployment.json` arquivo para definir a configuração de implantação do componente Greengrass CLI. Esse arquivo deve ser semelhante ao seguinte:
```
{
"targetArn":"targetArn",
"components": {
"aws.greengrass.Cli": {
"componentVersion": "2.17.0",
"configurationUpdate": {
"merge": "{\"AuthorizedPosixGroups\":\",,...,\",\"AuthorizedWindowsGroups\":\",,...,\"}"
}
}
}
}
```
+ No campo `target`, substitua `targetArn` pelo nome do recurso da Amazon (ARN) da coisa ou do grupo de coisas do destino da implantação, no formato a seguir:
+ Coisa: `arn:aws:iot:region:account-id:thing/thingName`
+ Grupo de coisas: `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
+ No objeto `aws.greengrass.Cli` componente, especifique os valores da seguinte forma:
`version`
Essa é a versão do componente Greengrass CLI.
`configurationUpdate.AuthorizedPosixGroups`
(Opcional) Uma string que contém uma lista separada por vírgulas de grupos do sistema. Você autoriza esses grupos de sistema a usar a CLI do Greengrass para interagir com AWS IoT Greengrass o software principal. Você pode especificar nomes de grupos ou grupos IDs. Por exemplo, `group1,1002,group3` autoriza três grupos do sistema (`group1``1002`, e`group3`) a usar a CLI do Greengrass.
Se você não especificar nenhum grupo para autorizar, poderá usar a CLI do Greengrass como `sudo` usuário raiz () ou como usuário do sistema que AWS IoT Greengrass executa o software Core.
`configurationUpdate.AuthorizedWindowsGroups`
(Opcional) Uma string que contém uma lista separada por vírgulas de grupos do sistema. Você autoriza esses grupos de sistema a usar a CLI do Greengrass para interagir com AWS IoT Greengrass o software principal. Você pode especificar nomes de grupos ou grupos IDs. Por exemplo, `group1,1002,group3` autoriza três grupos do sistema (`group1``1002`, e`group3`) a usar a CLI do Greengrass.
Se você não especificar nenhum grupo para autorizar, poderá usar a CLI do Greengrass como administrador ou como usuário do sistema que AWS IoT Greengrass executa o software Core.
1. Execute o seguinte comando para implantar o componente da CLI do Greengrass no dispositivo:
```
$ aws greengrassv2 create-deployment --cli-input-json file://path/to/deployment.json
```
Durante a instalação, o componente adiciona um link simbólico à `greengrass-cli` `/greengrass/v2/bin` pasta do seu dispositivo e você executa a CLI do Greengrass a partir desse caminho. Para executar a CLI do Greengrass sem seu caminho absoluto, adicione sua `/greengrass/v2/bin` pasta à variável PATH. Para verificar a instalação da CLI do Greengrass, execute o seguinte comando:
------
#### [ Linux or Unix ]
```
/greengrass/v2/bin/greengrass-cli help
```
------
#### [ Windows ]
```
C:\greengrass\v2\bin\greengrass-cli help
```
------
A seguinte saída deverá ser mostrada:
```
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.
```
Se `greengrass-cli` não for encontrado, a implantação pode ter falhado ao instalar a CLI do Greengrass. Para obter mais informações, consulte [Solução de problemas AWS IoT Greengrass V2](troubleshooting.md).
# Comandos da CLI do Greengrass
A CLI do Greengrass fornece uma interface de linha de comando para interagir localmente com o dispositivo principal do AWS IoT Greengrass. Os comandos da CLI do Greengrass usam o formato a seguir.
```
$ greengrass-cli [arguments]
```
Por padrão, o arquivo `greengrass-cli` executável na pasta `/greengrass/v2/bin/` interage com a versão do software AWS IoT Greengrass Core em execução na pasta `/greengrass/v2`. Se você chamar um executável que não esteja colocado nesse local ou se quiser interagir com o software AWS IoT Greengrass Core em um local diferente, será preciso usar um dos métodos a seguir para especificar explicitamente o caminho raiz do software AWS IoT Greengrass Core com o qual você quer interagir:
+ Defina a variável de ambiente `GGC_ROOT_PATH` como `/greengrass/v2`.
+ Adicione o argumento `--ggcRootPath /greengrass/v2` ao comando, conforme mostrado no exemplo a seguir.
```
greengrass-cli --ggcRootPath /greengrass/v2 [arguments]
```
É possível usar os argumentos a seguir com qualquer comando:
+ Use `--help` para informações sobre um comando específico da CLI do Greengrass.
+ Use `--version` para informações sobre a versão da CLI do Greengrass.
Esta seção descreve os comandos da CLI do Greengrass e fornece exemplos deles. A sinopse de cada comando mostra os argumentos e o uso deles. Os argumentos opcionais são mostrados dentro de colchetes.
**Topics**
+ [componente](gg-cli-component.md)
+ [implantação](gg-cli-deployment.md)
+ [logs](gg-cli-logs.md)
+ [get-debug-password](gg-cli-get-debug-password.md)
# componente
Use o comando `component` para interagir com componentes locais em seu dispositivo principal.
**Subcomandos**
+ [detalhes](#component-details)
+ [list](#component-list)
+ [reiniciar](#component-restart)
+ [parar](#component-stop)
## detalhes
Recupere a versão, o status e a configuração de um componente.
**Resumo**
```
greengrass-cli component details --name
```
**Argumentos**
`--name`, `-n`. O nome do componente.
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse comando.
```
$ sudo greengrass-cli component details --name MyComponent
Component Name: MyComponent
Version: 1.0.0
State: RUNNING
Configuration: null
```
## list
Recupere o nome, a versão, o status e a configuração de cada componente instalado no dispositivo.
**Resumo**
```
greengrass-cli component list
```
**Argumentos**
Nenhum
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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 os componentes.
**Resumo**
```
greengrass-cli component restart --names ,...
```
**Argumentos**
`--names`, `-n`. O nome do componente. Pelo menos um nome de componente é necessário. Você pode especificar nomes de componentes adicionais, separando cada nome com uma vírgula.
**Saída**
Nenhum
## parar
Pare de executar componentes.
**Resumo**
```
greengrass-cli component stop --names ,...
```
**Argumentos**
`--names`, `-n`. O nome do componente. Pelo menos um nome de componente é necessário. Você pode especificar nomes de componentes adicionais, se necessário, separando cada nome com uma vírgula.
**Saída**
Nenhum
# implantação
Use o comando `deployment` para interagir com componentes locais em seu dispositivo principal.
Use o subcomando `status` para monitorar o progresso de uma implantação local. Você não pode monitorar o progresso de uma implantação local usando o console.
**Subcomandos**
+ [criar](#deployment-create)
+ [cancelar](#deployment-cancel)
+ [listar](#deployment-list)
+ [status](#deployment-status)
## criar
Crie ou atualize uma implantação local usando fórmulas de componentes, artefatos e argumentos de runtime especificados.
**Resumo**
```
greengrass-cli deployment create
--recipeDir path/to/component/recipe
[--artifactDir path/to/artifact/folder ]
[--update-config {component-configuration}]
[--groupId ]
[--merge "="]...
[--runWith ":posixUser=[:]"]...
[--systemLimits "{component-system-resource-limits}]"]...
[--remove ,...]
[--failure-handling-policy ]
```
**Arguments (Argumentos)**
+ `--recipeDir`, `-r`. O caminho completo para a pasta que contém os arquivos de fórmulas do componente.
+ `--artifactDir`, `-a`. O caminho completo para a pasta que contém os arquivos de artefatos que você deseja incluir na sua implantação. A pasta de artefatos deve conter a seguinte estrutura de diretórios:
```
/path/to/artifact/folder///
```
+ `--update-config`, `-c`. Os argumentos de configuração para a implantação, fornecidos como uma string JSON ou um arquivo JSON. A string JSON deve estar no seguinte formato:
```
{ \
"componentName": { \
"MERGE": {"config-key": "config-value"}, \
"RESET": ["path/to/reset/"] \
} \
}
```
`MERGE` e `RESET` diferenciam maiúsculas de minúsculas.
+ `--groupId`, `-g`. O grupo de objetos de destino para a implantação.
+ `--merge`, `-m`. O nome e a versão do componente de destino que você deseja adicionar ou atualizar. Você deve fornecer as informações do componente no formato `=`. Use um argumento separado para cada componente adicional para especificar. Se necessário, use o argumento `--runWith` para fornecer as informações `posixUser`, `posixGroup` e `windowsUser` para executar o componente.
+ `--runWith`. As informações `posixUser`, `posixGroup` e `windowsUser` para executar um componente genérico ou do Lambda. Você deve fornecer essas informações no formato `:{posixUser|windowsUser}=[:<=posixGroup>]`. Por exemplo, você deve especificar **HelloWorld:posixUser=ggc\$1user:ggc\$1group** ou **HelloWorld:windowsUser=ggc\$1user**. Use um argumento separado para cada opção adicional para especificar.
Para obter mais informações, consulte [Configurar o usuário que executa os componentes](configure-greengrass-core-v2.md#configure-component-user).
+ `--systemLimits`. Os limites de recursos do sistema a serem aplicados aos processos de componentes do Lambda genéricos e não conteinerizados no dispositivo principal. Você pode configurar a quantidade máxima de uso da CPU e RAM que os processos de um componente podem usar. Especifique um objeto JSON serializado ou um caminho de arquivo para um arquivo JSON. O objeto JSON deve ter o seguinte formato.
```
{ \
"componentName": { \
"cpus": cpuTimeLimit, \
"memory": memoryLimitInKb \
} \
}
```
Você pode configurar os seguintes limites de recursos do sistema para cada componente:
+ `cpus`: a quantidade máxima de tempo de CPU que os processos deste componente podem usar no dispositivo principal. O tempo total da CPU de um dispositivo essencial é equivalente ao número de núcleos da CPU do dispositivo. Por exemplo, em um dispositivo principal com quatro núcleos da CPU, é possível definir esse valor como `2` a fim de limitar os processos do componente para 50% de uso em cada núcleo da CPU. Em um dispositivo com um núcleo da CPU, você pode definir esse valor como `0.25` a fim de limitar os processos do componente para 25% de uso da CPU. Se você definir esse valor como um número maior que o número de núcleos de CPU, o software AWS IoT Greengrass Core não limitará o uso da CPU do componente.
+ `memory`: a quantidade máxima de RAM, expressa em kilobytes, que esse processo de componente pode usar no dispositivo principal.
Para obter mais informações, consulte [Configurar limites de recursos do sistema para componentes](configure-greengrass-core-v2.md#configure-component-system-resource-limits).
Esse recurso está disponível para a versão 2.4.0 e posterior do componente Greengrass [nucleus e da CLI do Greengrass](greengrass-nucleus-component.md) em dispositivos principais do Linux. AWS IoT Greengrass atualmente não oferece suporte a esse recurso nos dispositivos principais do Windows.
+ `--remove`. O nome do componente de destino que você deseja remover de uma implantação local. Se o componente definir uma etapa do [ciclo de vida de desinstalação](component-recipe-reference.md#uninstall-lifecycle-definition), o software AWS IoT Greengrass principal executará o script de desinstalação antes de remover o componente. Para remover um componente que foi mesclado de uma implantação na nuvem, você deve fornecer o ID do grupo de objetos de destino no seguinte formato:
------
#### [ Greengrass nucleus v2.4.0 and later ]
```
--remove --groupId
```
------
#### [ Earlier than v2.4.0 ]
```
--remove --groupId thinggroup/
```
------
+ `--failure-handling-policy`. Define a ação tomada quando uma implantação falha. Há duas ações que você pode especificar:
+ `ROLLBACK` –
+ `DO_NOTHING` –
Este atributo está disponível para a v2.11.0 e posterior do [Greengrass nucleus](greengrass-nucleus-component.md).
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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 a implantação especificada.
Resumo
```
greengrass-cli deployment cancel
-i
```
Argumentos
`-i`. O identificador exclusivo da implantação a ser cancelada. O ID de implantação é retornado na saída do comando `create`.
Output
+ Nenhum
## listar
Recuperar o status das últimas 10 implantações locais.
**Resumo**
```
greengrass-cli deployment list
```
**Arguments (Argumentos)**
Nenhum
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse comando. Dependendo do status da sua implantação, a saída mostra um dos seguintes valores de status: `IN_PROGRESS`, `SUCCEEDED` ou `FAILED`.
```
$ sudo greengrass-cli deployment list
44d89f46-1a29-4044-ad89-5151213dfcbc: SUCCEEDED
Created on: 6/27/23 11:05 AM
```
## status
Recupere o status de uma implantação específica.
**Resumo**
```
greengrass-cli deployment status -i
```
**Arguments (Argumentos)**
`-i`. O ID da implantação.
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse comando. Dependendo do status da sua implantação, a saída mostra um dos seguintes valores de status: `IN_PROGRESS`, `SUCCEEDED` ou `FAILED`.
```
$ sudo greengrass-cli deployment status -i 44d89f46-1a29-4044-ad89-5151213dfcbc
44d89f46-1a29-4044-ad89-5151213dfcbc: FAILED
Created on: 6/27/23 11:05 AM
Detailed Status:
Deployment Error Stack: List of error codes
Deployment Error Types: List of error types
Failure Cause: Cause
```
# logs
Use o comando `logs` para analisar logs do Greengrass no seu dispositivo principal.
**Subcomandos**
+ [get](#logs-get)
+ [list-keywords](#logs-list-keywords)
+ [list-log-files](#logs-list-log-files)
## get
Colete, filtre e visualize os arquivos de log do Greengrass. Esse comando é compatível somente com arquivos de log formatados em JSON. Você pode especificar o [formato de registro em log](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-logging-format) na configuração do núcleo.
**Resumo**
```
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`. O caminho para o diretório para verificar os arquivos de log, como **`/greengrass/v2`/logs**. Não use com `--syslog`. Use um argumento separado para cada diretório adicional para especificar. É necessário usar pelo menos um `--log-dir` ou `--log-file`. Você também pode usar os dois argumentos em um único comando.
+ `--log-file`, `-lf`. Os caminhos para os diretórios de logs que você deseja usar. Use um argumento separado para cada diretório adicional para especificar. É necessário usar pelo menos um `--log-dir` ou `--log-file`. Você também pode usar os dois argumentos em um único comando.
+ `--follow`, `-fol`. Mostre as atualizações de log à medida que elas ocorrem. A CLI do Greengrass continua sendo executada e lendo os logs especificados. Se você especificar uma janela de tempo, a CLI do Greengrass interromperá o monitoramento dos logs após o término de todas as janelas de tempo.
+ `--filter`, `-f`. A palavra-chave, as expressões regulares ou o par de valores-chave a serem usados como filtro. Forneça esse valor como string, expressão regular ou par de chave-valor. Use um argumento separado para cada filtro adicional para especificar.
Quando avaliados, vários filtros especificados em um único argumento são separados por operadores OR, e os filtros especificados em argumentos adicionais são combinados com operadores AND. Por exemplo, se seu comando incluir `--filter "installed" --filter "name=alpha,name=beta"`, a CLI do Greengrass filtrará e exibirá mensagens de log que contêm a palavra-chave `installed` e uma chave `name` com os valores `alpha` ou `beta`.
+ `--time-window`, `-t`. A janela de tempo para a qual mostrar as informações do log. Você pode usar carimbos de data/hora exatos e compensações relativas. Você deve fornecer essas informações no formato `,`. Se você não especificar a hora de início nem a hora de término, o valor dessa opção será padronizado para a data e a hora atuais do sistema. Use um argumento separado para cada janela de tempo adicional a ser especificada.
Use um argumento separado para cada janela de tempo adicional a ser especificada.
+ `yyyy-MM-DD`, por exemplo, `2020-06-30`. O horário padrão é 00:00:00 quando você usa esse formato.
`yyyyMMDD`, por exemplo, `20200630`. O horário padrão é 00:00:00 quando você usa esse formato.
`HH:mm:ss`, por exemplo, `15:30:45`. A data é padronizada para a data atual do sistema quando você usa esse formato.
`HH:mm:ssSSS`, por exemplo, `15:30:45`. A data assume como padrão a data atual do sistema quando você usa esse formato.
`YYYY-MM-DD'T'HH:mm:ss'Z'`, por exemplo, `2020-06-30T15:30:45Z`.
`YYYY-MM-DD'T'HH:mm:ss`, por exemplo, `2020-06-30T15:30:45`.
`yyyy-MM-dd'T'HH:mm:ss.SSS`, por exemplo, `2020-06-30T15:30:45.250`.
As compensações relativas especificam uma diferença de período em relação à hora atual do sistema. A CLI do Greengrass é compatível com o seguinte formato para compensações relativas: `+|-[h|hr|hours][valuem|min|minutes][value]s|sec|seconds`.
Por exemplo, o argumento a seguir para especificar uma janela de tempo entre 1 hora e 2 horas, 15 minutos antes da hora atual é `--time-window -2h15min,-1hr`.
+ `--verbose`. Mostra todos os campos das mensagens de log. Não use com `--syslog`.
+ `--no-color`, `-nc`. Remova o código de cores. O código de cores padrão para mensagens de log usa texto vermelho em negrito. É compatível apenas com terminais do tipo Unix porque usa sequências de escape ANSI.
+ `--before`, `-b`. O número de linhas a serem mostradas antes de uma entrada de log correspondente. O padrão é 0.
+ `--after`, `-a`. O número de linhas a serem mostradas após uma entrada de log correspondente. O padrão é 0.
+ `--syslog`. Processe todos os arquivos de log usando o protocolo syslog definido pelo RFC3164. Não use com `--log-dir` e `--verbose`. O protocolo syslog usa o seguinte formato: `"<$Priority>$Timestamp $Host $Logger ($Class): $Message"`. Se você não especificar um arquivo de log, a CLI do Greengrass lê as mensagens de log dos seguintes locais: `/var/log/messages`, `/var/log/syslog` ou `/var/log/system.log`.
No momento, o AWS IoT Greengrass não oferece suporte a esse recurso nos dispositivos principais do Windows.
+ `--max-log-queue-size`, `-m`. O número máximo de entradas de log a serem alocadas na memória. Use essa opção para otimizar o uso da memória. O padrão é de 100.
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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
Mostre as palavras-chave sugeridas que você pode usar para filtrar arquivos de log.
**Resumo**
```
greengrass-cli logs list-keywords [arguments]
```
**Argumentos**
Nenhum
**Saída**
Os exemplos apresentados a seguir mostram a saída produzida ao executar esse 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
Mostre arquivos de log localizados em um diretório especificado.
**Resumo**
```
greengrass-cli logs list-log-files [arguments]
```
**Argumentos**
`--log-dir`, `-ld`. O caminho para o diretório para verificar os arquivos de log.
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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
Use o comando `get-debug-password` para imprimir uma senha gerada aleatoriamente para o [componente do console de depuração local](local-debug-console-component.md) (`aws.greengrass.LocalDebugConsole`). A senha expira oito horas depois de ser gerada.
**Resumo**
```
greengrass-cli get-debug-password
```
**Argumentos**
Nenhum
**Saída**
O exemplo a seguir mostra a saída produzida ao executar esse 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
```
# Use a estrutura AWS IoT Greengrass de teste
O Greengrass Testing Framework (GTF) é uma coleção de componentes básicos que oferece suporte à end-to-end automação do ponto de vista do cliente. O GTF usa [Cucumber](https://cucumber.io) como driver de recursos. AWS IoT Greengrass usa os mesmos componentes básicos para qualificar as alterações de software em vários dispositivos. Para mais informações, consulte [Estrutura de testes do Greengrass no Github](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1).
O GTF é implementado usando o Cucumber, uma ferramenta usada para executar testes automatizados, para incentivar o desenvolvimento orientado pelo comportamento (BDD) dos componentes. No Cucumber, os atributos desse sistema são descritos em um tipo especial de arquivo chamado `feature`. Cada atributo é descrito em um formato legível por humanos chamado cenários, que são especificações que podem ser convertidas em testes automatizados. Cada cenário é descrito como uma série de etapas que definem as interações e os resultados desse sistema em teste usando uma linguagem específica de domínio chamada Gherkin. Uma [etapa Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) é vinculada ao código de programação usando um método chamado definição de etapa, que conecta a especificação ao fluxo de teste. As definições de etapas no GTF são implementadas com Java.
**Topics**
+ [Como funciona](#gg-testing-framework-how-gtf-works)
+ [Changelog](#gtf-changelog)
+ [Opções de configuração da estrutura de testes do Greengrass (Greengrass Testing Framework)](configuration-options-gtf.md)
+ [Tutorial: Execute end-to-end testes usando o Greengrass Testing Framework e o Greengrass Development Kit](run-e2e-tests-tutorial.md)
+ [Tutorial: usar um teste de confiança do conjunto de testes de confiança](confidence-tests-tutorial.md)
## Como funciona
AWS IoT Greengrass distribui o GTF como um JAR autônomo que consiste em vários módulos Java. Para usar o GTF para end-to-end testar componentes, você deve implementar os testes em um projeto Java. Adicionar o JAR padrão de teste como uma dependência em seu projeto Java permite que você use a funcionalidade existente do GTF e a estenda escrevendo seus próprios casos de teste personalizados. Para executar os casos de teste personalizados, você pode criar seu projeto Java e executar o JAR de destino com as opções de configuração descritas em [Opções de configuração da estrutura de testes do Greengrass (Greengrass Testing Framework)](configuration-options-gtf.md).
### JAR autônomo do GTF
O Greengrass usa o Cloudfront como um repositório [Maven](https://maven.apache.org/) para hospedar diferentes versões do JAR autônomo do GTF. Para uma lista completa das versões do GTF, consulte os [lançamentos do GTF](https://github.com/aws-greengrass/aws-greengrass-testing/releases).
O JAR autônomo do GTF inclui os seguintes módulos. Não se limita apenas a esses módulos. Você pode escolher cada uma dessas dependências separadamente em seu projeto ou incluí-las todas de uma vez com o [arquivo JAR autônomo de teste](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone).
+ `aws-greengrass-testing-resources`: este módulo fornece abstração para gerenciar o ciclo de vida de um AWS recurso durante o curso de um teste. Você pode usar isso para definir seus AWS recursos personalizados usando `ResourceSpec` abstração para que o GTF possa cuidar da criação e remoção desses recursos para você.
+ `aws-greengrass-testing-platform`: este módulo fornece abstração em nível de plataforma para o dispositivo em teste durante o ciclo de vida do teste. Ele é APIs usado para interagir com o sistema operacional independente da plataforma e pode ser usado para simular os comandos em execução no shell do dispositivo.
+ `aws-greengrass-testing-components`: este módulo consiste em amostras de componentes que são usados para testar os atributos de núcleo do Greengrass, como implantações, IPC e outros.
+ `aws-greengrass-testing-features`: este módulo consiste em etapas comuns reutilizáveis e as definições delas, que são usadas para testes no ambiente Greengrass.
**Topics**
+ [Como funciona](#gg-testing-framework-how-gtf-works)
+ [Changelog](#gtf-changelog)
+ [Opções de configuração da estrutura de testes do Greengrass (Greengrass Testing Framework)](configuration-options-gtf.md)
+ [Tutorial: Execute end-to-end testes usando o Greengrass Testing Framework e o Greengrass Development Kit](run-e2e-tests-tutorial.md)
+ [Tutorial: usar um teste de confiança do conjunto de testes de confiança](confidence-tests-tutorial.md)
## Changelog
A tabela a seguir descreve as alterações em cada versão do GTF. Para obter mais informações, consulte a [página de lançamentos do GTF](https://github.com/aws-greengrass/aws-greengrass-testing/releases) em. GitHub
| **Versão** | **Alterações** |
| --- | --- |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.0.0 | Versão inicial. |
# Opções de configuração da estrutura de testes do Greengrass (Greengrass Testing Framework)
## Opções de configuração do GTF
O GTF permite que você configure determinados parâmetros durante o lançamento do processo de teste de ponta a ponta para orquestrar o fluxo de teste. É possível especificar essas opções de configuração como argumentos de CLI para o JAR autônomo do GTF.
A versão 1.1.0 e posteriores do GTF oferecem as seguintes opções de configuração.
+ `additional-plugins`: (opcional) plug-ins adicionais do Cucumber
+ `aws-region`: tem como alvo endpoints regionais específicos para serviços da AWS. O padrão é o que o SDK da AWS descobre.
+ `credentials-path`: caminho opcional de credenciais do perfil da AWS. O padrão é credenciais descobertas no ambiente do host.
+ `credentials-path-rotation`: duração de rotação opcional para credenciais da AWS. O valor padrão é 15 minutos ou `PT15M`.
+ `csr-path`: o caminho para o CSR usando qual certificado do dispositivo será gerado.
+ `device-mode`: o dispositivo alvo em teste. O padrão é o dispositivo local.
+ `env-stage`: tem como alvo o ambiente de implantação do Greengrass. O padrão é produção.
+ `existing-device-cert-arn`: o arn de um certificado existente que você deseja usar como certificado de dispositivo para o Greengrass.
+ `feature-path`: arquivo ou diretório contendo arquivos de atributos adicionais. O padrão é não usar nenhum arquivo de atributo adicional.
+ `gg-cli-version`: substitui a versão da CLI do Greengrass. O padrão é o valor encontrado em `ggc.version`.
+ `gg-component-bucket`: o nome de um bucket existente do Amazon S3 que abriga os componentes do Greengrass.
+ `gg-component-overrides`: uma lista de substituições de componentes do Greengrass.
+ `gg-persist`: uma lista de elementos de teste a serem persistidos após a execução do teste. O comportamento padrão é não persistir em nada. Os valores aceitos são `aws.resources`, `installed.software` e `generated.files`.
+ `gg-runtime`: uma lista de valores para influenciar a forma como o teste interage com os recursos do teste. Esses valores substituem o parâmetro `gg.persist`. Se o padrão for vazio, ele presume que todos os recursos de teste são gerenciados pelo caso de teste, incluindo o runtime do Greengrass instalado. Os valores aceitos são `aws.resources`, `installed.software` e `generated.files`.
+ `ggc-archive`: o caminho para o componente do núcleo arquivado do Greengrass.
+ `ggc-install-root`: diretório para instalar o componente do núcleo do Greengrass. O padrão é test.temp.path e pasta de execução de teste.
+ `ggc-log-level`: defina o nível de log do núcleo do Greengrass para a execução do teste. O padrão é "INFO".
+ `ggc-tes-rolename`: o perfil do IAM que o AWS IoT Greengrass Core assumirá para acessar os serviços da AWS. Se um perfil com o nome fornecido não existir, será criada uma política de acesso padrão.
+ `ggc-trusted-plugins`: a lista separada por vírgula dos caminhos (no host) dos plug-ins confiáveis que precisam ser adicionados ao Greengrass. Para fornecer o caminho no próprio DUT, adicione o prefixo o caminho com 'dut':
+ `ggc-user-name`: o valor de user:group PosixUser para o núcleo do Greengrass. O padrão é o nome de usuário atual que está conectado.
+ `ggc-version`: substitui a versão do componente do núcleo do Greengrass em execução. O padrão é o valor encontrado em ggc.archive.
+ `log-level`: nível de log da execução do teste. O padrão é "INFO".
+ `parallel-config`: conjunto de índice de lote e número de lotes como uma string JSON. O valor padrão do índice do lote é 0 e o número de lotes é 1.
+ `proxy-url`: configure todos os testes para rotear o tráfego por meio desse URL.
+ `tags`: executa apenas tags de recursos. Pode ser cruzado com '&'
+ `test-id-prefix`: um prefixo comum aplicado a todos os recursos específicos do teste, incluindo nomes e tags de recursos da AWS. O padrão é um prefixo "gg".
+ `test-log-path`: diretório que conterá os resultados de toda a execução do teste. O padrão é "testResults".
+ `test-results-json`: sinalize para determinar se um relatório JSON do Cucumber resultante foi gerado e gravado no disco. O valor padrão é verdadeiro.
+ `test-results-log`: sinalize para determinar se a saída do console foi gerada e gravada no disco. O padrão é falso.
+ `test-results-xml`: sinalize para determinar se um relatório XML JUnit resultante é gerado e gravado em disco. O valor padrão é verdadeiro.
+ `test-temp-path`: diretório para gerar artefatos de teste locais. O padrão é um diretório temporário aleatório prefixado com gg-testing.
+ `timeout-multiplier`: multiplicador fornecido para todos os tempos limite de teste. O padrão é 1.0.
# Tutorial: Execute end-to-end testes usando o Greengrass Testing Framework e o Greengrass Development Kit
AWS IoT Greengrass O Testing Framework (GTF) e o Greengrass Development Kit (GDK) oferecem aos desenvolvedores maneiras de executar testes. end-to-end Você pode concluir este tutorial para inicializar um projeto do GDK com um componente, inicializar um projeto do GDK com um módulo de end-to-end teste e criar um caso de teste personalizado. Depois de criar seu caso de teste personalizado, você poderá executar o teste.
Neste tutorial, você faz o seguinte:
1. Inicialize um projeto do GDK com um componente.
1. Inicialize um projeto GDK com um módulo de end-to-end teste.
1. Crie um caso de teste personalizado.
1. Adicione uma tag ao novo caso de teste.
1. Crie o JAR de teste.
1. Execute o teste do .
**Topics**
+ [Pré-requisitos](#run-e2e-tests-tutorial-prerequisites)
+ [Etapa 1: inicializar um projeto do GDK com um componente](#init-gdk-with-component)
+ [Etapa 2: inicializar um projeto do GDK com um end-to-end módulo de teste](#init-gdk-with-e2e-test)
+ [Etapa 3: definir um caso de teste personalizado](#run-e2e-tests-tutorial-instructions)
+ [Etapa 4: Adicionar uma tag ao novo caso de teste](#add-tag-to-test-case)
+ [Etapa 5: compilar o JAR de teste](#build-test-jar)
+ [Etapa 6: executar o teste](#run-test-gtf)
+ [Exemplo: criar um caso de teste personalizado](#build-test-case-example)
## Pré-requisitos
Para concluir este tutorial, você precisará do seguinte:
+ GDK versão 1.3.0 ou posterior
+ Java
+ Maven
+ Git
## Etapa 1: inicializar um projeto do GDK com um componente
+ Inicialize uma pasta vazia com um projeto do GDK. Faça download do componente `HelloWorld` implementado em Python executando o comando a seguir.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Esse comando cria um diretório chamado `HelloWorld` no diretório atual.
## Etapa 2: inicializar um projeto do GDK com um end-to-end módulo de teste
+ O GDK permite que você baixe o modelo do módulo de teste que consiste em uma implementação de atributos e etapas. Execute o comando a seguir para abrir o diretório `HelloWorld` e inicializar o projeto GDK existente usando um módulo de teste.
```
cd HelloWorld
gdk test-e2e init
```
Esse comando cria um diretório chamado `gg-e2e-tests` no diretório `HelloWorld`. Esse diretório de teste é um projeto [Maven](https://maven.apache.org/) que depende do JAR independente de testes do Greengrass.
## Etapa 3: definir um caso de teste personalizado
Escrever um caso de teste personalizado consiste basicamente em duas etapas: criar um arquivo de recurso com um cenário de teste e implementar as definições das etapas. Para ver um exemplo de criação de um caso de teste personalizado, consulte [Exemplo: criar um caso de teste personalizado](#build-test-case-example). Use as etapas a seguir para criar seu caso de teste personalizado:
1. Criar um arquivo de recurso com um cenário de teste
Um recurso geralmente descreve uma funcionalidade específica do software que está sendo testado. No Cucumber, cada recurso é especificado como um arquivo de recurso individual com um título, uma descrição detalhada e um ou mais exemplos de casos específicos chamados cenários. Cada cenário consiste em um título, uma descrição detalhada e uma série de etapas que definem as interações e os resultados esperados. Os cenários são escritos em um formato estruturado usando as palavras-chave “determinado”, “quando” e “então”.
1. Implementar definições de etapas
Uma definição de etapa vincula a [etapa Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) em linguagem simples ao código programático. Quando o Cucumber identifica uma etapa do Gherkin em um cenário, ele procura uma definição de etapa correspondente para ser executada.
## Etapa 4: Adicionar uma tag ao novo caso de teste
+ Você pode atribuir tags aos atributos e cenários para organizar o processo de teste. Você pode usar tags para categorizar os subconjuntos de cenários e também selecionar hooks condicionalmente para execução. Os atributos e os cenários podem ter várias tags separadas por um espaço.
Neste exemplo, usamos o componente `HelloWorld`.
No arquivo de recurso, adicione uma nova tag chamada `@HelloWorld` ao lado da tag `@Sample`.
```
@Sample @HelloWorld
Scenario: As a developer, I can create a component and deploy it on my device
....
```
## Etapa 5: compilar o JAR de teste
1. Crie o componente. Você deve criar o componente antes de criar o módulo de teste.
```
gdk component build
```
1. Crie o módulo de teste usando o comando a seguir. Esse comando criará o JAR de teste na pasta `greengrass-build`.
```
gdk test-e2e build
```
## Etapa 6: executar o teste
Quando você executa um caso de teste personalizado, o GTF automatiza o ciclo de vida do teste junto com o gerenciamento de recursos que foram criados durante o teste. Primeiro, ele provisiona um dispositivo em teste (DUT) como uma AWS IoT coisa e instala o software principal do Greengrass nele. Em seguida, ele criará um novo componente chamado `HelloWorld` usando a fórmula especificada nesse caminho. O componente do `HelloWorld` é então implantado no dispositivo principal por meio de uma implantação da coisa do Greengrass. Em seguida, é verificado se a implantação foi bem-sucedida. O status da implantação será alterado para `COMPLETED` dentro de 3 minutos se a implantação for bem-sucedida.
1. Vá para o arquivo `gdk-config.json` no diretório do projeto para direcionar os testes com a tag `HelloWorld`. Atualize a chave `test-e2e` usando o comando a seguir.
```
"test-e2e":{
"gtf_options" : {
"tags":"HelloWorld"
}
}
```
1. Antes de executar os testes, você deve fornecer AWS credenciais para o dispositivo host. O GTF usa essas credenciais para gerenciar os AWS recursos durante o processo de teste. Certifique-se de que o perfil fornecido tenha permissões para automatizar as operações necessárias incluídas no teste.
Execute os comandos a seguir para fornecer as AWS credenciais.
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. Execute o teste usando o seguinte comando.
```
gdk test-e2e run
```
Esse comando baixa a versão mais recente do núcleo do Greengrass na pasta `greengrass-build` e executa testes usando-a. Esse comando também visa somente os cenários com a tag `HelloWorld` e gera um relatório para eles. Você verá que os AWS recursos criados durante esse teste serão descartados no final do teste.
## Exemplo: criar um caso de teste personalizado
**Example**
O módulo de teste baixado no projeto GDK consiste em um recurso de amostra e um arquivo de implementação de etapas.
No exemplo a seguir, criamos um arquivo de atributo para testar o atributo de implantação do objeto do software Greengrass. Testamos parcialmente a funcionalidade desse atributo com um cenário que executa a implantação de um componente por meio da Nuvem AWS do Greengrass. Esta é uma série de etapas que nos ajudam a entender as interações e os resultados esperados deste caso de uso.
1.
**Criar um arquivo de atributos**
Navegue até a pasta `gg-e2e-tests/src/main/resources/greengrass/features` no diretório atual. É possível encontrar uma amostra `component.feature` que parece com o exemplo a seguir.
Nesse arquivo de recurso, você pode testar o recurso de implantação do software Greengrass. Você pode testar parcialmente a funcionalidade desse recurso com um cenário que executa uma implantação de um componente por meio da nuvem do Greengrass. O cenário é uma série de etapas que ajudam a entender as interações e os resultados esperados desse caso de uso.
```
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
```
O GTF contém as definições de etapas de todas as etapas a seguir, exceto a etapa chamada: `And I call my custom step`.
1.
**Implementar definições de etapas**
O JAR autônomo GTF contém as definições de todas as etapas, exceto uma: `And I call my custom step`. Você pode implementar essa etapa no módulo de teste.
Navegue até o código-fonte do arquivo de teste. É possível vincular sua etapa personalizada usando uma definição de etapa usando o comando a seguir.
```
@And("I call my custom step")
public void customStep() {
System.out.println("My custom step was called ");
}
```
# Tutorial: usar um teste de confiança do conjunto de testes de confiança
AWS IoT Greengrass O Testing Framework (GTF) e o Greengrass Development Kit (GDK) oferecem aos desenvolvedores maneiras de executar testes. end-to-end Você pode concluir este tutorial para inicializar um projeto do GDK com um componente, inicializar um projeto do GDK com um módulo de end-to-end teste e usar um teste de confiança do conjunto de testes de confiança. Depois de criar seu caso de teste personalizado, você poderá executar o teste.
Um teste de confiança é um teste genérico fornecido pelo Greengrass que valida os comportamentos dos componentes fundamentais. Esses testes podem ser modificados ou estendidos para atender às necessidades mais específicas dos componentes.
Para este tutorial, usaremos um HelloWorld componente. Se você estiver usando outro componente, substitua o HelloWorld componente pelo seu componente.
Neste tutorial, você faz o seguinte:
1. Inicialize um projeto do GDK com um componente.
1. Inicialize um projeto GDK com um módulo de end-to-end teste.
1. Use um teste do conjunto de testes de confiança.
1. Adicione uma tag ao novo caso de teste.
1. Crie o JAR de teste.
1. Execute o teste do .
**Topics**
+ [Pré-requisitos](#confidence-tests-tutorial-prerequisites)
+ [Etapa 1: inicializar um projeto do GDK com um componente](#init-gdk-with-component)
+ [Etapa 2: inicializar um projeto do GDK com um end-to-end módulo de teste](#init-gdk-with-e2e-test)
+ [Etapa 3: usar um teste do conjunto de testes de confiança](#confidence-tests-tutorial-instructions)
+ [Etapa 4: adicionar uma tag ao novo caso de teste](#add-tag-to-test-case)
+ [Etapa 5: compilar o JAR de teste](#build-test-jar)
+ [Etapa 6: executar o teste](#run-test-gtf)
+ [Exemplo: usar um teste de confiança](#build-confidence-test-case-example)
## Pré-requisitos
Para concluir este tutorial, você precisará do seguinte:
+ GDK versão 1.6.0 ou posterior
+ Java
+ Maven
+ Git
## Etapa 1: inicializar um projeto do GDK com um componente
+ Inicialize uma pasta vazia com um projeto do GDK. Faça download do componente `HelloWorld` implementado em Python executando o comando a seguir.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Esse comando cria um diretório chamado `HelloWorld` no diretório atual.
## Etapa 2: inicializar um projeto do GDK com um end-to-end módulo de teste
+ O GDK permite que você baixe o modelo do módulo de teste que consiste em uma implementação de atributos e etapas. Execute o comando a seguir para abrir o diretório `HelloWorld` e inicializar o projeto GDK existente usando um módulo de teste.
```
cd HelloWorld
gdk test-e2e init
```
Esse comando cria um diretório chamado `gg-e2e-tests` no diretório `HelloWorld`. Esse diretório de teste é um projeto [Maven](https://maven.apache.org/) que depende do JAR independente de testes do Greengrass.
## Etapa 3: usar um teste do conjunto de testes de confiança
Escrever um caso de teste de confiança consiste em usar o arquivo de atributo fornecido e, se necessário, modificar os cenários. Para ver um exemplo de uso do teste de confiança, consulte [Exemplo: criar um caso de teste personalizado](run-e2e-tests-tutorial.md#build-test-case-example). Siga as etapas a seguir para usar um teste de confiança:
+ Use o arquivo de atributo fornecido.
Navegue até a pasta `gg-e2e-tests/src/main/resources/greengrass/features` no diretório atual. Abra o arquivo `confidenceTest.feature` de amostra para usar o teste de confiança.
## Etapa 4: adicionar uma tag ao novo caso de teste
+ Você pode atribuir tags aos atributos e cenários para organizar o processo de teste. Você pode usar tags para categorizar os subconjuntos de cenários e também selecionar hooks condicionalmente para execução. Os atributos e os cenários podem ter várias tags separadas por um espaço.
Neste exemplo, usamos o componente `HelloWorld`.
Cada cenário é marcado com `@ConfidenceTest`. Altere ou adicione tags se quiser executar somente um subconjunto do conjunto de testes. Cada cenário de teste é descrito na parte superior de cada teste de confiança. O cenário é uma série de etapas que ajudam a entender as interações e os resultados esperados de cada caso de teste. É possível estender esses testes adicionando suas próprias etapas ou modificando as existentes.
```
@ConfidenceTest
Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected
....
```
## Etapa 5: compilar o JAR de teste
1. Crie o componente. Você deve criar o componente antes de criar o módulo de teste.
```
gdk component build
```
1. Crie o módulo de teste usando o comando a seguir. Esse comando criará o JAR de teste na pasta `greengrass-build`.
```
gdk test-e2e build
```
## Etapa 6: executar o teste
Quando você executa um teste de confiança, o GTF automatiza o ciclo de vida do teste, além de gerenciar os recursos que foram criados durante o teste. Primeiro, ele provisiona um dispositivo em teste (DUT) como uma AWS IoT coisa e instala o software principal do Greengrass nele. Em seguida, ele criará um novo componente chamado `HelloWorld` usando a fórmula especificada nesse caminho. O componente do `HelloWorld` é então implantado no dispositivo principal por meio de uma implantação da coisa do Greengrass. Em seguida, é verificado se a implantação foi bem-sucedida. O status da implantação será alterado para `COMPLETED` dentro de 3 minutos se a implantação for bem-sucedida.
1. Acesse o arquivo `gdk-config.json` no diretório do projeto para direcionar os testes com a tag `ConfidenceTest` ou qualquer tag que você especificou na etapa 4. Atualize a chave `test-e2e` usando o seguinte comando.
```
"test-e2e":{
"gtf_options" : {
"tags":"ConfidenceTest"
}
}
```
1. Antes de executar os testes, você deve fornecer AWS credenciais para o dispositivo host. O GTF usa essas credenciais para gerenciar os AWS recursos durante o processo de teste. Certifique-se de que o perfil fornecido tenha permissões para automatizar as operações necessárias incluídas no teste.
Execute os comandos a seguir para fornecer as AWS credenciais.
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. Execute o teste usando o seguinte comando.
```
gdk test-e2e run
```
Esse comando baixa a versão mais recente do núcleo do Greengrass na pasta `greengrass-build` e executa testes usando-a. Esse comando também visa somente os cenários com a tag `ConfidenceTest` e gera um relatório para eles. Você verá que os AWS recursos criados durante esse teste serão descartados no final do teste.
## Exemplo: usar um teste de confiança
**Example**
O módulo de teste baixado no projeto do GDK consiste em um arquivo de atributo fornecido.
No exemplo a seguir, usamos um arquivo de atributo para testar o atributo de implantação do objeto do software Greengrass. Testamos parcialmente a funcionalidade desse atributo com um cenário que executa a implantação de um componente por meio da Nuvem AWS do Greengrass. Esta é uma série de etapas que nos ajudam a entender as interações e os resultados esperados deste caso de uso.
+
**Use o arquivo de atributo fornecido.**
Navegue até a pasta `gg-e2e-tests/src/main/resources/greengrass/features` no diretório atual. É possível encontrar uma amostra `confidenceTest.feature` que parece com o exemplo a seguir.
```
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 cenário de teste é descrito na parte superior de cada teste de confiança. O cenário é uma série de etapas que ajudam a entender as interações e os resultados esperados de cada caso de teste. É possível estender esses testes adicionando suas próprias etapas ou modificando as existentes. Cada um dos cenários inclui comentários que ajudam a fazer esses ajustes.