A Amazon não CodeCatalyst está mais aberta a novos clientes. Os clientes atuais podem continuar usando o serviço normalmente. Para obter mais informações, consulte [Como migrar do CodeCatalyst](migration.md). 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á. # Compilação, teste e implantação com fluxos de trabalho Depois de escrever o código do aplicativo em um [ambiente de CodeCatalyst desenvolvimento](devenvironment.md) e enviá-lo para o [repositório de CodeCatalyst origem](source.md), você está pronto para implantá-lo. A maneira de fazer isso automaticamente é por meio de um fluxo de trabalho. *Fluxo de trabalho* é um procedimento automatizado que descreve como criar, testar e implantar o código como parte de um sistema de integração contínua e entrega contínua (CI/CD). Um fluxo de trabalho define uma série de etapas ou *ações* a serem realizadas durante a execução de um fluxo de trabalho. Um fluxo de trabalho também define os eventos, ou *gatilhos*, que fazem com que o fluxo de trabalho seja iniciado. Para configurar um fluxo de trabalho, você cria um *arquivo de definição de fluxo* de trabalho usando o [editor visual ou YAML](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors) do CodeCatalyst console. **dica** Para ver rapidamente como usar fluxos de trabalho em um projeto, [crie um projeto com um esquema](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template). Cada esquema implanta um fluxo de trabalho funcional que você pode revisar, executar e experimentar. ## Sobre o arquivo de definição do fluxo de trabalho *Arquivo de definição de fluxo de trabalho* é um arquivo YAML que descreve o fluxo de trabalho. Por padrão, o arquivo é armazenado em uma pasta `~/.codecatalyst/workflows/` na raiz do [repositório de origem](source-repositories.md). O arquivo pode ter uma extensão .yml ou .yaml, e a extensão deve estar em minúsculas. Veja a seguir um exemplo de um arquivo de definição de fluxo de trabalho simples. Explicamos cada linha desse exemplo na tabela a seguir. ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: docker build -t MyApp:latest . ``` | Linha | Description | | --- | --- | |

Name: MyWorkflow

| Especifica o nome do fluxo de trabalho. Para ter mais informações sobre a propriedade do `Name`, consulte [Propriedades de nível superior](workflow-reference.md#workflow.top.level). | |

SchemaVersion: 1.0

| Especifica a versão do esquema de fluxo de trabalho. Para ter mais informações sobre a propriedade do `SchemaVersion`, consulte [Propriedades de nível superior](workflow-reference.md#workflow.top.level). | |

RunMode: QUEUED

| Indica como CodeCatalyst lida com várias execuções. Para ter mais informações sobre o modo de execução, consulte [Configurar o comportamento de enfileiramento das execuções](workflows-configure-runs.md). | |

Triggers:

| Especifica a lógica que fará com que a execução de um fluxo de trabalho seja iniciada. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). | |

- Type: PUSH
  Branches:
    - main

| Indica que o fluxo de trabalho deve ser iniciado sempre que você envia o código para a ramificação `main` do repositório de origem padrão. Para ter mais informações sobre a origem do fluxo de trabalho, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). | |

Actions:

| Define as tarefas a serem realizadas durante a execução de um fluxo de trabalho. Neste exemplo, a seção `Actions` define uma única ação chamada `Build`. Para ter mais informações sobre as ações, consulte [Configuração de ações de fluxo de trabalho](workflows-actions.md). | |

Build:

| Define as propriedades da ação `Build`. Para ter mais informações sobre a ação de criação, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). | |

Identifier: aws/build@v1

| Especifica o identificador exclusivo e com codificação rígida para a ação de criação. | |

Inputs:
  Sources:
    - WorkflowSource

| Indica que a ação de criação deve procurar no repositório de origem `WorkflowSource` os arquivos necessários para concluir o processamento. Para obter mais informações, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). | |

Configuration:

| Contém as propriedades de configuração específicas para a ação de criação. | |

Steps:
  - Run: docker build -t MyApp:latest .

| Diz à ação de criação que crie uma imagem do Docker chamada `MyApp` e a marque com `latest`. | Para ver uma lista completa de todas as propriedades disponíveis no arquivo de definição de fluxo de trabalho, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). ## Usando os editores visual e YAML do CodeCatalyst console Para criar e editar o arquivo de definição do fluxo de trabalho, você pode usar seu editor preferido, mas recomendamos usar o editor visual ou o editor YAML do CodeCatalyst console. Esses editores oferecem validação útil de arquivos para ajudar a garantir que nomes, valores, aninhamento, espaçamento, uso de letras maiúsculas e minúsculas, etc. das propriedades YAML estejam corretos. A imagem a seguir mostra um fluxo de trabalho no editor visual. O editor visual oferece uma interface de usuário completa para criar e configurar seu arquivo de definição de fluxo de trabalho. O editor visual inclui um diagrama de fluxo de trabalho (1) mostrando os principais componentes do fluxo de trabalho e uma área de configuração (2). ![\[Editor visual de fluxo de trabalho\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/workflow-visual-editor.png) Como alternativa, é possível usar o editor YAML, mostrado na imagem a seguir. Use o editor YAML para colar blocos de código grandes (de um tutorial, por exemplo) ou para adicionar propriedades avançadas que não são oferecidas pelo editor visual. ![\[Editor YAML do fluxo de trabalho\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/workflow-yaml-editor.png) Você pode alternar do editor visual para o editor YAML para ver o efeito que suas configurações têm no código YAML subjacente. ## Descoberta de fluxos de trabalho Você pode visualizar seu fluxo de trabalho na página de resumo dos **Fluxos de trabalho**, junto com outros fluxos de trabalho configurados no mesmo projeto. A seguinte imagem mostra a página de resumo dos **Fluxos de trabalho**. Ele é preenchido com dois fluxos de trabalho: e. **BuildToProd**UnitTests**** Você pode ver que ambos foram executados algumas vezes. Selecione **Execuções recentes** para ver rapidamente o histórico de execuções ou selecione o nome do fluxo de trabalho para ver o código YAML do fluxo de trabalho e outras informações detalhadas. ![\[Logs do fluxo de trabalho\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/workflow-list.png) ## Visualização de detalhes da execução do fluxo de trabalho Visualize os detalhes da execução de um fluxo de trabalho selecionando a execução na página de resumo dos **Fluxos de trabalho**. A imagem a seguir mostra os detalhes de uma execução de fluxo de trabalho chamada **Run-cc11d**, iniciada automaticamente em uma confirmação na origem. O diagrama do fluxo de trabalho indica que uma ação falhou (1). Você pode navegar até os logs (2) para visualizar as mensagens de log detalhadas e solucionar problemas. Para ter mais informações sobre execuções de fluxos de trabalho, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). ![\[Logs do fluxo de trabalho\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/workflow-visual-logs.png) ## Próximas etapas Para saber mais sobre conceitos de fluxos de trabalho, consulte [Conceitos de fluxos de trabalho](workflows-concepts.md). Para criar seu primeiro fluxo de trabalho, consulte [Conceitos básicos de fluxos de trabalho](workflows-getting-started.md). # Conceitos de fluxos de trabalho Aqui estão alguns conceitos e termos que você deve conhecer ao criar, testar ou implantar seu código com fluxos de trabalho. CodeCatalyst ## Fluxos de trabalho *Fluxo de trabalho* é um procedimento automatizado que descreve como criar, testar e implantar o código como parte de um sistema de integração contínua e entrega contínua (CI/CD). Um fluxo de trabalho define uma série de etapas ou *ações* a serem realizadas durante a execução de um fluxo de trabalho. Um fluxo de trabalho também define os eventos, ou *gatilhos*, que fazem com que o fluxo de trabalho seja iniciado. Para configurar um fluxo de trabalho, você cria um *arquivo de definição de fluxo* de trabalho usando o [editor visual ou YAML](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors) do CodeCatalyst console. **dica** Para ver rapidamente como usar fluxos de trabalho em um projeto, [crie um projeto com um esquema](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template). Cada esquema implanta um fluxo de trabalho funcional que você pode revisar, executar e experimentar. ## Arquivos de definição de fluxo de trabalho *Arquivo de definição de fluxo de trabalho* é um arquivo YAML que descreve o fluxo de trabalho. Por padrão, o arquivo é armazenado em uma pasta `~/.codecatalyst/workflows/` na raiz do [repositório de origem](source-repositories.md). O arquivo pode ter uma extensão .yml ou .yaml, e a extensão deve estar em minúsculas. Para ter mais informações sobre o arquivo de definição de fluxo de trabalho, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). ## Ações Uma *ação* é o principal componente de um fluxo de trabalho e define uma unidade lógica de trabalho, ou tarefa, a ser realizada durante a execução de um fluxo de trabalho. Normalmente, um fluxo de trabalho inclui várias ações que são executadas de modo sequencial ou paralelo, dependendo de como você as configurou. Para ter mais informações sobre as ações, consulte [Configuração de ações de fluxo de trabalho](workflows-actions.md). ## Grupos de ações Um *grupo de ações* contém uma ou mais ações. O agrupamento de ações em grupos ajuda a manter o fluxo de trabalho organizado e também permite configurar dependências entre grupos diferentes. Para ter mais informações sobre os grupos de ações, consulte [Agrupar ações em grupos de ações](workflows-group-actions.md). ## Artefatos *Artefato* é a saída de uma ação de fluxo de trabalho e geralmente consiste em uma pasta ou um arquivameto de arquivos. Os artefatos são importantes porque permitem que você compartilhe arquivos e informações entre as ações. Para obter mais informações sobre artefatos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). ## Computação *Computação* se refere ao mecanismo de computação (CPU, memória e sistema operacional) gerenciado e mantido por CodeCatalyst para executar ações de fluxo de trabalho. Para ter mais informações sobre computação, consulte [Configuração de imagens de computação e runtime](workflows-working-compute.md). ## Ambientes do Um CodeCatalyst *ambiente*, que não deve ser confundido com um [ambiente de desenvolvimento](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html), define o Amazon VPC de destino Conta da AWS e opcional ao qual um CodeCatalyst [fluxo de trabalho](workflow.md) se conecta. Um ambiente também define a [função do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um fluxo de trabalho precisa para acessar os AWS serviços e recursos na conta de destino. É possível configurar vários ambientes e atribuir a eles nomes, como desenvolvimento, teste, preparação e produção. Quando você implanta nesses ambientes, as informações sobre as implantações aparecem nas CodeCatalyst guias **Atividade** de **implantação e Destinos** de implantação no ambiente. Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md). ## Portões *Portão* é um componente do fluxo de trabalho que pode ser usado para impedir que a execução do fluxo de trabalho continue, a menos que determinadas condições sejam atendidas. Um exemplo de porta é a porta de **aprovação**, na qual os usuários devem enviar uma aprovação no CodeCatalyst console antes que a execução do fluxo de trabalho possa continuar. É possível adicionar portões entre sequências de ações a um fluxo de trabalho ou antes da primeira ação (executada imediatamente após o download da **Origem**). Também será possível adicionar portões após a última ação, se necessário. Para ter mais informações sobre portões, consulte [Bloquear uma execução de fluxo de trabalho](workflows-gates.md). ## Relatórios Um *relatório* contém detalhes sobre os testes que ocorrem durante a execução de um fluxo de trabalho. É possível criar relatórios, por exemplo, de teste, de cobertura de código, de análise de composição de software e de análise estática. É possível usar um relatório para ajudar a solucionar um problema durante um fluxo de trabalho. Se você tiver muitos relatórios de vários fluxos de trabalho, poderá usá-los para visualizar tendências e taxas de falha para ajudar a otimizar as aplicações e as configurações de implantação. Para obter mais informações sobre os relatórios, consulte [Tipos de relatório de qualidade](test-workflow-actions.md#test-reporting). ## Execuções *Execução* é uma iteração única de um fluxo de trabalho. Durante uma execução, CodeCatalyst executa as ações definidas no arquivo de configuração do fluxo de trabalho e gera os registros, artefatos e variáveis associados. Para ter mais informações sobre execuções, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). ## Fontes *Origem*, também chamada de *origem de entrada*, é um repositório de origem ao qual uma [ação de fluxo de trabalho](workflows-actions.md) se conecta para receber os arquivos necessários com o objetivo de realizar as operações. Por exemplo, uma ação de fluxo de trabalho pode se conectar a um repositório de origem para receber arquivos de origem a aplicação com o objetivo de criar uma aplicação. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). ## Variáveis Uma *variável* é um par de valores-chave que contém informações que você pode consultar em seu fluxo de trabalho da Amazon CodeCatalyst . A parte do valor da variável é substituída por um valor real quando o fluxo de trabalho é executado. Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). ## Gatilhos do fluxo de trabalho Um *gatilho de fluxo de trabalho*, ou simplesmente um *gatilho*, permite que você inicie a execução automática de um fluxo de trabalho quando determinados eventos ocorrerem, como um envio de código. Talvez você queira configurar gatilhos para liberar seus desenvolvedores de software da necessidade de iniciar execuções de fluxo de trabalho manualmente por meio do CodeCatalyst console. É possível usar três tipos de gatilho: + **Envio**: um gatilho de envio de código faz com que a execução de um fluxo de trabalho seja iniciada sempre que uma confirmação é enviada. + **Solicitação pull**: um gatilho de solicitação pull faz com que a execução de um fluxo de trabalho seja iniciada sempre que uma solicitação pull é criada, revisada ou fechada. + **Programação**: um gatilho de programação faz com que a execução de um fluxo de trabalho comece em uma programação definida por você. Pense em usar um gatilho de programação para executar compilações noturnas do software para que a versão mais recente esteja pronta para os desenvolvedores de software trabalharem na manhã seguinte. É possível usar gatilhos de envio, solicitação pull e programação de maneira independente ou combinados no mesmo fluxo de trabalho. Os gatilhos são opcionais. Se você não configurar nenhum, só poderá iniciar um fluxo de trabalho manualmente. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). # Conceitos básicos de fluxos de trabalho Neste tutorial, você aprenderá a criar e configurar o primeiro fluxo de trabalho. **dica** Prefere começar com um fluxo de trabalho pré-configurado? Consulte [Criar um projeto com um esquema](projects-create.md#projects-create-console-template), que inclui instruções para configurar um projeto com um fluxo de trabalho funcional, uma aplicação de exemplo e outros recursos. **Topics** + [ ## Pré-requisitos ](#get-started-create-workflow-prerequisites) + [ ## Etapa 1: criar e configurar o fluxo de trabalho ](#get-started-create-workflow-create) + [ ## Etapa 2: salvar o fluxo de trabalho com uma confirmação ](#get-started-create-workflow-commit) + [ ## Etapa 3: visualizar os resultados da execução ](#get-started-create-workflow-results) + [ ## (Opcional) Etapa 4: limpar ](#get-started-create-workflow-cleanup) ## Pré-requisitos Antes de começar + Você precisa de um CodeCatalyst **espaço**. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). + Em seu CodeCatalyst espaço, você precisa de um projeto vazio chamado: ``` codecatalyst-project ``` Para obter mais informações, consulte [Criando um projeto vazio na Amazon CodeCatalyst](projects-create.md#projects-create-empty). + No seu projeto, você precisa de um CodeCatalyst **repositório** chamado: ``` codecatalyst-source-repository ``` Para obter mais informações, consulte [Criar um repositório de origem](source-repositories-create.md). **nota** Se você tiver um projeto e um repositório de origem, poderá usá-los; no entanto, a criação de outros facilita a limpeza no final deste tutorial. ## Etapa 1: criar e configurar o fluxo de trabalho Nesta etapa, você cria e configura um fluxo de trabalho que compila e testa automaticamente o código-fonte quando as alterações são feitas. **Como criar o fluxo de trabalho** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho**. O arquivo de definição do fluxo de trabalho aparece no editor YAML do CodeCatalyst console. **Como configurar o fluxo de trabalho** Você pode configurar o fluxo de trabalho no editor **Visual** ou no editor **YAML**. Vamos começar com o editor YAML e depois mudar para o editor visual. 1. Escolha **\$1 Ações** para ver uma lista de ações do fluxo de trabalho que você pode adicionar ao fluxo de trabalho. 1. Na ação **Criar**, selecione **\$1** para adicionar o YAML da ação ao arquivo de definição de fluxo de trabalho. O fluxo de trabalho será semelhante ao mostrado a seguir. ``` Name: Workflow_fe47 SchemaVersion: "1.0" # Optional - Set automatic triggers. Triggers: - Type: Push Branches: - main # Required - Define action configurations. Actions: Build_f0: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource # This specifies that the action requires this workflow as a source Outputs: AutoDiscoverReports: Enabled: true # Use as prefix for the report files ReportNamePrefix: rpt Configuration: Steps: - Run: echo "Hello, World!" - Run: echo "" >> report.xml - Run: echo "" >> report.xml - Run: echo "" >> report.xml ``` **O fluxo de trabalho copia os arquivos no repositório de `WorkflowSource` origem para a máquina computacional que executa a `Build_f0` ação, imprime `Hello, World!` nos registros, descobre relatórios de teste na máquina computacional e os envia para a página Relatórios do CodeCatalyst console.** 1. Selecione **Visual** para visualizar o arquivo de definição do fluxo de trabalho no editor visual. Os campos no editor visual permitem configurar as propriedades YAML mostradas no editor YAML. ## Etapa 2: salvar o fluxo de trabalho com uma confirmação Nesta etapa, você salva as alterações. Como os fluxos de trabalho são armazenados como arquivos `.yaml` no repositório, você salva suas alterações com confirmações. **Como confirmar as alterações no fluxo de trabalho** 1. (Opcional) Selecione **Validar** para garantir que o código YAML do fluxo de trabalho seja válido. 1. Selecione **Confirmar**. 1. Em **Nome do arquivo do fluxo de trabalho**, insira um nome para o arquivo de configuração do fluxo de trabalho, como **my-first-workflow**. 1. Em **Mensagem de confirmação**, insira uma mensagem para identificar sua confirmação, por exemplo **create my-first-workflow.yaml**. 1. Em **Repositório**, selecione o repositório no qual você deseja salvar o fluxo de trabalho (`codecatalyst-repository`). 1. Em **Nome da ramificação**, selecione a ramificação na qual você deseja salvar o fluxo de trabalho (`main`). 1. Selecione **Confirmar**. Seu novo fluxo de trabalho aparece na lista de fluxos de trabalho. A exibição pode demorar alguns instantes. Como os fluxos de trabalho são salvos com confirmações e como o fluxo de trabalho tem um gatilho de envio de código configurado, salvar o fluxo de trabalho inicia a execução do fluxo de trabalho automaticamente. ## Etapa 3: visualizar os resultados da execução Nesta etapa, você navega até a execução que foi iniciada a partir da sua confirmação e visualiza os resultados. **Como visualizar os resultados da execução** 1. Selecione o nome do fluxo de trabalho, por exemplo, `Workflow_fe47`. Um diagrama de fluxo de trabalho mostrando o rótulo do seu repositório de origem (**WorkflowSource**) e a ação de criação (por exemplo, **build\$1F0**). 1. No diagrama de execução do fluxo de trabalho, selecione a ação de criação (por exemplo, **Build\$1f0**). 1. Analise o conteúdo das guias **Logs**, **Relatórios**, **Configuração** e **Variáveis**. Essas guias mostram os resultados da sua ação de criação. Para obter mais informações, consulte [Visualização dos resultados de uma ação de criação](build-view-results.md). ## (Opcional) Etapa 4: limpar Nesta etapa, você limpará os recursos que criou neste tutorial. **Como excluir recursos** + Se você criou um projeto para este tutorial, exclua-o. Para instruções, consulte [Excluir um projeto](projects-delete.md). A exclusão do projeto também exclui o repositório de origem e o fluxo de trabalho. # Criação com fluxos de trabalho Usando [CodeCatalyst fluxos de trabalho](workflow.md), você pode criar aplicativos e outros recursos. **Topics** + [ ## Como faço para criar uma aplicação? ](#build-how-to) + [ ## Benefícios da ação de criação ](#build-benefits) + [ ## Alternativas à ação de criação ](#build-alternatives) + [ # Adição da ação de criação ](build-add-action.md) + [ # Visualização dos resultados de uma ação de criação ](build-view-results.md) + [ # Tutorial: Fazer upload de artefatos no Amazon S3 ](build-deploy.md) + [ # Ações de criação e de teste YAML ](build-action-ref.md) ## Como faço para criar uma aplicação? Para criar um aplicativo ou recurso em CodeCatalyst, primeiro você cria um fluxo de trabalho e, em seguida, especifica uma ação de construção dentro dele. A *ação de criação* é um componente do fluxo de trabalho que compila seu código-fonte, executa testes de unidade e produz artefatos prontos para implantação. Você adiciona uma ação de criação ao seu fluxo de trabalho usando o editor visual do CodeCatalyst console ou o editor YAML. As etapas detalhadas para criar uma aplicação ou um recurso são as seguintes. **Como criar uma aplicação (tarefas detalhadas)** 1. Em CodeCatalyst, você **adiciona o código-fonte** de um aplicativo que deseja criar. Para obter mais informações, consulte [Armazenando o código-fonte em repositórios para um projeto no CodeCatalyst](source-repositories.md). 1. Em CodeCatalyst, você **cria um fluxo de trabalho**. No fluxo de trabalho, você define como criar, testar e implantar a aplicação. Para obter mais informações, consulte [Conceitos básicos de fluxos de trabalho](workflows-getting-started.md). 1. (Opcional) No fluxo de trabalho, você **adiciona um gatilho** que indica os eventos que farão com que o fluxo de trabalho seja iniciado automaticamente. Para obter mais informações, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). 1. No fluxo de trabalho, você adiciona uma **ação de criação** que compila e empacota o código-fonte da aplicação ou do recurso. Se desejar, você também poderá fazer com que a ação de criação execute testes de unidade, gere relatórios e implante a aplicação se você não quiser usar uma ação de teste ou de implantação para essas finalidades. Para ter mais informações sobre as ações de teste e de implantação, consulte [Adição da ação de criação](build-add-action.md). 1. (Opcional) No fluxo de trabalho, você **adiciona uma ação de teste** e uma **ação de implantação** para testar e implantar a aplicação ou o recurso. Você pode escolher entre várias ações pré-configuradas para implantar a aplicação em diferentes destinos, como o Amazon ECS. Para ter mais informações, consulte [Teste com fluxos de trabalhoTeste com fluxos de trabalho](test-workflow-actions.md) e [Implantar com fluxos de trabalhoImplantar com fluxos de trabalho](deploy.md). 1. Você **inicia o fluxo de trabalho** manual ou automaticamente por meio de um gatilho. O fluxo de trabalho executa as ações de criação, teste e implantação em sequência para criar, testar e implantar a aplicação e seus recursos no destino. Para obter mais informações, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md). ## Benefícios da ação de criação O uso da ação de criação em um fluxo de trabalho fornece os seguintes benefícios: + **Totalmente gerenciado**: a ação de criação elimina a necessidade de configurar, aplicar patches e atualizações e gerenciar os próprios servidores de compilação. + **Sob demanda**: a ação de criação escala sob demanda, para atender às necessidades da compilação. Você paga somente pela quantidade de minutos de compilação que consumir. Para obter mais informações, consulte [Configuração de imagens de computação e runtime](workflows-working-compute.md). + **Pronto para uso — CodeCatalyst inclui imagens Docker de** ambiente de tempo de execução pré-empacotadas que são usadas para executar todas as ações do seu fluxo de trabalho, incluindo ações de construção. Essas imagens vêm pré-configuradas com ferramentas úteis para criar aplicativos como o AWS CLI e o Node.js. Você pode configurar CodeCatalyst para usar uma imagem de compilação fornecida por você a partir de um registro público ou privado. Para obter mais informações, consulte [Especificação de imagens de ambiente de runtime](build-images.md). ## Alternativas à ação de criação Se você estiver usando uma ação de criação para implantar seu aplicativo, considere usar uma *ação de CodeCatalyst implantação* em vez disso. As ações de implantação realizam behind-the-scenes configurações que, de outra forma, você precisaria escrever manualmente se estivesse usando uma ação de compilação. Para ter mais informações sobre as ações de implantação disponíveis, consulte [Lista de ações de implantação](deploy.md#deploy-concepts-action-supported). Você também pode usar AWS CodeBuild para criar seus aplicativos. Para obter mais informações, consulte [O que é o CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html). # Adição da ação de criação Use o procedimento a seguir para adicionar uma ação de criação ao seu CodeCatalyst fluxo de trabalho. ------ #### [ Visual ] **Para adicionar uma ação de criação usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. Escolha **Ações**. 1. Em **Ações**, escolha **Criar**. 1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [Ações de criação e de teste YAML](build-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como adicionar uma ação de criação usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Escolha **Ações**. 1. Em **Ações**, escolha **Criar**. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [Ações de criação e de teste YAML](build-action-ref.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ ## Definição de ação de criação A ação de criação é definida como um conjunto de propriedades YAML dentro do arquivo de definição do fluxo de trabalho. Para ter mais informações sobre essas propriedades, consulte [Ações de criação e de teste YAML](build-action-ref.md) na [Definição do YAML do fluxo de trabalho](workflow-reference.md). # Visualização dos resultados de uma ação de criação Use as instruções a seguir para visualizar os resultados de uma ação de criação, incluindo os logs, relatórios e variáveis gerados. **Para visualizar os resultados de uma ação de criação** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. No diagrama do fluxo de trabalho, escolha o nome da ação de criação, por exemplo, **Compilação**. 1. Para ver os logs da execução da criação, selecione **Logs**. Os logs das várias fases de criação são exibidos. Você pode expandir ou recolher os logs conforme necessário. 1. Para visualizar os relatórios de teste produzidos pela ação de criação, selecione **Relatórios** ou, no painel de navegação, selecione **Relatórios**. Para obter mais informações, consulte [Tipos de relatório de qualidade](test-workflow-actions.md#test-reporting). 1. Para ver a configuração usada para a ação de criação, selecione **Configuração**. Para obter mais informações, consulte [Adição da ação de criação](build-add-action.md). 1. Para ver as variáveis usadas pela ação de criação, selecione **Variáveis**. Para obter mais informações, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). # Tutorial: Fazer upload de artefatos no Amazon S3 Neste tutorial, você aprende a fazer upload de artefatos em um bucket do Amazon S3 usando um fluxo de trabalho da CodeCatalyst [Amazon](workflows-concepts.md#workflows-concepts-workflows) que inclui algumas ações [de](workflows-concepts.md#workflows-concepts-actions) criação. Essas ações são executadas em série quando o fluxo de trabalho é iniciado. A primeira ação de criação gera dois arquivos, `Hello.txt` e `Goodbye.txt`, e os agrupa em um artefato de criação. A segunda ação de criação carrega o artefato no Amazon S3. Você configurará o fluxo de trabalho para ser executado sempre que enviar uma confirmação para o repositório de origem. **Topics** + [ ## Pré-requisitos ](#build-deploy-tut-prereqs) + [ ## Etapa 1: criar uma AWS função ](#build-deploy-tut-role) + [ ## Etapa 2: criar um bucket do Amazon S3 ](#build-deploy-tut-artifact) + [ ## Etapa 3: criar um repositório de origem ](#deploy-tut-lambda-cfn-source) + [ ## Etapa 4: criar um fluxo de trabalho ](#build-deploy-tut-workflow.title) + [ ## Etapa 5: verificar os resultados ](#build-deploy.s3.verify) + [ ## Limpeza ](#deploy-tut-lambda-cfn-clean-up) ## Pré-requisitos Antes de começar, você precisará fazer o seguinte: + Você precisa de um CodeCatalyst **espaço** com uma AWS conta conectada. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). + Em seu espaço, você precisa de um projeto vazio chamado: ``` codecatalyst-artifact-project ``` Use a opção **Começar do zero** para criar esse projeto. Para obter mais informações, consulte [Criando um projeto vazio na Amazon CodeCatalyst](projects-create.md#projects-create-empty). + Em seu projeto, você precisa de um CodeCatalyst **ambiente** chamado: ``` codecatalyst-artifact-environment ``` Configure esse ambiente da seguinte forma: + Escolha qualquer tipo, como **Desenvolvimento**. + Conecte sua AWS conta a ela. + Para o **Perfil do IAM padrão**, escolha qualquer perfil. Você especificará um perfil diferente posteriormente. Para obter mais informações, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md). ## Etapa 1: criar uma AWS função Nesta etapa, você cria uma função AWS do IAM que posteriormente atribuirá à ação de criação em seu fluxo de trabalho. Essa função concede à ação de CodeCatalyst construção permissão para acessar sua AWS conta e gravar no Amazon S3, onde seu artefato será armazenado. O perfil é chamado de **Perfil de criação**. **nota** Se você já tiver um perfil de criação para outro tutorial, também poderá usá-lo para este tutorial. Apenas garanta que ele tenha as permissões e a política de confiança mostradas no procedimento a seguir. Para obter mais informações sobre as funções do IAM, consulte [Funções do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) no *Guia AWS AWS Identity and Access Management do usuário*. **Como criar um perfil de criação** 1. Crie uma política para o perfil da seguinte maneira: 1. Faça login em AWS. 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação, selecione **Políticas**. 1. Escolha **Criar política**. 1. Escolha a guia **JSON**. 1. Exclua o código existente. 1. Cole o seguinte código: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:ListBucket" ], "Resource": "*" } ] } ``` ------ **nota** Na primeira vez em que o perfil for usado para executar ações de fluxo de trabalho, use o caractere curinga na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` 1. Escolha **Próximo: tags**. 1. Selecione **Próximo: revisar**. 1. Em **Nome**, insira: ``` codecatalyst-s3-build-policy ``` 1. Selecione **Criar política**. Agora você criou uma política de permissões. 1. Crie o perfil de criação, da seguinte forma: 1. No painel de navegação, escolha **Perfis** e **Criar perfil**. 1. Selecione **Política de confiança personalizada**. 1. Exclua a política de confiança personalizada existente. 1. Adicione a política de confiança personalizada a seguir: 1. Escolha **Próximo**. 1. Em **Políticas de permissões**, procure `codecatalyst-s3-build-policy` e marque a caixa de seleção. 1. Escolha **Próximo**. 1. Em **Nome do perfil**, insira: ``` codecatalyst-s3-build-role ``` 1. Em **Descrição do perfil**, insira: ``` CodeCatalyst build role ``` 1. Selecione **Criar perfil**. Agora você criou um perfil de criação com uma política de confiança e uma política de permissões. ## Etapa 2: criar um bucket do Amazon S3 Nesta etapa, você cria um bucket do Amazon S3 no qual os artefatos `Hello.txt` e `Goodbye.txt` serão carregados. **Como criar um bucket do Amazon S3** 1. Abra o console do Amazon S3 em [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. No painel principal, selecione **Criar bucket**. 1. Em **Nome do bucket**, insira: ``` codecatalyst-artifact-bucket ``` 1. Na **região da AWS **, escolha uma região. Este tutorial pressupõe que você tenha escolhido o **Oeste dos EUA (Oregon) us-west-2**. Para ter informações sobre regiões com suporte do Amazon S3, consulte [Endpoints e cotas do Amazon Simple Storage Service](https://docs.aws.amazon.com/general/latest/gr/s3.html) na *Referência geral da AWS*. 1. Selecione **Criar bucket** na parte inferior da página. 1. Copie o nome do bucket que você acabou de criar, por exemplo: ``` codecatalyst-artifact-bucket ``` Agora você criou um bucket chamado **codecatalyst-artifact-bucket** na região Oeste dos EUA (Oregon), us-west-2. ## Etapa 3: criar um repositório de origem Nesta etapa, você cria um repositório de origem no CodeCatalyst. Esse repositório é usado para armazenar o arquivo de definição do fluxo de trabalho do tutorial. Para ter mais informações sobre repositórios de origem, consulte [Criar um repositório de origem](source-repositories-create.md). **Como criar um repositório de origem** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Navegue até o projeto, `codecatalyst-artifact-project`. 1. No painel de navegação, selecione **Código** e, em seguida, selecione **Repositórios de origem**. 1. Escolha **Adicionar repositório** e selecione **Criar repositório**. 1. Em **Nome do repositório**, insira: ``` codecatalyst-artifact-source-repository ``` 1. Escolha **Criar**. Agora você criou um repositório chamado `codecatalyst-artifact-source-repository`. ## Etapa 4: criar um fluxo de trabalho Nesta etapa, você cria um fluxo de trabalho que consiste nos seguintes componentes que são executados sequencialmente: + Um gatilho – Esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + Uma ação de criação chamada `GenerateFiles` — No gatilho, a ação `GenerateFiles` cria dois arquivos, `Hello.txt` e `Goodbye.txt`, os empacota em um artefato de saída chamado `codecatalystArtifact`. + Outra ação de criação chamada `Upload` — Ao concluir a ação `GenerateFiles`, a ação `Upload` executa o comando da AWS CLI `aws s3 sync` para carregar os arquivos no `codecatalystArtifact` e no repositório de origem para o bucket do Amazon S3. AWS CLI Ele vem pré-instalado e pré-configurado na plataforma de CodeCatalyst computação, então você não precisa instalá-lo ou configurá-lo. Para obter mais informações sobre o software pré-empacotado na plataforma de CodeCatalyst computação, consulte. [Especificação de imagens de ambiente de runtime](build-images.md) Para obter mais informações sobre o `aws s3 sync` comando AWS CLI's, consulte [sync](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html) na *Referência de AWS CLI Comandos*. Para ter mais informações sobre a ação de criação, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). **Como criar um fluxo de trabalho** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho**. 1. Exclua o código de amostra YAML. 1. Adicione o seguinte código YAML: **nota** No código YAML a seguir, você pode omitir a seção `Connections:` se quiser. Se você omitir essa seção, deverá garantir que o perfil especificado no campo **Perfil do IAM padrão** em seu ambiente inclua as permissões e as políticas de confiança descritas em [Etapa 1: criar uma AWS função](#build-deploy-tut-role). Para ter mais informações sobre como configurar um ambiente com um perfil do IAM padrão, consulte [Criar um ambiente](deploy-environments-creating-environment.md). ``` Name: codecatalyst-artifact-workflow SchemaVersion: 1.0 Triggers: - Type: Push Branches: - main Actions: GenerateFiles: Identifier: aws/build@v1 Configuration: Steps: # Create the output files. - Run: echo "Hello, World!" > "Hello.txt" - Run: echo "Goodbye!" > "Goodbye.txt" Outputs: Artifacts: - Name: codecatalystArtifact Files: - "**/*" Upload: Identifier: aws/build@v1 DependsOn: - GenerateFiles Environment: Name: codecatalyst-artifact-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-s3-build-role Inputs: Artifacts: - codecatalystArtifact Configuration: Steps: # Upload the output artifact to the S3 bucket. - Run: aws s3 sync . s3://codecatalyst-artifact-bucket ``` No código acima, substitua: + *codecatalyst-artifact-environment*com o nome do ambiente em que você criou[Pré-requisitos](#build-deploy-tut-prereqs). + *codecatalyst-account-connection*com o nome da conexão da conta que você criou[Pré-requisitos](#build-deploy-tut-prereqs). + *codecatalyst-s3-build-role* pelo nome do perfil de criação criado em [Etapa 1: criar uma AWS função](#build-deploy-tut-role). + *codecatalyst-artifact-bucket*com o nome do Amazon S3 em que você criou. [Etapa 2: criar um bucket do Amazon S3](#build-deploy-tut-artifact) Para ter informações sobre as propriedades nesse arquivo, consulte a [Ações de criação e de teste YAML](build-action-ref.md). 1. (Opcional) Selecione **Validar** para garantir que o código YAML seja válido antes de confirmar. 1. Selecione **Confirmar**. 1. Na caixa de diálogo **Confirmar fluxo de trabalho**, insira o seguinte: 1. Em **Nome do arquivo do fluxo de trabalho**, deixe o padrão, `codecatalyst-artifact-workflow`. 1. Em **Confirmar mensagem**, insira: ``` add initial workflow file ``` 1. Em **Repositório**, selecione **codecatalyst-artifact-source-repository**. 1. Em **Nome da ramificação**, selecione **principal**. 1. Selecione **Confirmar**. Agora você criou um fluxo de trabalho. A execução de um fluxo de trabalho é iniciada automaticamente devido ao gatilho definido na parte superior do fluxo de trabalho. Especificamente, quando você confirmou (e enviou) o arquivo `codecatalyst-artifact-workflow.yaml` ao repositório de origem, o gatilho iniciou a execução do fluxo de trabalho. **Para visualizar a execução do fluxo de trabalho em andamento** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha o fluxo de trabalho que você acabou de criar: `codecatalyst-artifact-workflow`. 1. Escolha **GenerateFiles**ver o progresso da primeira ação de construção. 1. Selecione **Carregar** para ver o progresso da segunda ação de criação. 1. Quando a ação **Carregar** terminar, faça o seguinte: + Se a execução do fluxo de trabalho for bem-sucedida, vá para o próximo procedimento. + Se a execução do fluxo de trabalho falhar, selecione **Logs** para solucionar o problema. ## Etapa 5: verificar os resultados Depois que o fluxo de trabalho for executado, acesse o serviço Amazon S3 e examine seu *codecatalyst-artifact-bucket* bucket. Agora ele deve incluir os seguintes arquivos e pastas: ``` . |— .aws/ |— .git/ |Goodbye.txt |Hello.txt |REAME.md ``` Os arquivos `Goodbye.txt` e `Hello.txt` foram enviados porque faziam parte do artefato `codecatalystArtifact`. Os arquivos `.aws/`, `.git/` e `README.md` foram enviados porque estavam no repositório de origem. ## Limpeza Limpe CodeCatalyst e evite AWS ser cobrado por esses serviços. **Para limpar CodeCatalyst** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Exclua o repositório de origem `codecatalyst-artifact-source-repository`. 1. Exclua o fluxo de trabalho `codecatalyst-artifact-workflow`. **Para limpar AWS** 1. Limpe no Amazon S3, da seguinte forma: 1. Abra o console do Amazon S3 em [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Exclua os arquivos no bucket `codecatalyst-artifact-bucket`. 1. Exclua o bucket `codecatalyst-artifact-bucket`. 1. Limpe no IAM, da seguinte forma: 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Exclua o `codecatalyst-s3-build-policy`. 1. Exclua o `codecatalyst-s3-build-role`. # Ações de criação e de teste YAML Veja a seguir a definição YAML das ações de criação e de teste. Há uma referência para duas ações porque as propriedades YAML de cada uma são muito semelhantes. Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). Escolha uma propriedade YAML no código a seguir para ver uma descrição dela. **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. action-name: Identifier: aws/build@v1 | aws/managed-test@v1 DependsOn: - dependent-action-name-1 Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Caching: FileCaching: key-name-1: Path: file1.txt RestoreKeys: - restore-key-1 Inputs: Sources: - source-name-1 - source-name-2 Artifacts: - artifact-name Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Outputs: Artifacts: - Name: output-artifact-1 Files: - build-output/artifact-1.jar - "build-output/build*" - Name: output-artifact-2 Files: - build-output/artifact-2.1.jar - build-output/artifact-2.2.jar Variables: - variable-name-1 - variable-name-2 AutoDiscoverReports: Enabled: true | false ReportNamePrefix: AutoDiscovered IncludePaths: - "**/*" ExcludePaths: - node_modules/cdk/junit.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisBug: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisSecurity: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisQuality: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisFinding: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number Reports: report-name-1: Format: format IncludePaths: - "*.xml" ExcludePaths: - report2.xml - report3.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisBug: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisSecurity: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisQuality: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisFinding: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number Configuration: Container: Registry: registry Image: image Steps: - Run: "step 1" - Run: "step 2" Packages: NpmConfiguration: PackageRegistries: - PackagesRepository: package-repository Scopes: - "@scope" ExportAuthorizationToken: true | false ``` ## action-name (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Interface de usuário correspondente: guia Configuração/**Nome da ação** ## Identifier (*action-name*/**Identifier**) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Use `aws/build@v1` para ações de criação. Use `aws/managed-test@v1` para ações de teste. UI correspondente: diagrama de fluxo de trabalho/nome da *aws/build@v1\$1aws/managed-test@v1* ação/rótulo ## DependsOn (*action-name*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*action-name*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*action-name*/Compute/**Tipo**) (Obrigatório se [Compute](#build.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2** (editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). Interface de usuário correspondente: guia Configuração/**Tipo de computação** ## Fleet (*action-name*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. Interface de usuário correspondente: guia Configuração/**Frota de computação** ## Timeout (*action-name*/**Timeout**) (Optional) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Environment (*action-name*/**Environment**) (Optional) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*action-name*/Environment/**Name**) (Optional) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*action-name*/Environment/**Connections**) (Optional) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). UI correspondente: a configuração tab/Environment/What está pronta*my-environment*? **/menu de três pontos/ Mudar função** ## Name (*action-name*/Environment/Connections/**Name**) (Obrigatório se [Connections](#build.environment.connections) for incluído) Especifique o nome da conexão da conta. UI correspondente: a configuração tab/Environment/What está pronta*my-environment*? **/menu de três pontos/ Mudar função** ## Role (*action-name*/Environment/Connections/**Role**) (Obrigatório se [Connections](#build.environment.connections) for incluído) Especifique o nome do perfil do IAM que essa ação usa para acessar e operar em serviços da AWS , como o Amazon S3 e o Amazon ECR. Esse perfil deve ser adicionado à conexão da Conta da AWS no espaço. Para adicionar um perfil do IAM a uma conexão de conta, consulte [Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas a seguir. **nota** É possível usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação. Para obter mais informações sobre esse perfil, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. **Atenção** Limite as permissões às exigidas pelas ações de criação e de teste. Usar um perfil com permissões mais amplas pode representar um risco de segurança. UI correspondente: a configuração tab/Environment/What está pronta*my-environment*? **/menu de três pontos/ Mudar função** ## Caching (*action-name*/**Caching**) (Optional) Uma seção na qual você pode especificar um cache para salvar arquivos em disco e restaurá-los desse cache em execuções subsequentes do fluxo de trabalho. Para ter mais informações sobre armazenamento de arquivos em cache, consulte [Armazenar arquivos em cache entre execuções de fluxo de trabalho](workflows-caching.md). Interface de usuário correspondente: guia Configuração/**Armazenamento de arquivos em cache - opcional** ## FileCaching (*action-name*/Caching/**FileCaching**) (Optional) Uma seção que especifica a configuração de uma sequência de caches. **UI correspondente: tab/File Cache de configuração - opcional/Adicionar cache** ## key-name-1 (*action-name*/Caching/FileCaching/***key-name-1***) (Optional) Especifique o nome da propriedade de cache principal. Os nomes de propriedade de cache devem ser exclusivos no fluxo de trabalho. Cada ação pode ter até cinco entradas em `FileCaching`. **UI correspondente: tab/File Cache de configuração - opcional/Adicionar cache/chave** ## Path (*action-name*/Caching/FileCaching/*key-name-1*/**Path**) (Optional) Especifique o caminho associado ao cache. **UI correspondente: tab/File Cache de configuração - opcional/Adicionar cache/caminho** ## RestoreKeys (*action-name*/Caching/FileCaching/*key-name-1*/**RestoreKeys**) (Optional) Especifique a chave de restauração a ser usada como fallback quando a propriedade do cache principal não puder ser encontrada. Os nomes de chave de restauração devem ser exclusivos no fluxo de trabalho. Cada cache pode ter até cinco entradas em `RestoreKeys`. **UI correspondente: tab/File Cache de configuração - opcional/Adicionar cache/Restaurar chaves - opcional** ## Inputs (*action-name*/**Inputs**) (Optional) A seção `Inputs` define os dados de que uma ação precisa durante a execução de um fluxo de trabalho. **nota** São permitidas no máximo quatro entradas (uma origem e três artefatos) por ação de criação ou de teste. As variáveis não são contadas nesse total. Se você precisar consultar arquivos que residem em entradas diferentes (digamos, uma origem e um artefato), a entrada de origem será a entrada primária e o artefato será a entrada secundária. As referências a arquivos em entradas secundárias usam um prefixo especial para diferirem das primárias. Para obter detalhes, consulte [Exemplo: referência de arquivos em vários artefatos](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file). Interface de usuário correspondente: guia **Entradas** ## Sources (*action-name*/Inputs/**Sources**) (Optional) Especifique os rótulos que representam os repositórios de origem que serão necessários para a ação. Atualmente, o único rótulo compatível é `WorkflowSource`, que representa o repositório de origem em que o arquivo de definição de fluxo de trabalho está armazenado. Se você omitir uma origem, deverá especificar pelo menos um artefato de entrada em `action-name/Inputs/Artifacts`. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: *nenhuma* ## Artifacts - input (*action-name*/Inputs/**Artifacts**) (Optional) Especifique artefatos de ações anteriores que você deseja fornecer como entrada para essa ação. Esses artefatos já devem estar definidos como artefatos de saída em ações anteriores. Se você não especificar nenhum artefato de entrada, deverá especificar pelo menos um repositório de origem em `action-name/Inputs/Sources`. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **nota** Se a lista suspensa **Artefatos – opcional** não estiver disponível (editor visual) ou se você receber erros ao validar o YAML (editor YAML), talvez seja porque a ação permite apenas uma entrada. Nesse caso, tente remover a entrada de origem. Interface de usuário correspondente: guia Entradas/**Artefatos - opcional** ## Variables - input (*action-name*/Inputs/**Variables**) (Optional) Especifique uma sequência de name/value pares que defina as variáveis de entrada que você deseja disponibilizar para a ação. Os nomes de variável são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de variável. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Interface de usuário correspondente: guia Entradas/**Variáveis - opcional** ## Outputs (*action-name*/**Outputs**) (Optional) Define os dados que são gerados pela ação durante a execução de um fluxo de trabalho. Interface de usuário correspondente: guia **Saídas** ## Artifacts - output (*action-name*/Outputs/**Artifacts**) (Optional) Especifique o nome de um artefato gerado pela ação. Os nomes de artefato devem ser exclusivos em um fluxo de trabalho e estão limitados a caracteres alfanuméricos (a-z, A-Z, 0-9) e sublinhados (\$1). Espaços, hifens (-) e outros caracteres especiais não são permitidos. Não é possível usar aspas para habilitar espaços, hifens e outros caracteres especiais em nomes de artefato de saída. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Saídas/**Artefatos** ## Name (*action-name*/Outputs/Artifacts/**Name**) (Obrigatório se [Artifacts - output](#build.outputs.artifacts) for incluído) Especifique o nome de um artefato gerado pela ação. Os nomes de artefato devem ser exclusivos em um fluxo de trabalho e estão limitados a caracteres alfanuméricos (a-z, A-Z, 0-9) e sublinhados (\$1). Espaços, hifens (-) e outros caracteres especiais não são permitidos. Não é possível usar aspas para habilitar espaços, hifens e outros caracteres especiais em nomes de artefato de saída. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **UI correspondente: tab/Artifacts/New Saídas, saída/nome do artefato de construção** ## Files (*action-name*/Outputs/Artifacts/**Files**) (Obrigatório se [Artifacts - output](#build.outputs.artifacts) for incluído) Especifique os arquivos CodeCatalyst incluídos no artefato gerado pela ação. Esses arquivos são gerados pela ação do fluxo de trabalho quando ela é executada e também estão disponíveis no repositório de origem. Os caminhos de arquivo podem residir em um repositório de origem ou em um artefato de uma ação anterior e são relativos ao repositório de origem ou à raiz do artefato. É possível usar padrões glob para especificar caminhos. Exemplos: + Para especificar um único arquivo que esteja na raiz do local de compilação ou do local do repositório de origem, use `my-file.jar`. + Para especificar um único arquivo em um subdiretório, use `directory/my-file.jar` ou `directory/subdirectory/my-file.jar`. + Para especificar todos os arquivos, use `"**/*"`. O padrão glob `**` indica que corresponde a qualquer número de subdiretórios. + Para especificar todos os arquivos e diretórios em um diretório chamado `directory`, use `"directory/**/*"`. O padrão glob `**` indica que corresponde a qualquer número de subdiretórios. + Para especificar todos os arquivos em um diretório chamado `directory`, mas não em nenhum de seus subdiretórios, use `"directory/*"`. **nota** Se o caminho do arquivo incluir um ou mais asteriscos (`*`) ou outro caractere especial, coloque o caminho entre aspas duplas (`""`). Para ter mais informações sobre caracteres especiais, consulte [Diretrizes e convenções de sintaxe](workflow-reference.md#workflow.terms.syntax.conv). Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **nota** Talvez seja necessário adicionar um prefixo ao caminho do arquivo para indicar em qual artefato ou origem encontrá-lo. Para obter mais informações, consulte [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md) e [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). UI correspondente: tab/Artifacts/New saídas de **saída/arquivos** produzidos pela compilação ## Variables - output (*action-name*/Outputs/**Variables**) (Optional) Especifique as variáveis que você deseja que a ação exporte para que estejam disponíveis para uso em ações subsequentes. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Interface de usuário correspondente: guia Saídas/Variáveis/**Adicionar variável** ## variable-name-1 (*action-name*/Outputs/Variables/*variable-name-1*) (Optional) Especifique o nome de uma variável a ser exportada pela ação. Essa variável já deve estar definida na seção `Inputs` ou `Steps` da mesma ação. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **UI correspondente: tab/Variables/Add Variável de saída/nome** ## AutoDiscoverReports (*action-name*/Outputs/**AutoDiscoverReports**) (Optional) Define a configuração do recurso de descoberta automática. Quando você ativa a descoberta automática, CodeCatalyst pesquisa todos os dados `Inputs` passados para a ação, bem como todos os arquivos gerados pela própria ação, procurando relatórios de teste, cobertura de código e análise de composição de software (SCA). Para cada relatório encontrado, CodeCatalyst transforma-o em um CodeCatalyst relatório. Um *CodeCatalyst relatório* é um relatório totalmente integrado ao CodeCatalyst serviço e que pode ser visualizado e manipulado por meio do CodeCatalyst console. **nota** Por padrão, o recurso de descoberta automática inspeciona todos os arquivos. É possível limitar quais arquivos são inspecionados usando as propriedades [IncludePaths](#build.reports.includepaths) ou [ExcludePaths](#build.reports.excludepaths). Interface de usuário correspondente: guia Saídas/Relatórios/**Relatórios de descoberta automática** ## Enabled (*action-name*/Outputs/AutoDiscoverReports/**Enabled**) (Optional) Habilite ou desabilite o recurso de descoberta automática. Os valores válidos são `true` ou `false`. Se `Enabled` for omitido, o padrão será `true`. Interface de usuário correspondente: guia Saídas/Relatórios/**Relatórios de descoberta automática** ## ReportNamePrefix (*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**) (Obrigatório se [AutoDiscoverReports](#build.outputs.autodiscover) estiver incluído e habilitado) Especifique um prefixo que seja CodeCatalyst anexado a todos os relatórios encontrados para nomear seus relatórios associados. CodeCatalyst Por exemplo, se você especificar um prefixo de`AutoDiscovered`, e CodeCatalyst descobrir automaticamente dois relatórios de teste, `TestSuiteOne.xml` e`TestSuiteTwo.xml`, os CodeCatalyst relatórios associados serão nomeados e. `AutoDiscoveredTestSuiteOne` `AutoDiscoveredTestSuiteTwo` Interface de usuário correspondente: guia Saídas/Relatórios/**Nome do prefixo** ## IncludePaths (*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**) Ou (*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**) (Obrigatório se [AutoDiscoverReports](#build.outputs.autodiscover) estiver incluído e habilitado ou se [Reports](#test.configuration.reports) estiver incluído) Especifique os arquivos e os caminhos de arquivo CodeCatalyst incluídos na pesquisa de relatórios brutos. Por exemplo, se você especificar`"/test/report/*"`, CodeCatalyst pesquisa toda a [imagem de compilação](build-images.md) usada pela ação procurando o `/test/report/*` diretório. Quando encontra esse diretório CodeCatalyst , procura relatórios nesse diretório. **nota** Se o caminho do arquivo incluir um ou mais asteriscos (`*`) ou outros caracteres especiais, coloque o caminho entre aspas duplas (`""`). Para ter mais informações sobre caracteres especiais, consulte [Diretrizes e convenções de sintaxe](workflow-reference.md#workflow.terms.syntax.conv). Se essa propriedade for omitida, o padrão será `"**/*"`, o que significa que a pesquisa inclui todos os arquivos em todos os caminhos. **nota** Em relatórios configurados manualmente, `IncludePaths` deverá ser um padrão global que corresponda a um único arquivo. Interface de usuário correspondente: + **Caminhos de tab/Reports/Auto-discover reports/Include/exclude saída/ Caminhos de inclusão** + **Saídas tab/Reports/Manually configuram relatórios/ /incluir/excluir *report-name-1* caminhos/ Incluir caminhos** ## ExcludePaths (*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**) Ou (*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**) (Optional) Especifique os arquivos e os caminhos de arquivo que são CodeCatalyst excluídos ao pesquisar relatórios brutos. Por exemplo, se você especificar`"/test/my-reports/**/*"`, não CodeCatalyst procurará arquivos no `/test/my-reports/` diretório. Para ignorar todos os arquivos em um diretório, use o padrão de glob `**/*`. **nota** Se o caminho do arquivo incluir um ou mais asteriscos (`*`) ou outros caracteres especiais, coloque o caminho entre aspas duplas (`""`). Para ter mais informações sobre caracteres especiais, consulte [Diretrizes e convenções de sintaxe](workflow-reference.md#workflow.terms.syntax.conv). Interface de usuário correspondente: + **Caminhos de tab/Reports/Auto-discover reports/Include/exclude saída/ caminhos de exclusão** + **As saídas tab/Reports/Manually configuram relatórios/ /incluir/excluir *report-name-1* caminhos/ Excluir caminhos** ## SuccessCriteria (*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**) Ou (*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**) (Optional) Especifique os critérios de sucesso para os relatórios de teste, cobertura de código, análise de composição de software (SCA) e análise estática (SA). Para obter mais informações, consulte [Configuração de critérios de sucesso para relatórios](test-config-action.md#test.success-criteria). Interface de usuário correspondente: guia Saída/Relatórios/**Critérios de sucesso** ## PassRate (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**) (Optional) Especifique a porcentagem de testes em um relatório de teste que devem ser aprovados para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de taxa de aprovação são aplicados somente aos relatórios de teste. Para ter mais informações sobre os relatórios de teste, consulte [Relatórios de teste](test-workflow-actions.md#test-reports). **UI correspondente: tab/Reports/Success critérios de saída/taxa de aprovação** ## LineCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**) (Optional) Especifique a porcentagem de linhas em um relatório de cobertura de código que devem ser cobertas para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de cobertura de linha são aplicados somente aos relatórios de cobertura de código. Para ter mais informações sobre relatórios de cobertura de código, consulte [Relatórios de cobertura de código](test-workflow-actions.md#test-code-coverage-reports). **UI correspondente: tab/Reports/Success critérios de saída/cobertura de linha** ## BranchCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**) (Optional) Especifique a porcentagem de filiais em um relatório de cobertura de código que devem ser cobertas para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de cobertura de ramificações são aplicados somente aos relatórios de cobertura de código. Para ter mais informações sobre relatórios de cobertura de código, consulte [Relatórios de cobertura de código](test-workflow-actions.md#test-code-coverage-reports). **UI correspondente: tab/Reports/Success critérios de saída/cobertura da filial** ## Vulnerabilities (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**) (Optional) Especifique o número máximo e a gravidade das vulnerabilidades permitidas no relatório SCA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar vulnerabilidades, é necessário especificar: + A gravidade mínima das vulnerabilidades que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, as vulnerabilidades `HIGH` e `CRITICAL` serão contabilizadas. + O número máximo de vulnerabilidades da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de vulnerabilidade são aplicados somente aos relatórios de SCA. Para ter mais informações sobre os relatórios de SCA, consulte [Relatórios de análise de composição de software](test-workflow-actions.md#test-sca-reports). Para especificar a gravidade mínima, use a propriedade `Severity`. Para especificar o número máximo de vulnerabilidades, use a propriedade `Number`. **UI correspondente: tab/Reports/Success critérios de saída/vulnerabilidades** ## StaticAnalysisBug (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisBug**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisBug**) (Optional) Especifique o número máximo e a gravidade dos bugs permitidos no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar bugs, é necessário especificar: + A gravidade mínima dos bugs que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, os bugs `HIGH` e `CRITICAL` serão contabilizados. + O número máximo de bugs da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de bugs são aplicados somente PyLint aos relatórios do ESLint SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports). Para especificar a gravidade mínima, use a propriedade `Severity`. Para especificar o número máximo de vulnerabilidades, use a propriedade `Number`. **UI correspondente: tab/Reports/Success critérios de saída/bugs** ## StaticAnalysisSecurity (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisSecurity**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisSecurity**) (Optional) Especifique o número máximo e a gravidade das vulnerabilidades de segurança permitidas no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar vulnerabilidades de segurança, é necessário especificar: + A gravidade mínima das vulnerabilidades de segurança que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, as vulnerabilidades de segurança `HIGH` e `CRITICAL` serão contabilizadas. + O número máximo de vulnerabilidades de segurança da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de vulnerabilidades de segurança são aplicados somente aos PyLint relatórios do ESLint SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports). Para especificar a gravidade mínima, use a propriedade `Severity`. Para especificar o número máximo de vulnerabilidades, use a propriedade `Number`. **UI correspondente: tab/Reports/Success critérios de saída/vulnerabilidades de segurança** ## StaticAnalysisQuality (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisQuality**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisQuality**) (Optional) Especifique o número máximo e a gravidade dos problemas de qualidade permitidos no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar problemas de qualidade, é necessário especificar: + A gravidade mínima dos problemas de qualidade que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, os problemas de qualidade `HIGH` e `CRITICAL` serão contabilizados. + O número máximo de problemas de qualidade da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de problemas de qualidade são aplicados somente PyLint aos relatórios ESLint da SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports). Para especificar a gravidade mínima, use a propriedade `Severity`. Para especificar o número máximo de vulnerabilidades, use a propriedade `Number`. **UI correspondente: tab/Reports/Success critérios de saída/problemas de qualidade** ## StaticAnalysisFinding (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisFinding**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisFinding**) (Optional) Especifique o número máximo e a severidade das descobertas permitidas no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar descobertas, é necessário especificar: + A gravidade mínima das descobertas que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, as descobertas `HIGH` e `CRITICAL` serão contabilizadas. + O número máximo de descobertas da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. As descobertas são aplicadas somente aos relatórios de SARIF SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports). Para especificar a gravidade mínima, use a propriedade `Severity`. Para especificar o número máximo de vulnerabilidades, use a propriedade `Number`. **UI correspondente: tab/Reports/Success critérios de saída/descobertas** ## Reports (*action-name*/Outputs/**Reports** ) (Optional) Uma seção que especifica a configuração dos relatórios de teste. Interface de usuário correspondente: guia Saídas/**Relatórios** ## report-name-1 (nome do *action-name* /Outputs/Reports/ **relatório-1)** (Obrigatório se [Reports](#test.configuration.reports) for incluído) O nome que você deseja dar ao CodeCatalyst relatório que será gerado a partir de seus relatórios brutos. **UI correspondente: saídas tab/Reports/Manually configuram relatórios/nome do relatório** ## Format (*action-name*/Outputs/Reports/*report-name-1*/**Format**) (Obrigatório se [Reports](#test.configuration.reports) for incluído) Especifique o formato de arquivo utilizado para os relatórios. Veja a seguir os valores possíveis. + Para relatórios de teste: + Para Cucumber JSON, especifique **Cucumber** (editor visual) ou `CUCUMBERJSON` (editor YAML). + Para JUnit XML, especifique **JUnit**(editor visual) ou `JUNITXML` (editor YAML). + Para NUnit XML, especifique **NUnit**(editor visual) ou `NUNITXML` (editor YAML). + Para NUnit 3 XML, especifique **NUnit3**(editor visual) ou `NUNIT3XML` (editor YAML). + Para Visual Studio TRX, especifique **Visual Studio TRX** (editor visual) ou `VISUALSTUDIOTRX` (editor YAML). + Para TestNG XML, especifique **TestNG** (editor visual) ou `TESTNGXML` (editor YAML). + Para relatórios de cobertura de código: + Para Clover XML, especifique **Clover** (editor visual) ou `CLOVERXML` (editor YAML). + Para Cobertura XML, especifique **Cobertura** (editor visual) ou `COBERTURAXML` (editor YAML). + Para JaCoCo XML, especifique **JaCoCo**(editor visual) ou `JACOCOXML` (editor YAML). + Para SimpleCov JSON gerado por [simplecov, não [simplecov-json](https://github.com/vicentllongo/simplecov-json)](https://github.com/simplecov-ruby/simplecov), especifique Simplecov (editor visual) ou (**editor YAML**). `SIMPLECOV` + Para relatórios de análise de composição de software (SCA): + Para SARIF, especifique **SARIF** (editor visual) ou `SARIFSCA` (editor YAML). **UI correspondente: tab/Reports/Manually configure reports/Add/configure relatórios de saídas/*report-name-1*/**Tipo de relatório e formato do relatório**** ## Configuration (*action-name*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## Container (*action-name*/Configuration/**Container**) (Optional) Especifique a imagem do Docker, ou *contêiner*, que a ação usa para concluir o processamento. Você pode especificar uma das [imagens ativas](build-images.md#build-curated-images) que vêm com CodeCatalyst ela ou usar sua própria imagem. Se você optar por usar a própria imagem, ela poderá residir no Amazon ECR, no Docker Hub ou em outro registro. Se você não especificar uma imagem do Docker, a ação usará uma das imagens ativas para processamento. Para ter informações sobre qual imagem ativa é usada por padrão, consulte [Imagens ativas](build-images.md#build-curated-images). Para ter mais informações sobre como especificar a própria imagem do Docker, consulte [Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação](build-images.md#build-images-specify). Interface de usuário correspondente: **Imagem do Docker do runtime - opcional** ## Registry (*action-name*/Configuration/Container/**Registry**) (Obrigatório se `Container` for incluído) Especifique o registro em que a imagem está armazenada. Os valores válidos são: + `CODECATALYST` (editor YAML) A imagem é armazenada no CodeCatalyst registro. + **Docker Hub** (editor visual) ou `DockerHub` (editor YAML) A imagem é armazenada no registro de imagens do Docker Hub. + **Outro registro** (editor visual) ou `Other` (editor YAML) A imagem é armazenada em um registro de imagem personalizado. Qualquer registro disponível publicamente pode ser usado. + **Amazon Elastic Container Registry** (editor visual) ou `ECR` (editor YAML) A imagem é armazenada em um repositório de imagens do Amazon Elastic Container Registry. Para usar uma imagem em um repositório do Amazon ECR, essa ação precisa acessar o Amazon ECR. Para habilitar esse acesso, é necessário criar um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que inclua as permissões e a política de confiança personalizada a seguir. (Se desejar, você poderá modificar um perfil existente para incluir as permissões e a política.) O perfil do IAM deve incluir as seguintes permissões na política: + `ecr:BatchCheckLayerAvailability` + `ecr:BatchGetImage` + `ecr:GetAuthorizationToken` + `ecr:GetDownloadUrlForLayer` O perfil do IAM deve incluir a seguinte política de confiança personalizada: Para ter mais informações sobre como criar perfis do IAM, consulte [Criar um perfil usando políticas de confiança personalizadas (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) no *Guia do usuário do IAM*. Depois que você criar o perfil, deverá atribuí-lo à ação por meio de um ambiente. Para obter mais informações, consulte [Associação de um ambiente a uma ação](deploy-environments-add-app-to-environment.md). Interface de usuário correspondente: opções **Amazon Elastic Container Registry**, **Docker Hub** e **Outro registro** ## Image (*action-name*/Configuration/Container/**Image**) (Obrigatório se `Container` for incluído) Especifique um dos seguintes: + Se você estiver usando um registro `CODECATALYST`, defina a imagem como uma das seguintes [imagens ativas](build-images.md#build-curated-images): + `CodeCatalystLinux_x86_64:2024_03` + `CodeCatalystLinux_x86_64:2022_11` + `CodeCatalystLinux_Arm64:2024_03` + `CodeCatalystLinux_Arm64:2022_11` + `CodeCatalystLinuxLambda_x86_64:2024_03` + `CodeCatalystLinuxLambda_x86_64:2022_11` + `CodeCatalystLinuxLambda_Arm64:2024_03` + `CodeCatalystLinuxLambda_Arm64:2022_11` + `CodeCatalystWindows_x86_64:2022_11` + Se você estiver usando um registro do Docker Hub, defina a imagem como o nome da imagem do Docker Hub e a tag opcional. Exemplo: `postgres:latest` + Se estiver usando um registro do Amazon ECR, defina a imagem como o URI do registro do Amazon ECR. Exemplo: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo` + Se estiver usando um registro personalizado, defina a imagem como o valor esperado pelo registro personalizado. Interface de usuário correspondente: **imagem do Docker do ambiente de runtime** (se o registro for `CODECATALYST`), **imagem do Docker Hub** (se o registro for **Docker Hub**), **URL da imagem do ECR** (se o registro for **Amazon Elastic Container Registry**) e **URL da imagem** (se o registro for **Outro registro**). ## Steps (*action-name*/Configuration/**Steps**) (Obrigatório) Especifique os comandos do shell que você deseja executar durante a ação para instalar, configurar e executar as ferramentas de compilação. Confira um exemplo de como criar um projeto npm: ``` Steps: - Run: npm install - Run: npm run build ``` Veja a seguir um exemplo de como especificar caminhos de arquivo: ``` Steps: - Run: cd $ACTION_BUILD_SOURCE_PATH_WorkflowSource/app && cat file2.txt - Run: cd $ACTION_BUILD_SOURCE_PATH_MyBuildArtifact/build-output/ && cat file.txt ``` Para ter mais informações sobre como especificar caminhos de arquivo, consulte [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md) e [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). Interface de usuário correspondente: guia Configuração/**Comandos de shell** ## Packages (*action-name*/Configuration/**Packages**) (Optional) Uma seção na qual você pode especificar um repositório de pacotes que a ação usa para resolver dependências. Os pacotes permitem que você armazene e compartilhe com segurança pacotes de software usados para desenvolvimento de aplicações. Para ter mais informações sobre pacotes, consulte [Publique e compartilhe pacotes de software no CodeCatalyst](packages.md). Interface de usuário correspondente: guia Configuração/**Pacotes** ## NpmConfiguration (*action-name*/Configuration/Packages/**NpmConfiguration**) (Obrigatório se [Packages](#build.configuration.packages) for incluído) Uma seção que define a configuração para o formato do pacote npm. Essa configuração é usada por uma ação durante a execução de um fluxo de trabalho. Para ter mais informações sobre a configuração do pacote npm, consulte [Uso de npm](packages-npm.md). **UI correspondente: configuração de tab/Packages/Add configuração/npm** ## PackageRegistries (*action-name*/Configuration/Packages/NpmConfiguration/**PackageRegistries**) (Obrigatório se [Packages](#build.configuration.packages) for incluído) Uma seção na qual você pode definir as propriedades de configuração de uma sequência de repositórios de pacotes. UI correspondente: tab/Packages/Add configuration/npm Configuração/ **Adicionar repositório de pacotes** ## PackagesRepository (*action-name*/Configuration/Packages/NpmConfiguration/PackageRegistries/**PackagesRepository**) (Obrigatório se [Packages](#build.configuration.packages) for incluído) Especifique o nome do *repositório de CodeCatalyst pacotes* que você deseja que a ação use. Se você especificar vários repositórios padrão, o último repositório terá prioridade. Para ter mais informações sobre repositórios de pacote, consulte [Repositórios de pacotes](packages-concepts.md#packages-concepts-repository). **UI correspondente: repositório de tab/Packages/Add configuration/npm/Add pacotes de configuração/repositório de pacotes** ## Scopes (*action-name*/Configuration/Packages/NpmConfiguration/PackageRegistries/**Scopes**) (Optional) Especifique uma sequência de *escopos* que você deseja definir no registro do pacote. Na definição de escopos, o repositório de pacotes especificado é configurado como o registro para todos os escopos listados. Se um pacote com o escopo for solicitado por meio do cliente npm, ele usará esse repositório em vez do padrão. Cada nome de escopo deve ter o prefixo “@”. Se você incluir escopos substitutos, o último repositório terá prioridade. Se `Scopes` for omitido, o repositório de pacotes especificado será configurado como o registro padrão para todos os pacotes usados pela ação. Para ter mais informações sobre escopos, consulte [Namespaces de pacote](packages-concepts.md#packages-concepts-package-namespaces) e [Pacotes com escopo definido](https://docs.npmjs.com/cli/v10/using-npm/scope). **UI correspondente: tab/Packages/Add configuration/npm/Add repositório/escopos do pacote de configuração - opcional** ## ExportAuthorizationToken (*action-name*/Configuration/Packages/**ExportAuthorizationToken**) (Optional) Habilite ou desabilite o recurso de token de autorização de exportação. Se habilitados, os tokens de autorização exportados podem ser usados para configurar manualmente um gerenciador de pacotes para se autenticar com repositórios de CodeCatalyst pacotes. É possível usar o token como uma variável de ambiente que pode ser referida nas ações. Os valores válidos são `true` ou `false`. Se `ExportAuthorizationToken` for omitido, o padrão será `false`. Para ter mais informações sobre o token de autorização de exportação, consulte [Usar tokens de autorização em ações de fluxo de trabalho](workflows-package-export-token.md). Interface de usuário correspondente: guia Configuração/Pacotes/**Token de autorização de exportação** # Teste com fluxos de trabalho Em CodeCatalyst, você pode executar testes como parte de diferentes ações do fluxo de trabalho, como criar e testar. Todas essas ações de fluxo de trabalho podem gerar relatórios de qualidade. Uma *ação de teste* é uma ação de fluxo de trabalho que produz relatórios de teste, cobertura de código, análise de composição de software e análise estática. Esses relatórios são exibidos no CodeCatalyst console. **Topics** + [ ## Tipos de relatório de qualidade ](#test-reporting) + [ # Adição da ação de teste ](test-add-action.md) + [ # Visualização dos resultados de uma ação de teste ](test-view-results.md) + [ # Omissão dos testes com falha em uma ação ](test.error-handling.md) + [ # Integrando com universal-test-runner ](test.universal-test-runner.md) + [ # Configuração de relatórios de qualidade em uma ação ](test-config-action.md) + [ # Melhores práticas de teste ](test-best-practices.md) + [ # Propriedades SARIF compatíveis ](test.sarif.md) ## Tipos de relatório de qualidade A ação CodeCatalyst de teste da Amazon oferece suporte aos seguintes tipos de relatórios de qualidade. Para ver um exemplo de como formatar esses relatórios em seu YAML, consulte [Exemplo de relatórios de qualidade YAML](test-config-action.md#test.success-criteria-example). **Topics** + [ ### Relatórios de teste ](#test-reports) + [ ### Relatórios de cobertura de código ](#test-code-coverage-reports) + [ ### Relatórios de análise de composição de software ](#test-sca-reports) + [ ### Relatórios de análise estática ](#test-static-analysis-reports) ### Relatórios de teste Em CodeCatalyst, você pode configurar testes de unidade, testes de integração e testes de sistema que são executados durante as compilações. Em seguida, CodeCatalyst pode criar relatórios que contêm os resultados dos seus testes. Você pode usar um relatório de teste para ajudar a solucionar problemas com seus testes. Se tiver muitos relatórios de teste de várias compilações, você poderá usar seus relatórios de teste para visualizar taxas de falha para ajudá-lo a otimizar suas compilações. É possível usar os seguintes formatos de arquivo de relatório de testes: + Cucumber JSON (.json) + JUnit XML (.xml) + NUnit XML (.xml) + NUnit3 XML (.xml) + TestNG XML (.xml) + Visual Studio TRX (.trx, .xml) ### Relatórios de cobertura de código Em CodeCatalyst, você pode gerar relatórios de cobertura de código para seus testes. CodeCatalyst fornece as seguintes métricas de cobertura de código: Cobertura de linha Mede quantas declarações seus testes abrangem. Declaração é uma instrução única, que não inclui comentários. `line coverage = (total lines covered)/(total number of lines)` Cobertura de ramificações Mede quantas ramificações seus testes cobrem de cada ramificação possível de uma estrutura de controle, como uma declaração `if` ou `case`. `branch coverage = (total branches covered)/(total number of branches)` Os seguintes formatos de arquivo de relatório de cobertura de código são compatíveis: + JaCoCo XML (.xml) + SimpleCov JSON (gerado por [simplecov, não [simplecov-json](https://github.com/vicentllongo/simplecov-json)](https://github.com/simplecov-ruby/simplecov), .json) + Clover XML (versão 3, .xml) + Cobertura XML (.xml) + LCOV (.info) ### Relatórios de análise de composição de software Em CodeCatalyst, você pode usar ferramentas de análise de composição de software (SCA) para analisar componentes do seu aplicativo e verificar se há vulnerabilidades de segurança conhecidas. Você pode descobrir e analisar relatórios do SARIF que detalham vulnerabilidades com severidades variadas e formas de corrigi-las. Os valores de gravidade válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Os seguintes formatos de arquivo de relatório SCA são compatíveis: + SARIF (.sarif, .json) ### Relatórios de análise estática Você pode usar relatórios de análise estática (SA) para identificar defeitos no código de origem. Em CodeCatalyst, você pode gerar relatórios de SA para ajudar a resolver problemas em seu código antes de implantá-lo. Esses problemas incluem bugs, vulnerabilidades de segurança, problemas de qualidade e outras vulnerabilidades. Os valores de gravidade válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. CodeCatalyst fornece as seguintes métricas de SA: Bugs Identifica vários possíveis bugs encontrados em seu código de origem. Esses bugs podem incluir problemas relacionados à segurança da memória. Veja a seguir um exemplo de um bug. ``` // The while loop will inadvertently index into array x out-of-bounds int x[64]; while (int n = 0; n <= 64; n++) { x[n] = 0; } ``` Vulnerabilidades de segurança Identifica várias vulnerabilidades de segurança possíveis encontradas em seu código de origem. Essas vulnerabilidades de segurança podem incluir problemas, como armazenar seus tokens secretos em texto simples. Problemas de qualidade Identifica vários possíveis problemas de qualidade encontrados em seu código de origem. Esses problemas de qualidade podem incluir problemas relacionados às convenções de estilo. Veja a seguir um exemplo de um problema de qualidade. ``` // The function name doesn't adhere to the style convention of camelCase int SUBTRACT(int x, int y) { return x-y } ``` Outras vulnerabilidades Identifica várias outras vulnerabilidades possíveis encontradas em seu código de origem. CodeCatalyst suporta os seguintes formatos de arquivo de relatório SA: + PyLint (.py) + ESLint (.js, .jsx, .ts, .tsx) + SARIF (.sarif, .json) # Adição da ação de teste Use o procedimento a seguir para adicionar uma ação de teste ao seu CodeCatalyst fluxo de trabalho. ------ #### [ Visual ] **Como adicionar uma ação de teste usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. Escolha **Ações**. 1. Em **Ações**, selecione **Teste**. 1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [Ações de criação e de teste YAML](build-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como adicionar uma ação de criação usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Escolha **Ações**. 1. Em **Ações**, selecione **Teste**. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [Ações de criação e de teste YAML](build-action-ref.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ ## Definição da ação de teste A ação de teste é definida como um conjunto de propriedades YAML dentro do arquivo de definição do fluxo de trabalho. Para ter mais informações sobre essas propriedades, consulte [Ações de criação e de teste YAML](build-action-ref.md) em [Definição do YAML do fluxo de trabalho](workflow-reference.md). # Visualização dos resultados de uma ação de teste Use as instruções a seguir para visualizar os resultados de uma ação de teste, incluindo os logs, relatórios e variáveis gerados. **Para visualizar os resultados de uma ação de teste** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. No diagrama do fluxo de trabalho, selecione o nome da ação de teste, por exemplo, **Teste**. 1. Para visualizar os logs gerados por uma ação, selecione **Logs**. Os logs das várias fases de ação são exibidos. Você pode expandir ou recolher os logs conforme necessário. 1. Para visualizar os relatórios de teste produzidos pela ação de teste, selecione **Relatórios** ou, no painel de navegação, selecione **Relatórios**. Para obter mais informações, consulte [Tipos de relatório de qualidade](test-workflow-actions.md#test-reporting). 1. Para visualizar a configuração usada para a ação de teste, selecione **Configuração**. Para obter mais informações, consulte [Adição da ação de teste](test-add-action.md). 1. Para visualizar as variáveis usadas pela ação de teste, selecione **Variáveis**. Para obter mais informações, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). # Omissão dos testes com falha em uma ação Se sua ação tiver mais de um comando de teste, talvez você queira permitir que comandos de teste subsequentes na ação sejam executados mesmo se um comando anterior falhar. Por exemplo, nos comandos a seguir, talvez você queira que `test2` execute sempre, mesmo se `test1` falhar. ``` Steps: - Run: npm install - Run: npm run test1 - Run: npm run test2 ``` Normalmente, quando uma etapa retorna um erro, a Amazon CodeCatalyst interrompe a ação do fluxo de trabalho e a marca como falhada. Você pode permitir que as etapas da ação continuem sendo executadas redirecionando a saída de erro para `null`. É possível fazer isso adicionando `2>/dev/null` ao comando. Com essa modificação, o exemplo anterior seria semelhante ao seguinte. ``` Steps: - Run: npm install - Run: npm run test1 2>/dev/null - Run: npm run test2 ``` No segundo trecho de código, o status do comando `npm install` será respeitado, mas qualquer erro retornado pelo comando `npm run test1` será ignorado. Como resultado, o comando `npm run test2` é executado. Ao fazer isso, você pode visualizar ambos os relatórios ao mesmo tempo, independentemente de ocorrer um erro. # Integrando com universal-test-runner As ações de teste são integradas à ferramenta de linha de comando de código aberto `universal-test-runner`. O `universal-test-runner` usa o [Protocolo de execução de teste](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md) para executar seus testes para qualquer linguagem em uma determinada estrutura. O `universal-test-runner` é compatível com as seguintes estruturas: + [Gradle](https://gradle.org/) + [Jest](https://jestjs.io/) + [Maven](https://maven.apache.org/) + [pytest](https://pytest.org) + [.NET](https://learn.microsoft.com/en-us/dotnet/core/tools/) O `universal-test-runner` é instalado somente nas imagens selecionadas para ações de teste. Se você configurar uma ação de teste para usar um Docker Hub ou Amazon ECR personalizado, deverá instalar manualmente o `universal-test-runner` para habilitar recursos de teste avançados. Para fazer isso, instale o Node.js (14 ou superior) na imagem e, depois, instale `universal-test-runner` por meio do `npm` usando o comando shell `- Run: npm install -g @aws/universal-test-runner`. Para ter mais informações sobre como instalar o Node.js no contêiner por meio de comandos shell, consulte [Installing and Updating Node Version Manager](https://github.com/nvm-sh/nvm#install--update-script). Para obter mais informações sobre o `universal-test-runner`, consulte [O que é universal-test-runner?](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner) ------ #### [ Visual ] **Para usar universal-test-runner no editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. Escolha **Ações**. 1. Em **Ações**, selecione **Teste**. 1. Na guia **Configuração**, preencha o campo **Comandos do Shell** atualizando o código de amostra com as estruturas compatíveis de sua escolha. Por exemplo, para usar uma estrutura compatível, você usaria um comando `Run` semelhante ao seguinte. ``` - Run: run-tests ``` Se a estrutura que você deseja não for compatível, considere contribuir com um adaptador ou executor personalizado. Para ver uma descrição do campo de **comandos do Shell**, consulte[Steps](build-action-ref.md#build.configuration.steps). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para usar universal-test-runner no editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Escolha **Ações**. 1. Em **Ações**, selecione **Teste**. 1. Modifique o código YAML de acordo com as suas necessidades. Por exemplo, para usar uma estrutura compatível, você usaria um comando `Run` semelhante ao seguinte. ``` Configuration: Steps: - Run: run-tests ``` Se a estrutura que você deseja não for compatível, considere contribuir com um adaptador ou executor personalizado. Para ver uma descrição da propriedade **Etapas**, consulte [Steps](build-action-ref.md#build.configuration.steps). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Configuração de relatórios de qualidade em uma ação Esta seção descreve como configurar um relatório de qualidade em uma ação. **Topics** + [ ## Descoberta automática e relatórios manuais ](#test.auto-discovery) + [ ## Configuração de critérios de sucesso para relatórios ](#test.success-criteria) + [ ## Exemplo de relatórios de qualidade YAML ](#test.success-criteria-example) ## Descoberta automática e relatórios manuais Quando a descoberta automática está ativada, CodeCatalyst pesquisa todas as entradas passadas para a ação e todos os arquivos gerados pela própria ação, procurando relatórios de teste, cobertura de código, análise de composição de software (SCA) e análise estática (SA). Você pode visualizar e manipular cada um desses relatórios em CodeCatalyst. Você também pode configurar manualmente quais relatórios são gerados. Você pode especificar o tipo de relatório que deseja gerar, bem como o formato do arquivo. Para obter mais informações, consulte [Tipos de relatório de qualidade](test-workflow-actions.md#test-reporting). ## Configuração de critérios de sucesso para relatórios Defina os valores que determinam os critérios de sucesso para um teste, cobertura de código, análise de composição de software (SCA) ou relatório de análise estática (SA). Os critérios de sucesso são limites que determinam se um relatório é aprovado ou reprovado. CodeCatalyst primeiro gera seu relatório, que pode ser um relatório de teste, cobertura de código, SCA ou SA, e depois aplica os critérios de sucesso aos relatórios gerados. Em seguida, mostra se os critérios de sucesso foram atendidos e em que medida. Se algum relatório não atender aos critérios de sucesso especificados, a CodeCatalyst ação que especificou os critérios de sucesso falhará. Por exemplo, quando você define os critérios de sucesso para seu relatório de SCA, os valores de vulnerabilidade válidos que variam do mais ao menos grave são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Se você definir os critérios para verificar uma vulnerabilidade com a gravidade `HIGH`, o relatório falhará se houver pelo menos uma vulnerabilidade com a gravidade `HIGH` ou nenhuma vulnerabilidade com a gravidade `HIGH`, mas pelo menos uma vulnerabilidade em um nível de gravidade mais alto, como uma vulnerabilidade em uma gravidade `CRITICAL`. Se você não especificar os critérios de sucesso, então: + O CodeCatalyst relatório gerado com base em seus relatórios brutos não exibirá critérios de sucesso. + Os critérios de sucesso não serão usados para determinar se a ação do fluxo de trabalho associada será aprovada ou falhará. ------ #### [ Visual ] **Para configurar critérios de sucesso** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha um fluxo de trabalho com uma ação que gere um relatório. Este é o relatório ao qual você deseja aplicar os critérios de sucesso. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, escolha a ação que você configurou para gerar CodeCatalyst relatórios. 1. Escolha a guia **Outputs**. 1. Em **Relatórios de descoberta automática** ou em **Configurar relatórios manualmente**, selecione **Critérios de sucesso**. Os critérios de sucesso são exibidos. Dependendo das suas seleções anteriores, você pode ver uma ou todas essas opções: **Taxa de aprovação** Especifique a porcentagem de testes em um relatório de teste que devem ser aprovados para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de taxa de aprovação são aplicados somente aos relatórios de teste. Para ter mais informações sobre os relatórios de teste, consulte [Relatórios de teste](test-workflow-actions.md#test-reports). **Cobertura de linha** Especifique a porcentagem de linhas em um relatório de cobertura de código que devem ser cobertas para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de cobertura de linha são aplicados somente aos relatórios de cobertura de código. Para ter mais informações sobre relatórios de cobertura de código, consulte [Relatórios de cobertura de código](test-workflow-actions.md#test-code-coverage-reports). **Cobertura de ramificações** Especifique a porcentagem de filiais em um relatório de cobertura de código que devem ser cobertas para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de cobertura de ramificações são aplicados somente aos relatórios de cobertura de código. Para ter mais informações sobre relatórios de cobertura de código, consulte [Relatórios de cobertura de código](test-workflow-actions.md#test-code-coverage-reports). **Vulnerabilidades (SCA)** Especifique o número máximo e a gravidade das vulnerabilidades permitidas no relatório SCA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar vulnerabilidades, é necessário especificar: + A gravidade mínima das vulnerabilidades que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, as vulnerabilidades `HIGH` e `CRITICAL` serão contabilizadas. + O número máximo de vulnerabilidades da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de vulnerabilidade são aplicados somente aos relatórios de SCA. Para ter mais informações sobre os relatórios de SCA, consulte [Relatórios de análise de composição de software](test-workflow-actions.md#test-sca-reports). **Bugs** Especifique o número máximo e a gravidade dos bugs permitidos no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar bugs, é necessário especificar: + A gravidade mínima dos bugs que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, os bugs `HIGH` e `CRITICAL` serão contabilizados. + O número máximo de bugs da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de bugs são aplicados somente PyLint aos relatórios do ESLint SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports). **Vulnerabilidades de segurança** Especifique o número máximo e a gravidade das vulnerabilidades de segurança permitidas no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar vulnerabilidades de segurança, é necessário especificar: + A gravidade mínima das vulnerabilidades de segurança que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, as vulnerabilidades de segurança `HIGH` e `CRITICAL` serão contabilizadas. + O número máximo de vulnerabilidades de segurança da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de vulnerabilidades de segurança são aplicados somente aos PyLint relatórios do ESLint SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports). **Problemas de qualidade** Especifique o número máximo e a gravidade dos problemas de qualidade permitidos no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar problemas de qualidade, é necessário especificar: + A gravidade mínima dos problemas de qualidade que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, os problemas de qualidade `HIGH` e `CRITICAL` serão contabilizados. + O número máximo de problemas de qualidade da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de problemas de qualidade são aplicados somente PyLint aos relatórios ESLint da SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports). 1. Selecione **Confirmar**. 1. Execute seu fluxo de trabalho para CodeCatalyst aplicar critérios de sucesso aos seus relatórios brutos e regenere os CodeCatalyst relatórios associados com as informações dos critérios de sucesso incluídas. Para obter mais informações, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md). ------ #### [ YAML ] **Para configurar critérios de sucesso** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha um fluxo de trabalho com uma ação que gere um relatório. Este é o relatório ao qual você deseja aplicar os critérios de sucesso. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No diagrama do fluxo de trabalho, escolha a ação que você configurou para gerar CodeCatalyst relatórios. 1. No painel de detalhes, selecione a guia **Saídas**. 1. Na ação, na `AutoDiscoverReports` seção ou na `Reports` seção, adicione uma **SuccessCriteria**propriedade junto com`PassRate`,`LineCoverage`,`BranchCoverage`,`Vulnerabilities`, `StaticAnalysisBug``StaticAnalysisSecurity`, e `StaticAnalysisQuality` propriedades. Para ver uma explicação de cada uma dessas propriedades, consulte [Ações de criação e de teste YAML](build-action-ref.md). 1. Selecione **Confirmar**. 1. Execute seu fluxo de trabalho para CodeCatalyst aplicar critérios de sucesso aos seus relatórios brutos e regenere os CodeCatalyst relatórios associados com as informações dos critérios de sucesso incluídas. Para ter mais informações sobre como iniciar um fluxo de trabalho, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md). ------ ## Exemplo de relatórios de qualidade YAML O exemplo a seguir mostra como configurar manualmente quatro relatórios: um relatório de teste, um relatório de cobertura de código, um relatório de análise de composição de software e um relatório de análise estática. ``` Reports: MyTestReport: Format: JUNITXML IncludePaths: - "*.xml" ExcludePaths: - report1.xml SuccessCriteria: PassRate: 90 MyCoverageReport: Format: CLOVERXML IncludePaths: - output/coverage/jest/clover.xml SuccessCriteria: LineCoverage: 75 BranchCoverage: 75 MySCAReport: Format: SARIFSCA IncludePaths: - output/sca/reports.xml SuccessCriteria: Vulnerabilities: Number: 5 Severity: HIGH MySAReport: Format: ESLINTJSON IncludePaths: - output/static/eslint.xml SuccessCriteria: StaticAnalysisBug: Number: 10 Severity: MEDIUM StaticAnalysisSecurity: Number: 5 Severity: CRITICAL StaticAnalysisQuality: Number: 0 Severity: INFORMATIONAL ``` # Melhores práticas de teste Ao usar os recursos de teste fornecidos pelo CodeCatalyst, recomendamos que você siga essas melhores práticas. **Topics** + [ ## Descoberta automática ](#test.best-auto-discovery) + [ ## Critérios de sucesso ](#test.best-success-criteria) + [ ## Inclusão/exclusão de caminhos ](#test.best-include-exclude) ## Descoberta automática Ao configurar ações CodeCatalyst, a descoberta automática permite que você descubra automaticamente os resultados de várias ferramentas, como relatórios de JUnit teste, e gere CodeCatalyst relatórios relevantes a partir deles. A descoberta automática ajuda a garantir que os relatórios continuem sendo gerados, mesmo se os nomes ou caminhos para as saídas descobertas mudarem. Quando novos arquivos são adicionados, os descobre CodeCatalyst automaticamente e produz relatórios relevantes. No entanto, se você usa a descoberta automática, é importante pensar em alguns dos seguintes aspectos desse recurso: + Ao ativar a descoberta automática em sua ação, todos os relatórios descobertos automaticamente do mesmo tipo compartilharão os mesmos critérios de sucesso. Por exemplo, um critério compartilhado, como taxa mínima de aprovação, se aplicaria a todos os relatórios de teste descobertos automaticamente. Se você precisar de critérios diferentes para relatórios do mesmo tipo, configure explicitamente cada um desses relatórios. + A descoberta automática também pode encontrar relatórios produzidos por suas dependências e, se os critérios de sucesso estiverem configurados, poderá falhar na ação desses relatórios. Esse problema pode ser resolvido atualizando a configuração do caminho de exclusão. + Não é garantido que a descoberta automática produza sempre a mesma lista de relatórios, pois ela verifica a ação em runtime. Se você quiser que um relatório específico seja sempre produzido, configure os relatórios explicitamente. Por exemplo, se os testes parassem de ser executados como parte de sua compilação, a estrutura de teste não produziria nenhuma saída e, como resultado, nenhum relatório de teste seria produzido e a ação poderia ser bem-sucedida. Se você quiser que o sucesso de sua ação dependa desse teste específico, configure explicitamente esse relatório. **dica** Ao começar um projeto novo ou existente, use a descoberta automática para todo o diretório do projeto (incluir `**/*`). Isso invoca a geração de relatórios em todos os arquivos do seu projeto, incluindo aqueles em subdiretórios. Para obter mais informações, consulte [Configuração de relatórios de qualidade em uma ação](test-config-action.md). ## Critérios de sucesso Você pode impor limites de qualidade em seus relatórios configurando critérios de sucesso. Por exemplo, se dois relatórios de cobertura de código foram descobertos automaticamente, um com uma cobertura de linha de 80% e outro com uma cobertura de linha de 60%, você tem as seguintes opções: + Defina os critérios de sucesso da descoberta automática para cobertura de linha em 80%. Isso faria com que o primeiro relatório fosse aprovado e o segundo falhasse, o que resultaria na falha geral da ação. Para desbloquear o fluxo de trabalho, adicione novos testes ao seu projeto até que a cobertura da linha para o segundo relatório exceda 80%. + Defina os critérios de sucesso da descoberta automática para cobertura de linha em 60%. Isso faria com que ambos os relatórios fossem aprovados, o que resultaria no sucesso da ação. Você poderia então trabalhar para aumentar a cobertura do código no segundo relatório. No entanto, com essa abordagem, você não pode garantir que a cobertura no primeiro relatório não caia abaixo de 80%. + Configure explicitamente um ou ambos os relatórios usando o editor visual ou adicionando uma seção e um caminho YAML explícitos para cada relatório. Isso permitiria que você configurasse critérios de sucesso e nomes personalizados separados para cada relatório. No entanto, com essa abordagem, a ação pode falhar se os caminhos do relatório mudarem. Para obter mais informações, consulte [Configuração de critérios de sucesso para relatórios](test-config-action.md#test.success-criteria). ## Inclusão/exclusão de caminhos Ao analisar os resultados da ação, você pode ajustar a lista de relatórios que são gerados CodeCatalyst pela configuração e. `IncludePaths` `ExcludePaths` + Use `IncludePaths` para especificar os arquivos e caminhos de arquivo que você CodeCatalyst deseja incluir ao pesquisar relatórios. Por exemplo, se você especificar`"/test/report/*"`, CodeCatalyst pesquisa toda a imagem de compilação usada pela ação procurando o `/test/report/` diretório. Quando encontra esse diretório CodeCatalyst , procura relatórios nesse diretório. **nota** Em relatórios configurados manualmente, `IncludePaths` deverá ser um padrão global que corresponda a um único arquivo. + Use `ExcludePaths` para especificar os arquivos e caminhos de arquivo que você CodeCatalyst deseja excluir ao pesquisar relatórios. Por exemplo, se você especificar`"/test/reports/**/*"`, não CodeCatalyst procurará arquivos no `/test/reports/` diretório. Para ignorar todos os arquivos em um diretório, use o padrão de glob `**/*`. Veja a seguir alguns exemplos de padrões glob possíveis. | Padrão | Description | | --- | --- | | `*.*` | Corresponde a todos os nomes de objetos no diretório atual que contêm um ponto | | `*.xml` | Corresponde a todos os nomes de objetos no diretório atual que terminam com `.xml` | | `*.{xml,txt}` | Corresponde a todos os nomes de objetos no diretório atual que terminam com `.xml` ou `.txt` | | `**/*.xml` | Corresponde aos nomes dos objetos em todos os diretórios que terminam com `.xml` | | `testFolder` | Corresponde a um objeto chamado `testFolder`, tratando-o como um arquivo | | `testFolder/*` | Corresponde a objetos em um nível de subpasta de `testFolder`, como `testFolder/file.xml` | | `testFolder/*/*` | Corresponde a objetos em dois níveis da subpasta de `testFolder`, como `testFolder/reportsFolder/file.xml` | | `testFolder/**` | Corresponde a subpasta `testFolder` bem como aos arquivos abaixo de `testFolder`, por exemplo, `testFolder/file.xml` e `testFolder/otherFolder/file.xml` | CodeCatalyst interpreta os padrões globais da seguinte forma: + O caractere de barra (`/`) separa os diretórios nos caminhos dos arquivos. + O caractere de asterisco (`*`) corresponde a zero ou mais caracteres de um componente de nome sem cruzar limites da pasta. + Um asterisco duplo (`**`) corresponde a zero ou mais caracteres de um componente de nome em todos os diretórios. **nota** `ExcludePaths` tem precedência sobre `IncludePaths`. Se ambos `IncludePaths` e `ExcludePaths` incluírem a mesma pasta, essa pasta não será examinada em busca de relatórios. # Propriedades SARIF compatíveis O Static Analysis Results Interchange Format (SARIF) é um formato de arquivo de saída que está disponível em análise de composição de software (SCA) e relatórios de análise estática na Amazon. CodeCatalyst O exemplo a seguir mostra como configurar manualmente o SARIF em um relatório de análise estática: ``` Reports: MySAReport: Format: SARIFSA IncludePaths: - output/sa_report.json SuccessCriteria: StaticAnalysisFinding: Number: 25 Severity: HIGH ``` CodeCatalyst suporta as seguintes propriedades SARIF, que podem ser usadas para otimizar a forma como os resultados da análise aparecerão em seus relatórios. **Topics** + [ ## Objeto `sarifLog` ](#test.sarif.sarifLog) + [ ## Objeto `run` ](#test.sarif.run) + [ ## Objeto `toolComponent` ](#test.sarif.toolComponent) + [ ## Objeto `reportingDescriptor` ](#test.sarif.reportingDescriptor) + [ ## Objeto `result` ](#test.sarif.result) + [ ## Objeto `location` ](#test.sarif.location) + [ ## Objeto `physicalLocation` ](#test.sarif.physicalLocation) + [ ## Objeto `logicalLocation` ](#test.sarif.logicalLocation) + [ ## Objeto `fix` ](#test.sarif.fix) ## Objeto `sarifLog` | Nome | Obrigatório | Descrição | | --- | --- | --- | | `$schema` | Sim | O URI do esquema SARIF JSON para a versão [2.1.0](https://json.schemastore.org/sarif-2.1.0.json). | | `version` | Sim | CodeCatalyst suporta apenas a versão 2.1.0 do SARIF. | | `runs[]` | Sim | Um arquivo SARIF contém uma ou mais execuções, cada uma das quais representando uma única execução da ferramenta de análise. | ## Objeto `run` | Nome | Obrigatório | Descrição | | --- | --- | --- | | `tool.driver` | Sim | Um objeto `toolComponent` que descreve a ferramenta de análise. | | `tool.name` | Não | Uma propriedade que indica o nome da ferramenta usada para realizar a análise. | | `results[]` | Sim | Os resultados da ferramenta de análise que são exibidos em CodeCatalyst. | ## Objeto `toolComponent` | Nome | Obrigatório | Descrição | | --- | --- | --- | | `name` | Sim | O nome da ferramenta de análise. | | `properties.artifactScanned` | Não | Um número total de artefatos analisados pela ferramenta. | | `rules[]` | Sim | Uma matriz de objetos `reportingDescriptor` que representam regras. Com base nessas regras, a ferramenta de análise encontra problemas no código que é analisado. | ## Objeto `reportingDescriptor` | Nome | Obrigatório | Descrição | | --- | --- | --- | | `id` | Sim | O identificador exclusivo da regra que é usada para referenciar uma descoberta. Tamanho máximo: 1.024 caracteres | | `name` | Não | O nome de exibição da regra. Tamanho máximo: 1.024 caracteres | | `shortDescription.text` | Não | Uma descrição resumida da regra. Tamanho máximo: 3.000 caracteres | | `fullDescription.text` | Não | Uma descrição completa da regra. Tamanho máximo: 3.000 caracteres | | `helpUri` | Não | Uma string que pode ser localizada para conter o URI absoluto da documentação primária da regra. Tamanho máximo: 3.000 caracteres | | `properties.unscore` | Não | Um sinalizador que indica se a descoberta do escaneamento foi pontuada. | | `properties.score.severity` | Não | Um conjunto fixo de strings que especificam o nível de gravidade da descoberta. Tamanho máximo: 1.024 caracteres | | `properties.cvssv3_baseSeverity` | Não | Uma classificação de gravidade qualitativa do [Sistema de pontuação de vulnerabilidades comuns v3.1](https://www.first.org/cvss/v3.1/specification-document). | | `properties.cvssv3_baseScore` | Não | Uma pontuação básica do CVSS v3 variando de [0,0 a 10,0](https://nvd.nist.gov/vuln-metrics/cvss). | | `properties.cvssv2_severity` | Não | Se os valores do CVSS v3 não estiverem disponíveis, CodeCatalyst pesquisa os valores do CVSS v2. | | `properties.cvssv2_score` | Não | Uma pontuação básica do CVSS v2 variando de [0,0 a 10,0](https://nvd.nist.gov/vuln-metrics/cvss). | | `properties.severity` | Não | Um conjunto fixo de strings que especificam o nível de gravidade da descoberta. Tamanho máximo: 1.024 caracteres | | `defaultConfiguration.level` | Não | A gravidade padrão de uma regra. | ## Objeto `result` | Nome | Obrigatório | Descrição | | --- | --- | --- | | `ruleId` | Sim | O identificador exclusivo da regra que é usada para referenciar uma descoberta. Tamanho máximo: 1.024 caracteres | | `ruleIndex` | Sim | O índice da regra associada no componente da ferramenta `rules[]`. | | `message.text` | Sim | Uma mensagem que descreve o resultado e exibe a mensagem de cada descoberta. Tamanho máximo: 3.000 caracteres | | `rank` | Não | Um valor entre 0,0 e 100,0, inclusive, que representa a prioridade ou importância do resultado. Essa escala considera 0,0 como a prioridade mais baixa e 100,0 como a prioridade mais alta. | | `level` | Não | A gravidade do resultado. Tamanho máximo: 1.024 caracteres | | `properties.unscore` | Não | Um sinalizador que indica se a descoberta do escaneamento foi pontuada. | | `properties.score.severity` | Não | Um conjunto fixo de strings que especificam o nível de gravidade da descoberta. Tamanho máximo: 1.024 caracteres | | `properties.cvssv3_baseSeverity` | Não | Uma classificação de gravidade qualitativa do [Sistema de pontuação de vulnerabilidades comuns v3.1](https://www.first.org/cvss/v3.1/specification-document). | | `properties.cvssv3_baseScore` | Não | Uma pontuação básica do CVSS v3 variando de [0,0 a 10,0](https://nvd.nist.gov/vuln-metrics/cvss). | | `properties.cvssv2_severity` | Não | Se os valores do CVSS v3 não estiverem disponíveis, CodeCatalyst pesquisa os valores do CVSS v2. | | `properties.cvssv2_score` | Não | Uma pontuação básica do CVSS v2 variando de [0,0 a 10,0](https://nvd.nist.gov/vuln-metrics/cvss). | | `properties.severity` | Não | Um conjunto fixo de strings que especificam o nível de gravidade da descoberta. Tamanho máximo: 1.024 caracteres | | `locations[]` | Sim | O conjunto de locais em que o resultado foi detectado. Somente um local deve ser incluído, a menos que o problema só possa ser corrigido fazendo uma alteração em cada local especificado. CodeCatalyst usa o primeiro valor na matriz de localização para anotar o resultado. Número máximo de objetos `location`: 10 | | `relatedLocations[]` | Não | Uma lista de referências de localizações adicionais na descoberta. Número máximo de objetos `location`: 50 | | `fixes[]` | Não | Uma matriz de `fix` objetos que representam a recomendação fornecida pela ferramenta de digitalização. CodeCatalyst usa a primeira recomendação na `fixes` matriz. | ## Objeto `location` | Nome | Obrigatório | Descrição | | --- | --- | --- | | `physicalLocation` | Sim | Identifica o artefato e a região. | | `logicalLocations[]` | Não | O conjunto de locais descritos pelo nome sem referência ao artefato. | ## Objeto `physicalLocation` | Nome | Obrigatório | Descrição | | --- | --- | --- | | `artifactLocation.uri` | Sim | O URI que indica a localização de um artefato, geralmente um arquivo no repositório ou gerado durante uma compilação. | | `fileLocation.uri` | Não | O URI de retorno indicando a localização do arquivo. Isso será usado se `artifactLocation.uri` retornar vazio. | | `region.startLine` | Sim | O número da linha do primeiro caractere na região. | | `region.startColumn` | Sim | O número da coluna do primeiro caractere na região. | | `region.endLine` | Sim | O número da linha do último caractere na região. | | `region.endColumn` | Sim | O número da coluna do último caractere na região. | ## Objeto `logicalLocation` | Nome | Obrigatório | Description | | --- | --- | --- | | `fullyQualifiedName` | Não | Informações adicionais que descrevem a localização do resultado. Tamanho máximo: 1.024 caracteres | ## Objeto `fix` | Nome | Obrigatório | Description | | --- | --- | --- | | `description.text` | Não | Uma mensagem que exibe uma recomendação para cada descoberta. Tamanho máximo: 3.000 caracteres | | `artifactChanges.[0].artifactLocation.uri` | Não | O URI que indica a localização do artefato que precisa ser atualizado. | # Implantar com fluxos de trabalho Usando [CodeCatalyst fluxos de trabalho](workflow.md), você pode implantar aplicativos e outros recursos em vários destinos, como Amazon ECS e muito mais. AWS Lambda ## Como faço para implantar uma aplicação? Para implantar um aplicativo ou recurso CodeCatalyst, primeiro você cria um fluxo de trabalho e, em seguida, especifica uma ação de implantação dentro dele. Uma *ação de implantação* é um componente básico do fluxo de trabalho *que define o* que você deseja implantar, *onde* e *como* deseja implantá-lo (por exemplo, usando um blue/green esquema). Você adiciona uma ação de implantação ao seu fluxo de trabalho usando o editor visual do CodeCatalyst console ou o editor YAML. As etapas detalhadas para implantar uma aplicação ou um recurso são as seguintes. **Como implantar uma aplicação (tarefas detalhadas)** 1. No seu CodeCatalyst projeto, você **adiciona o código-fonte** de um aplicativo que deseja implantar. Para obter mais informações, consulte [Armazenando o código-fonte em repositórios para um projeto no CodeCatalyst](source-repositories.md). 1. Em seu CodeCatalyst projeto, você **adiciona um ambiente** que define a Amazon Virtual Private Cloud (VPC) de destino Conta da AWS e opcional na qual você deseja implantar. Para obter mais informações, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md). 1. No seu CodeCatalyst projeto, você **cria um fluxo de trabalho**. No fluxo de trabalho, você define como criar, testar e implantar a aplicação. Para obter mais informações, consulte [Conceitos básicos de fluxos de trabalho](workflows-getting-started.md). 1. No fluxo de trabalho, você **adiciona um gatilho**, uma **ação de criação** e, se desejar, uma **ação de teste**. Para obter mais informações, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md), [Adição da ação de criação](build-add-action.md) e [Adição da ação de teste](test-add-action.md). 1. No fluxo de trabalho, você **adiciona uma ação de implantação**. Você pode escolher entre várias ações de implantação CodeCatalyst fornecidas para seu aplicativo em diferentes destinos, como o Amazon ECS. (Você também pode usar uma ação de compilação ou uma GitHub ação para implantar seu aplicativo. Para obter mais informações sobre a ação de criação e GitHub as ações, consulte[Alternativas para ações de implantação](#deploy-concepts-alternatives).) 1. Você **inicia o fluxo de trabalho** manual ou automaticamente por meio de um gatilho. O fluxo de trabalho executa as ações de criação, teste e implantação em sequência para implantar a aplicação e os recursos no destino. Para obter mais informações, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md). ## Lista de ações de implantação As seguintes ações de implantação estão disponíveis: + Implantar CloudFormation pilha — Essa ação cria uma CloudFormation pilha AWS com base em um [CloudFormation modelo ou [AWS Serverless Application Model modelo](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html) fornecido por você. Para obter mais informações, consulte [Implantação de uma pilha CloudFormation](deploy-action-cfn.md). + Implantar no Amazon ECS - Essa ação registra um arquivo de [definição de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) que você fornece. Para obter mais informações, consulte [Implantação no Amazon ECS com um fluxo de trabalho](deploy-action-ecs.md). + Implantar no cluster do Kubernetes - Essa ação implanta uma aplicação em um cluster do Amazon Elastic Kubernetes Service. Para obter mais informações, consulte [Implantar no Amazon EKS com um fluxo de trabalho](deploy-action-eks.md). + AWS CDK implantar — Essa ação implanta um [AWS CDK aplicativo](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_concepts) em AWS. Para obter mais informações, consulte [Implantando um AWS CDK aplicativo com um fluxo de trabalho](cdk-dep-action.md). **nota** *Há outras CodeCatalyst ações que podem implantar recursos; no entanto, elas não são consideradas ações de implantação porque suas informações de implantação não aparecem na página **Ambientes**.* Para saber mais sobre a página **Ambientes** e ver as implantações, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Visualizar informações de implantação](deploy-view-deployment-info.md). ## Benefícios das ações de implantação O uso de ações de implantação em um fluxo de trabalho fornece os seguintes benefícios: + **Histórico de implantação**: visualize um histórico de suas implantações para ajudar a gerenciar e comunicar as alterações no software implantado. + **Rastreabilidade** — Acompanhe o status de suas implantações por meio do CodeCatalyst console e veja quando e onde cada revisão do aplicativo foi implantada. + **Reversões**: reverta as implantações automaticamente se houver erros. Também é possível configurar alarmes para ativar reversões de implantação. + **Monitoramento** — Observe sua implantação conforme ela progride nos vários estágios do fluxo de trabalho. + **Integração com outros CodeCatalyst recursos** — armazene o código-fonte e, em seguida, crie, teste e implante, tudo em um único aplicativo. ## Alternativas para ações de implantação Você não precisa usar ações de implantação, embora elas sejam recomendadas porque oferecem os benefícios descritos na seção anterior. Em vez disso, você pode usar as seguintes [CodeCatalyst ações](workflows-actions.md#workflows-actions-types-cc): + Uma ação de **criação**. Normalmente, você usa ações de criação quando quer implantar em um destino para o qual não existe uma ação de implantação correspondente ou quando quer ter mais controle sobre o procedimento de implantação. Para ter mais informações sobre como usar ações de criação para implantar recursos, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). + Uma **GitHub ação**. Você pode usar uma [GitHub ação](workflows-actions.md#workflows-actions-types-github) dentro de um CodeCatalyst fluxo de trabalho para implantar aplicativos e recursos (em vez de uma CodeCatalyst ação). Para obter informações sobre como usar GitHub ações em um CodeCatalyst fluxo de trabalho, consulte [Integração com GitHub ações](integrations-github-actions.md) Você também pode usar os seguintes AWS serviços para implantar seu aplicativo, se não quiser usar um CodeCatalyst fluxo de trabalho para fazer isso: + AWS CodeDeploy — veja [O que é CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + AWS CodeBuild e AWS CodePipeline — veja [O que é AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) e [o que é AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) + CloudFormation — veja [O que é CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) Use CodeDeploy, CodeBuild CodePipeline, e CloudFormation serviços para implantações corporativas complexas. **Topics** + [ ## Como faço para implantar uma aplicação? ](#deploy-concepts) + [ ## Lista de ações de implantação ](#deploy-concepts-action-supported) + [ ## Benefícios das ações de implantação ](#deploy-concepts-why-use) + [ ## Alternativas para ações de implantação ](#deploy-concepts-alternatives) + [ # Implantação no Amazon ECS com um fluxo de trabalho ](deploy-action-ecs.md) + [ # Implantar no Amazon EKS com um fluxo de trabalho ](deploy-action-eks.md) + [ # Implantação de uma pilha CloudFormation ](deploy-action-cfn.md) + [ # Implantando um AWS CDK aplicativo com um fluxo de trabalho ](cdk-dep-action.md) + [ # Inicializando um AWS CDK aplicativo com um fluxo de trabalho ](cdk-boot-action.md) + [ # Publicação de arquivos no Amazon S3 com um fluxo de trabalho ](s3-pub-action.md) + [ # Implantação em e Contas da AWS VPCs ](deploy-environments.md) + [ # Exibir o URL da aplicação no diagrama do fluxo de trabalho ](deploy-app-url.md) + [ # Remoção de um destino de implantação ](deploy-remove-target.md) + [ # Rastreamento do status de implantação por confirmação ](track-changes.md) + [ # Visualização dos logs de implantação ](deploy-deployment-logs.md) + [ # Visualizar informações de implantação ](deploy-view-deployment-info.md) # Implantação no Amazon ECS com um fluxo de trabalho Esta seção descreve como implantar um aplicativo em contêiner em um cluster do Amazon Elastic Container Service usando um CodeCatalyst fluxo de trabalho. Para fazer isso, você deve adicionar a ação **Implantar no Amazon ECS** ao seu fluxo de trabalho. Essa ação registra um arquivo de [definição de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) que você fornece. Após o registro, a definição da tarefa é instanciada pelo [serviço do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) em execução no [cluster do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters). “Instanciar uma definição de tarefa” é equivalente a implantar uma aplicação no Amazon ECS. Para usar essa ação, você deve ter um cluster, serviço e arquivo de definição de tarefas do Amazon ECS pronto. Para ter mais informações sobre o Amazon ECS, consulte o *Guia do desenvolvedor do Amazon Elastic Container Service*. **dica** Para ver um tutorial que mostra como usar a ação **Implantar no Amazon ECS**, consulte [Tutorial: Implantar uma aplicação no Amazon ECS](deploy-tut-ecs.md). **dica** Para ter um exemplo prático da ação **Implantar no Amazon ECS**, crie um projeto com o esquema **API Node.js com AWS Fargate** ou a **API Java com AWS Fargate**. Para obter mais informações, consulte [Criar um projeto com um esquema](projects-create.md#projects-create-console-template). **Topics** + [ ## Imagem de runtime usada pela ação “Implantar no Amazon ECS” ](#deploy-action-ecs-runtime) + [ # Tutorial: Implantar uma aplicação no Amazon ECS ](deploy-tut-ecs.md) + [ # Adição da ação “Implantar no Amazon ECS” ](deploy-action-ecs-adding.md) + [ # Variáveis de “Implantar no Amazon ECS” ](deploy-action-ecs-variables.md) + [ # YAML de ação “Implantar no Amazon ECS” ](deploy-action-ref-ecs.md) ## Imagem de runtime usada pela ação “Implantar no Amazon ECS” A ação **Implantar no Amazon ECS** é executada em uma [imagem de novembro de 2022](build-images.md#build.previous-image). Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). # Tutorial: Implantar uma aplicação no Amazon ECS Neste tutorial, você aprende a implantar um aplicativo sem servidor no Amazon Elastic Container Service (Amazon ECS) usando um fluxo de trabalho, o Amazon ECS e alguns outros serviços. AWS A aplicação implantada é um site simples do Hello World construído em uma imagem do Docker do servidor da Web Apache. O tutorial explica o trabalho de preparação necessário, como a configuração de um cluster, e descreve como criar um fluxo de trabalho para criar e implantar a aplicação. **dica** Em vez de seguir este tutorial, você pode usar um esquema que faz uma configuração completa do Amazon ECS para você. Você precisará usar o esquema **API Node.js com AWS Fargate** ou **API Java com AWS Fargate**. Para obter mais informações, consulte [Criar um projeto com um esquema](projects-create.md#projects-create-console-template). **Topics** + [ ## Pré-requisitos ](#deploy-tut-ecs-prereqs) + [ ## Etapa 1: configurar um AWS usuário e AWS CloudShell ](#deploy-tut-ecs-user-cloudshell) + [ ## Etapa 2: implantar uma aplicação de espaço reservado no Amazon ECS ](#deploy-tut-ecs-placeholder) + [ ## Etapa 3: criar uma imagem de repositório do Amazon ECR ](#deploy-tut-ecs-ecr) + [ ## Etapa 4: criar AWS funções ](#deploy-tut-ecs-build-deploy-roles) + [ ## Etapa 5: adicionar AWS funções a CodeCatalyst ](#deploy-tut-ecs-import-roles) + [ ## Etapa 6: criar um repositório de origem ](#deploy-tut-ecs-source-repo) + [ ## Etapa 7: adicionar arquivos de origem ](#deploy-tut-ecs-source-files) + [ ## Etapa 8: criar e executar um fluxo de trabalho ](#deploy-tut-ecs-workflow) + [ ## Etapa 9: realizar uma alteração nos arquivos de origem ](#deploy-tut-ecs-change) + [ ## Limpeza ](#deploy-tut-ecs-cleanup) ## Pré-requisitos Antes de começar + Você precisa de um CodeCatalyst **espaço** com uma AWS conta conectada. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). + Em seu espaço, você precisa de um projeto vazio chamado: ``` codecatalyst-ecs-project ``` Use a opção **Começar do zero** para criar esse projeto. Para obter mais informações, consulte [Criando um projeto vazio na Amazon CodeCatalyst](projects-create.md#projects-create-empty). + Em seu projeto, você precisa de um CodeCatalyst **ambiente** chamado: ``` codecatalyst-ecs-environment ``` Configure esse ambiente da seguinte forma: + Escolha qualquer tipo, como **Não produção**. + Conecte sua AWS conta a ela. + Para o **Perfil do IAM padrão**, escolha qualquer perfil. Você especificará um perfil diferente posteriormente. Para obter mais informações, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md). ## Etapa 1: configurar um AWS usuário e AWS CloudShell A primeira etapa deste tutorial é criar um usuário e executar uma AWS CloudShell instância como esse usuário. Centro de Identidade do AWS IAM Durante este tutorial, CloudShell é o seu computador de desenvolvimento e é onde você configura AWS recursos e serviços. Exclua esse usuário depois de concluir o tutorial. **nota** Não use seu usuário-raiz neste tutorial. Você deve criar um usuário separado, caso contrário poderá ter problemas ao executar ações na AWS Command Line Interface (CLI) posteriormente. Para obter mais informações sobre os usuários do IAM Identity Center e CloudShell consulte o *Guia Centro de Identidade do AWS IAM do usuário* e o *Guia AWS CloudShell do usuário*. **Como criar um usuário do Centro de Identidade do IAM** 1. Faça login no Console de gerenciamento da AWS e abra o Centro de Identidade do AWS IAM console em [https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/). **nota** Certifique-se de fazer login usando o Conta da AWS que está conectado ao seu CodeCatalyst espaço. Você pode verificar qual conta está conectada navegando até seu espaço e escolhendo a guia **Contas da AWS**. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). 1. No painel de navegação, escolha **Usuários** e depois **Adicionar usuário**. 1. Em **Nome de usuário**, digite: ``` CodeCatalystECSUser ``` 1. Em **Senha**, selecione **Gerar uma senha de uso único que você possa compartilhar com esse usuário**. 1. Em **Endereço de e-mail** e **Confirmar endereço de e-mail**, insira um endereço de e-mail que ainda não exista no IAM Identity Center. 1. Em **Nome** e **Sobrenome**, digite: ``` CodeCatalystECSUser ``` 1. Em **Nome de exibição**, mantenha o nome gerado automaticamente: ``` CodeCatalystECSUser CodeCatalystECSUser ``` 1. Escolha **Próximo**. 1. Na página **Adicionar usuário a grupos**, selecione **Avançar**. 1. Na página **Revisar e adicionar usuário**, revise as informações e selecione **Adicionar usuário**. Uma caixa de diálogo **Senha de uso único** é exibida. 1. Selecione **Copiar** e cole as informações de login, incluindo o URL do portal de acesso da AWS e a senha de uso único. 1. Escolha **Fechar**. **Para criar um conjunto de permissões** Você atribuirá esse conjunto de permissões a `CodeCatalystECSUser` posteriormente. 1. No painel de navegação, escolha **Conjuntos de permissões** e selecione **Criar conjunto de permissões**. 1. Escolha Conjunto de **permissões predefinido** e, em seguida, selecione **AdministratorAccess**. Esta política fornece permissões totais para todos os Serviços da AWS. 1. Escolha **Próximo**. 1. Em **Nome do conjunto de permissões**, digite: ``` CodeCatalystECSPermissionSet ``` 1. Escolha **Próximo**. 1. Na página **Revisar e criar**, revise as informações e selecione **Criar**. **Para atribuir o conjunto de permissões a CodeCatalyst ECSUser** 1. No painel de navegação **Contas da AWS**, escolha e marque a caixa de seleção ao lado da caixa de seleção na Conta da AWS qual você está conectado no momento. 1. Escolha **Atribuir usuários ou grupos**. 1. Escolha a guia **Users**. 1. Marque a caixa de seleção ao lado dos logs do `CodeCatalystECSUser`. 1. Escolha **Próximo**. 1. Marque a caixa de seleção ao lado dos logs do `CodeCatalystECSPermissionSet`. 1. Escolha **Próximo**. 1. Revise suas informações e selecione **Enviar**. Agora você designou `CodeCatalystECSUser` e `CodeCatalystECSPermissionSet` para o seu Conta da AWS, unindo-os. **Para sair e entrar novamente como CodeCatalyst ECSUser** 1. Antes de sair, verifique se você tem a URL do portal de AWS acesso, o nome de usuário e a senha de uso único para`CodeCatalystECSUser`. Você deveria ter copiado essas informações para um editor de texto anteriormente. **nota** Se você não tiver essas informações, acesse a página de detalhes do `CodeCatalystECSUser` no IAM Identity Center, selecione **Redefinir senha**, **Gerar uma senha de uso único [...]** e **Redefinir senha** novamente para exibir as informações na tela. 1. Sair de AWS. 1. Cole o URL do portal de AWS acesso na barra de endereço do seu navegador. 1. Faça login com o nome de usuário e a senha de uso único para `CodeCatalystECSUser`. 1. Em **Nova senha**, insira uma senha e selecione **Definir nova senha**. Uma caixa de **Conta da AWS** aparece na tela. 1. Escolha e **Conta da AWS**, em seguida, escolha o nome do Conta da AWS ao qual você atribuiu o `CodeCatalystECSUser` usuário e o conjunto de permissões. 1. Ao lado de `CodeCatalystECSPermissionSet`, selecione **Console de gerenciamento**. O Console de gerenciamento da AWS aparece. Agora você está conectado como `CodeCatalystECSUser` com as permissões apropriadas. **Para iniciar uma AWS CloudShell instância** 1. Como`CodeCatalystECSUser`, na barra de navegação superior, escolha o AWS ícone (![\[AWS icon\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/deploy/aws-logo.png)). A página principal do Console de gerenciamento da AWS aparece. 1. Na barra de navegação superior, escolha o AWS CloudShell ícone (![\[CloudShell icon\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/deploy/CloudShell.png)). CloudShell abre. Aguarde enquanto o CloudShell ambiente é criado. **nota** Se você não vê o CloudShell ícone, verifique se você está em uma [região suportada pelo CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/faq-list.html#regions-available). Este tutorial pressupõe que você esteja na região do Oeste dos EUA (Oregon). **Para verificar se o AWS CLI está instalado** 1. No CloudShell terminal, digite: ``` aws --version ``` 1. Confira se uma versão é exibida. O já AWS CLI está configurado para o usuário atual`CodeCatalystECSUser`, portanto, não há necessidade de configurar AWS CLI chaves e credenciais, como é normalmente o caso. ## Etapa 2: implantar uma aplicação de espaço reservado no Amazon ECS Nesta seção, você implanta manualmente uma aplicação de espaço reservado no Amazon ECS. Essa aplicação de espaço reservado será substituída pela aplicação Hello World implantada pelo fluxo de trabalho. A aplicação de espaço reservado é o Apache Web Server. Para ter mais informações sobre o Amazon ECS, consulte o *Guia do desenvolvedor do Amazon Elastic Container Service*. Conclua a série de procedimentos a seguir para implantar a aplicação de espaço reservado. **Como criar o perfil de execução de tarefas** Essa função concede ao Amazon ECS AWS Fargate permissão para fazer chamadas de API em seu nome. 1. Crie uma política de confiança: 1. Em AWS CloudShell, digite o seguinte comando: ``` cat > codecatalyst-ecs-trust-policy.json ``` Um aviso piscando aparece no CloudShell terminal. 1. No prompt, insira o seguinte código: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ 1. Coloque o cursor após o último colchete (`}`). 1. Pressione **Enter** e, depois, **Ctrl\$1d** para salvar o arquivo e sair do cat. 1. Crie um perfil de execução de tarefas: ``` aws iam create-role \ --role-name codecatalyst-ecs-task-execution-role \ --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json ``` 1. Anexe a `AmazonECSTaskExecutionRolePolicy` política AWS gerenciada à função: ``` aws iam attach-role-policy \ --role-name codecatalyst-ecs-task-execution-role \ --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy ``` 1. Exiba os detalhes do perfil: ``` aws iam get-role \ --role-name codecatalyst-ecs-task-execution-role ``` 1. Observe o valor `"Arn":` do perfil, por exemplo, `arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role`. Você precisará desse nome do recurso da Amazon (ARN) posteriormente. **Para criar um cluster do Amazon ECS** Esse cluster conterá a aplicação de espaço reservado Apache e, posteriormente, a aplicação Hello World. 1. Como`CodeCatalystECSUser`, em AWS CloudShell, crie um cluster vazio: ``` aws ecs create-cluster --cluster-name codecatalyst-ecs-cluster ``` 1. (Opcional) Verifique se o cluster foi criado: ``` aws ecs list-clusters ``` O ARN do cluster `codecatalyst-ecs-cluster` deve aparecer na lista, indicando uma criação bem-sucedida. **Para criar um arquivo de definição de tarefa** O arquivo de definição da tarefa indica a execução da imagem Docker (`httpd:2.4`) [do servidor Web Apache 2.4](https://hub.docker.com/_/httpd), da qual foi extraída. DockerHub 1. Como`CodeCatalystECSUser`, em AWS CloudShell, crie um arquivo de definição de tarefa: ``` cat > taskdef.json ``` 1. No prompt, cole o seguinte código: ``` { "executionRoleArn": "arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role", "containerDefinitions": [ { "name": "codecatalyst-ecs-container", "image": "httpd:2.4", "essential": true, "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ] } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "256", "family": "codecatalyst-ecs-task-def", "memory": "512", "networkMode": "awsvpc" } ``` No código anterior, substitua *arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role* pelo ARN do perfil de execução da tarefa que você anotou em [Como criar o perfil de execução de tarefas](#deploy-tut-ecs-create-task-execution-role). 1. Coloque o cursor após o último colchete (`}`). 1. Pressione **Enter** e, depois, **Ctrl\$1d** para salvar o arquivo e sair do cat. **Para registrar o arquivo definição de tarefa com o Amazon ECS** 1. Como`CodeCatalystECSUser`, em AWS CloudShell, registre a definição da tarefa: ``` aws ecs register-task-definition \ --cli-input-json file://taskdef.json ``` 1. (Opcional) Verifique se a definição da tarefa foi registrada: ``` aws ecs list-task-definitions ``` A definição da tarefa `codecatalyst-ecs-task-def` deve aparecer na lista. **Para criar o serviço do Amazon ECS** O serviço Amazon ECS executa as tarefas (e os contêineres do Docker associados) da aplicação de espaço reservado Apache e, posteriormente, da aplicação Hello World. 1. Como `CodeCatalystECSUser`, mude para o console do Amazon Elastic Container Service, se você ainda não tiver feito isso. 1. Selecione o cluster que você criou antes, `codecatalyst-ecs-cluster`. 1. Na guia **Serviços**, selecione **Criar**. 1. Na página **Criar**, faça o seguinte: 1. Mantenha todas as configurações padrão, exceto as listadas a seguir. 1. Para **Launch type (Tipo de inicialização)**, escolha **FARGATE**. 1. Em **Definição de tarefa**, na lista suspensa **Família**, escolha: `codecatalyst-ecs-task-def` 1. Em **Nome do serviço**, digite: ``` codecatalyst-ecs-service ``` 1. Em **Tarefas desejadas**, digite: ``` 3 ``` Neste tutorial, cada tarefa inicia um único contêiner do Docker. 1. Expanda a seção **Rede**. 1. Em **VPC**, escolha qualquer VPC. 1. Em **Sub-redes**, escolha qualquer sub-rede. **nota** Especifique somente uma sub-rede. Isso é tudo o que é necessário para este tutorial. **nota** Se você não tiver uma VPC e uma sub-rede, crie-as. Consulte [Criar uma VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) e [Criar uma sub-rede na VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet) no *Guia do usuário da Amazon VPC*. 1. Em **Grupo de segurança**, selecione **Criar um grupo de segurança** e faça o seguinte: 1. Em **Nome do grupo de segurança**, digite: ``` codecatalyst-ecs-security-group ``` 1. Em **Descrição do grupo de segurança**, digite: ``` CodeCatalyst ECS security group ``` 1. Escolha **Adicionar regra**. Em **Tipo**, selecione **HTTP** e, em **Origem**, selecione **Qualquer lugar**. 1. Selecione **Criar** na parte inferior. 1. Aguarde enquanto o serviço é criado. Isso pode levar alguns minutos. 1. Escolha a guia **Tarefas** e escolha o botão de atualização. Verifique se as três tarefas têm a coluna **Último status** definida como **Em execução**. **(Opcional) Para verificar se a aplicação de espaço reservado Apache está em execução** 1. Na guia **Tarefas**, escolha qualquer uma das três tarefas. 1. No campo **IP público**, escolha **endereço aberto**. Uma página `It Works!` é exibida. Isso indica que o serviço Amazon ECS iniciou uma tarefa que executou um contêiner do Docker com a imagem do Apache. Neste ponto do tutorial, você implantou manualmente uma definição de cluster, serviço e tarefa do Amazon ECS, bem como uma aplicação de espaço reservado do Apache. Com todos esses itens prontos, agora você já pode criar um fluxo de trabalho que substituirá a aplicação de espaço reservado Apache pela aplicação Hello World do tutorial. ## Etapa 3: criar uma imagem de repositório do Amazon ECR Nesta seção, você cria um repositório de imagens privadas no Amazon Elastic Container Registry (Amazon ECR). Esse repositório armazena a imagem do Docker do tutorial que substituirá a imagem de espaço reservado do Apache que você implantou anteriormente. Para obter mais informações sobre o Amazon ECR, consulte o *Guia do usuário do Amazon Elastic Container Registry*. **Para criar um repositório de imagens no Amazon ECR** 1. Por `CodeCatalystECSUser` exemplo AWS CloudShell, crie um repositório vazio no Amazon ECR: ``` aws ecr create-repository --repository-name codecatalyst-ecs-image-repo ``` 1. Exiba os detalhes do repositório do Amazon ECR: ``` aws ecr describe-repositories \ --repository-names codecatalyst-ecs-image-repo ``` 1. Observe o valor `“repositoryUri”:`, por exemplo, `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`. Você precisará dele mais tarde ao adicionar o repositório ao seu fluxo de trabalho. ## Etapa 4: criar AWS funções Nesta seção, você cria funções AWS do IAM que seu CodeCatalyst fluxo de trabalho precisará para funcionar. Esses perfis são: + **Função de criação** — concede permissão à ação de CodeCatalyst criação (no fluxo de trabalho) para acessar sua AWS conta e gravar no Amazon ECR e no Amazon EC2. + **Função de implantação** — concede **à ação CodeCatalyst Deploy to ECS** (no fluxo de trabalho) permissão para acessar sua AWS conta, o Amazon ECS e alguns outros AWS serviços. Para ter informações sobre perfis do IAM, consulte [Perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) no *Guia do usuário do AWS Identity and Access Management *. **nota** Para economizar tempo, você pode criar um único perfil, chamado `CodeCatalystWorkflowDevelopmentRole-spaceName`, em vez dos dois perfis listados anteriormente. Para obter mais informações, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões bem amplas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Este tutorial pressupõe que você esteja criando os dois perfis listados anteriormente. Para criar as funções de criação e implantação, você pode usar Console de gerenciamento da AWS o. ou AWS CLI o. ------ #### [ Console de gerenciamento da AWS ] Para criar os perfis de criação e implantação, conclua a série de procedimentos a seguir. **Como criar um perfil de criação** 1. Crie uma política para o perfil da seguinte maneira: 1. Faça login em AWS. 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação, selecione **Políticas**. 1. Escolha **Criar política**. 1. Escolha a guia **JSON**. 1. Exclua o código existente. 1. Cole o seguinte código: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:*", "ec2:*" ], "Resource": "*" } ] } ``` ------ **nota** Na primeira vez em que o perfil for usado para executar ações de fluxo de trabalho, use o caractere curinga na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` 1. Escolha **Próximo: tags**. 1. Selecione **Próximo: revisar**. 1. Em **Nome**, insira: ``` codecatalyst-ecs-build-policy ``` 1. Selecione **Criar política**. Agora você criou uma política de permissões. 1. Crie o perfil de criação, da seguinte forma: 1. No painel de navegação, escolha **Perfis** e **Criar perfil**. 1. Selecione **Política de confiança personalizada**. 1. Exclua a política de confiança personalizada existente. 1. Adicione a política de confiança personalizada a seguir: 1. Escolha **Próximo**. 1. Em **Políticas de permissões**, procure `codecatalyst-ecs-build-policy` e marque a caixa de seleção. 1. Escolha **Próximo**. 1. Em **Nome do perfil**, insira: ``` codecatalyst-ecs-build-role ``` 1. Em **Descrição do perfil**, insira: ``` CodeCatalyst ECS build role ``` 1. Selecione **Criar perfil**. Agora você criou um perfil de criação com uma política de permissões e uma política de confiança. 1. Obtenha o ARN do perfil de criação, da seguinte forma: 1. No painel de navegação, escolha **Perfis**. 1. Na caixa de pesquisa, insira o nome do perfil que você acabou de criar (`codecatalyst-ecs-build-role`). 1. Escolha o perfil na lista. A página **Resumo** do perfil é exibida. 1. Na parte superior, copie o valor do **ARN**. Você precisará disso mais tarde. **Para criar um perfil de implantação** 1. Crie uma política para o perfil da seguinte maneira: 1. Faça login em AWS. 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação, selecione **Políticas**. 1. Escolha **Create Policy**. 1. Escolha a guia **JSON**. 1. Exclua o código existente. 1. Cole o seguinte código: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action":[ "ecs:DescribeServices", "ecs:CreateTaskSet", "ecs:DeleteTaskSet", "ecs:ListClusters", "ecs:RegisterTaskDefinition", "ecs:UpdateServicePrimaryTaskSet", "ecs:UpdateService", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:ModifyRule", "lambda:InvokeFunction", "lambda:ListFunctions", "cloudwatch:DescribeAlarms", "sns:Publish", "sns:ListTopics", "s3:GetObject", "s3:GetObjectVersion", "codedeploy:CreateApplication", "codedeploy:CreateDeployment", "codedeploy:CreateDeploymentGroup", "codedeploy:GetApplication", "codedeploy:GetDeployment", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "codedeploy:ListDeployments", "codedeploy:StopDeployment", "codedeploy:GetDeploymentTarget", "codedeploy:ListDeploymentTargets", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision", "codedeploy:BatchGetApplicationRevisions", "codedeploy:BatchGetDeploymentGroups", "codedeploy:BatchGetDeployments", "codedeploy:BatchGetApplications", "codedeploy:ListApplicationRevisions", "codedeploy:ListDeploymentConfigs", "codedeploy:ContinueDeployment" ], "Resource":"*", "Effect":"Allow" },{"Action":[ "iam:PassRole" ], "Effect":"Allow", "Resource":"*", "Condition":{"StringLike":{"iam:PassedToService":[ "ecs-tasks.amazonaws.com", "codedeploy.amazonaws.com" ] } } }] } ``` ------ **nota** Na primeira vez em que o perfil for usado para executar ações de fluxo de trabalho, use o caractere curinga na declaração de política de recursos. Em seguida, você pode definir o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` 1. Escolha **Próximo: tags**. 1. Selecione **Próximo: revisar**. 1. Em **Nome**, insira: ``` codecatalyst-ecs-deploy-policy ``` 1. Selecione **Criar política**. Agora você criou uma política de permissões. 1. Crie o perfil de implantação, da seguinte forma: 1. No painel de navegação, escolha **Perfis** e **Criar perfil**. 1. Selecione **Política de confiança personalizada**. 1. Exclua a política de confiança personalizada existente. 1. Adicione a política de confiança personalizada a seguir: 1. Escolha **Próximo**. 1. Em **Políticas de permissões**, procure `codecatalyst-ecs-deploy-policy` e marque a caixa de seleção. 1. Escolha **Próximo**. 1. Em **Nome do perfil**, insira: ``` codecatalyst-ecs-deploy-role ``` 1. Em **Descrição do perfil**, insira: ``` CodeCatalyst ECS deploy role ``` 1. Selecione **Criar perfil**. Agora você criou um perfil de implantação com uma política de confiança. 1. Obtenha o ARN do perfil de implantação, da seguinte forma: 1. No painel de navegação, escolha **Perfis**. 1. Na caixa de pesquisa, insira o nome do perfil que você acabou de criar (`codecatalyst-ecs-deploy-role`). 1. Escolha o perfil na lista. A página **Resumo** do perfil é exibida. 1. Na parte superior, copie o valor do **ARN**. Você precisará disso mais tarde. ------ #### [ AWS CLI ] Para criar os perfis de criação e implantação, conclua a série de procedimentos a seguir. **Para criar uma política de confiança para os dois perfis** Por `CodeCatalystECSUser` exemplo AWS CloudShell, crie um arquivo de política de confiança: 1. Crie o arquivo: ``` cat > codecatalyst-ecs-trust-policy.json ``` 1. No prompt do terminal, cole o seguinte código: 1. Coloque o cursor após o último colchete (`}`). 1. Pressione **Enter** e, depois, **Ctrl\$1d** para salvar o arquivo e sair do cat. **Para criar a política de criação e o perfil de criação** 1. Crie a política de criação: 1. Por `CodeCatalystECSUser` exemplo AWS CloudShell, crie um arquivo de política de compilação: ``` cat > codecatalyst-ecs-build-policy.json ``` 1. No prompt, insira o seguinte código: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:*", "ec2:*" ], "Resource": "*" } ] } ``` ------ 1. Coloque o cursor após o último colchete (`}`). 1. Pressione **Enter** e, depois, **Ctrl\$1d** para salvar o arquivo e sair do cat. 1. Adicione a política de compilação a AWS: ``` aws iam create-policy \ --policy-name codecatalyst-ecs-build-policy \ --policy-document file://codecatalyst-ecs-build-policy.json ``` 1. Na saída do comando, observe o valor `"arn":`, por exemplo, `arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy`. Esse ARN será necessário posteriormente. 1. Crie o perfil de criação e anexe a política de confiança a ele: ``` aws iam create-role \ --role-name codecatalyst-ecs-build-role \ --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json ``` 1. Anexe a política de criação à função de criação: ``` aws iam attach-role-policy \ --role-name codecatalyst-ecs-build-role \ --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy ``` Onde *arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy* é substituído pelo ARN da política de construção que você observou anteriormente. 1. Exiba os detalhes do perfil de criação: ``` aws iam get-role \ --role-name codecatalyst-ecs-build-role ``` 1. Observe o valor `"Arn":` do perfil, por exemplo, `arn:aws:iam::111122223333:role/codecatalyst-ecs-build-role`. Esse ARN será necessário posteriormente. **Para criar a política e o perfil de implantação** 1. Crie uma política de implantação: 1. Em AWS CloudShell, crie um arquivo de política de implantação: ``` cat > codecatalyst-ecs-deploy-policy.json ``` 1. No prompt, insira o seguinte código: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action":[ "ecs:DescribeServices", "ecs:CreateTaskSet", "ecs:DeleteTaskSet", "ecs:ListClusters", "ecs:RegisterTaskDefinition", "ecs:UpdateServicePrimaryTaskSet", "ecs:UpdateService", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:ModifyRule", "lambda:InvokeFunction", "lambda:ListFunctions", "cloudwatch:DescribeAlarms", "sns:Publish", "sns:ListTopics", "s3:GetObject", "s3:GetObjectVersion", "codedeploy:CreateApplication", "codedeploy:CreateDeployment", "codedeploy:CreateDeploymentGroup", "codedeploy:GetApplication", "codedeploy:GetDeployment", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "codedeploy:ListDeployments", "codedeploy:StopDeployment", "codedeploy:GetDeploymentTarget", "codedeploy:ListDeploymentTargets", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision", "codedeploy:BatchGetApplicationRevisions", "codedeploy:BatchGetDeploymentGroups", "codedeploy:BatchGetDeployments", "codedeploy:BatchGetApplications", "codedeploy:ListApplicationRevisions", "codedeploy:ListDeploymentConfigs", "codedeploy:ContinueDeployment" ], "Resource":"*", "Effect":"Allow" },{"Action":[ "iam:PassRole" ], "Effect":"Allow", "Resource":"*", "Condition":{"StringLike":{"iam:PassedToService":[ "ecs-tasks.amazonaws.com", "codedeploy.amazonaws.com" ] } } }] } ``` ------ **nota** Na primeira vez em que o perfil for usado para executar ações de fluxo de trabalho, use o caractere curinga na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` 1. Coloque o cursor após o último colchete (`}`). 1. Pressione **Enter** e, depois, **Ctrl\$1d** para salvar o arquivo e sair do cat. 1. Adicione a política de implantação a AWS: ``` aws iam create-policy \ --policy-name codecatalyst-ecs-deploy-policy \ --policy-document file://codecatalyst-ecs-deploy-policy.json ``` 1. Na saída do comando, observe o valor `"arn":` da política de implantação, por exemplo, `arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy`. Esse ARN será necessário posteriormente. 1. Crie o perfil de implantação e anexe a política de confiança a ele: ``` aws iam create-role \ --role-name codecatalyst-ecs-deploy-role \ --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json ``` 1. Anexe a política de implantação à função de implantação, que *arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy* é substituída pelo ARN da política de implantação que você anotou anteriormente. ``` aws iam attach-role-policy \ --role-name codecatalyst-ecs-deploy-role \ --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy ``` 1. Exiba os detalhes do perfil de implantação: ``` aws iam get-role \ --role-name codecatalyst-ecs-deploy-role ``` 1. Observe o valor `"Arn":` do perfil, por exemplo, `arn:aws:iam::111122223333:role/codecatalyst-ecs-deploy-role`. Esse ARN será necessário posteriormente. ------ ## Etapa 5: adicionar AWS funções a CodeCatalyst Nesta etapa, você adiciona a função de criação (`codecatalyst-ecs-build-role`) e a função de implantação (`codecatalyst-ecs-deploy-role`) à conexão da CodeCatalyst conta em seu espaço. **Para adicionar perfis de criação e implantação à conexão da sua conta** 1. Dentro CodeCatalyst, navegue até seu espaço. 1. Selecione **Contas da AWS **. Uma lista de conexões de conta é exibida. 1. Escolha a conexão de conta que representa a AWS conta em que você criou suas funções de criação e implantação. 1. Escolha **Gerenciar funções no console de AWS gerenciamento**. A página **Adicionar função do IAM ao CodeCatalyst espaço da Amazon** é exibida. Talvez seja necessário fazer login para acessá-la. 1. Selecione **Adicionar um perfil existente que você criou no IAM**. Uma lista suspensa aparece. A lista exibe todos os perfis do IAM com uma política de confiança que inclui as entidades principais de serviço `codecatalyst-runner.amazonaws.com` e `codecatalyst.amazonaws.com`. 1. Na lista suspensa, selecione `codecatalyst-ecs-build-role` e **Adicionar perfil**. **nota** Se você vir `The security token included in the request is invalid`, pode ser porque você não tem as permissões corretas. Para corrigir esse problema, saia e faça login novamente com a AWS conta que você usou ao criar seu CodeCatalyst espaço. AWS 1. Escolha **Adicionar perfil do IAM**, selecione **Adicionar um perfil existente que você criou no IAM** e, na lista suspensa, escolha `codecatalyst-ecs-deploy-role`. Escolha **Add role (adicionar função)**. Agora você adicionou os perfis de criação e implantação ao seu espaço. 1. Copie o valor do **nome de CodeCatalyst exibição da Amazon**. Esse valor será necessário posteriormente, ao criar seu fluxo de trabalho. ## Etapa 6: criar um repositório de origem Nesta etapa, você cria um repositório de origem no CodeCatalyst. Esse repositório armazena os arquivos de origem do tutorial, como o arquivo de definição da tarefa. Para ter mais informações sobre repositórios de origem, consulte [Criar um repositório de origem](source-repositories-create.md). **Como criar um repositório de origem** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Navegue até o projeto, `codecatalyst-ecs-project`. 1. No painel de navegação, selecione **Código** e, em seguida, selecione **Repositórios de origem**. 1. Escolha **Adicionar repositório** e selecione **Criar repositório**. 1. Em **Nome do repositório**, insira: ``` codecatalyst-ecs-source-repository ``` 1. Escolha **Criar**. ## Etapa 7: adicionar arquivos de origem Nesta seção, você adiciona os arquivos de origem do Hello World ao seu CodeCatalyst repositório,`codecatalyst-ecs-source-repository`. Eles consistem em: + Um arquivo `index.html` - Exibe uma mensagem do Hello World no navegador. + Um Dockerfile: descreve a imagem básica a ser usada para sua imagem do Docker e os comandos do Docker a serem aplicados a ela. + Um arquivo `taskdef.json` - Define a imagem do Docker a ser usada ao iniciar tarefas em seu cluster. A estrutura de pastas é esta: ``` . |— public-html | |— index.html |— Dockerfile |— taskdef.json ``` **nota** As instruções a seguir mostram como adicionar os arquivos usando o CodeCatalyst console, mas você pode usar o Git se preferir. Para obter detalhes, consulte [Clonar um repositório de origem](source-repositories-clone.md). **Topics** + [ ### index.html ](#deploy-tut-ecs-source-files-index) + [ ### Dockerfile ](#deploy-tut-ecs-source-files-dockerfile) + [ ### taskdef.json ](#deploy-tut-ecs-source-files-taskdef) ### index.html O arquivo `index.html` exibe uma mensagem do Hello World no navegador. **Como adicionar o arquivo index.html** 1. No CodeCatalyst console, acesse seu repositório de origem,`codecatalyst-ecs-source-repository`. 1. Em **Arquivos**, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` public-html/index.html ``` **Importante** Inclua o prefixo `public-html/` para criar uma pasta com o mesmo nome. Espera-se que `index.html` esteja nessa pasta. 1. Na caixa de texto, insira o código a seguir: ``` Hello World

Hello World

``` 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. O `index.html` é adicionado ao seu repositório em uma pasta `public-html`. ### Dockerfile O Dockerfile descreve a imagem base do Docker a ser usada e os comandos do Docker a serem aplicados a ela. Para ter mais informações sobre o Dockerfile, consulte a [Referência de Dockerfile](https://docs.docker.com/engine/reference/builder/). O Dockerfile especificado aqui indica o uso da imagem base do Apache 2.4 (`httpd`). Também inclui instruções para copiar um arquivo fonte chamado `index.html` para uma pasta no servidor Apache que serve páginas da Web. A instrução `EXPOSE` no Dockerfile diz ao Docker que o contêiner está escutando na porta 80. **Para adicionar o Dockerfile** 1. No repositório de origem, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` Dockerfile ``` Não inclua uma extensão de arquivo. **Importante** O Dockerfile deve residir na pasta raiz do repositório. O comando `Docker build` do fluxo de trabalho espera que ele esteja lá. 1. Na caixa de texto, insira o código a seguir: ``` FROM httpd:2.4 COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html EXPOSE 80 ``` 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. O Dockerfile é adicionado ao repositório. ### taskdef.json O arquivo `taskdef.json` que você adiciona nessa etapa é o mesmo que você já especificou em [Etapa 2: implantar uma aplicação de espaço reservado no Amazon ECS](#deploy-tut-ecs-placeholder) com a seguinte diferença: Em vez de especificar um nome de imagem do Docker codificado no campo `image:` (`httpd:2.4`), a definição da tarefa aqui usa algumas variáveis para indicar a imagem: `$REPOSITORY_URI` e `$IMAGE_TAG`. Essas variáveis serão substituídas por valores reais gerados pela ação de criação do fluxo de trabalho quando você executar o fluxo de trabalho em uma etapa posterior. Para saber detalhes sobre os parâmetros de definição de tarefa, consulte [Parâmetros de definição de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. **Como adicionar o arquivo taskdef.json** 1. No repositório de origem, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` taskdef.json ``` 1. Na caixa de texto, insira o código a seguir: ``` { "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role", "containerDefinitions": [ { "name": "codecatalyst-ecs-container", # The $REPOSITORY_URI and $IMAGE_TAG variables will be replaced # by the workflow at build time (see the build action in the # workflow) "image": $REPOSITORY_URI:$IMAGE_TAG, "essential": true, "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ] } ], "requiresCompatibilities": [ "FARGATE" ], "networkMode": "awsvpc", "cpu": "256", "memory": "512", "family": "codecatalyst-ecs-task-def" } ``` No código anterior, substitua *arn:aws:iam::account\$1ID:role/codecatalyst-ecs-task-execution-role* pelo ARN do perfil de execução da tarefa que você anotou em [Como criar o perfil de execução de tarefas](#deploy-tut-ecs-create-task-execution-role). 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. O arquivo `taskdef.json` é adicionado ao repositório. ## Etapa 8: criar e executar um fluxo de trabalho Nesta etapa, você cria um fluxo de trabalho que pega seus arquivos de origem, os cria em uma imagem do Docker e, depois, implanta a imagem no seu cluster do Amazon ECS. Essa implantação substitui a aplicação de espaço reservado Apache existente. O fluxo de trabalho consiste nos seguintes blocos de compilação que são executados sequencialmente: + Um gatilho: esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + Uma ação de criação (`BuildBackend`) – No gatilho, a ação cria a imagem do Docker usando o Dockerfile e envia a imagem para o Amazon ECR. A ação de criação também atualiza o `taskdef.json` com o valor de campo `image` correto e, depois, cria um artefato de saída desse arquivo. Esse artefato é usado como entrada para a ação de implantação, que será a seguir. Para ter mais informações sobre a ação de criação, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). + Uma ação de implantação (`DeployToECS`): ao concluir a ação de criação, a ação de implantação procura o artefato de saída gerado pela ação de criação (`TaskDefArtifact`), encontra o `taskdef.json` dentro dele e o registra no seu serviço do Amazon ECS. Em seguida, o serviço segue as instruções no arquivo `taskdef.json` para executar três tarefas do Amazon ECS – e os contêineres do Docker do Hello World associados – dentro do seu cluster do Amazon ECS. **Para criar um fluxo de trabalho** 1. **No CodeCatalyst console, no painel de navegação, escolha **CI/CD** e, em seguida, escolha Fluxos de trabalho.** 1. Selecione **Criar fluxo de trabalho**. 1. Em **Repositório de origem**, selecione `codecatalyst-ecs-source-repository`. 1. Em **Ramificação**, selecione `main`. 1. Escolha **Criar**. 1. Exclua o código de amostra YAML. 1. Adicione o seguinte código YAML: **nota** No código YAML a seguir, você pode omitir as seções `Connections:` se quiser. Se você omitir essas seções, deverá garantir que o perfil especificado no campo **Perfil do IAM padrão** em seu ambiente inclua as permissões e as políticas de confiança dos dois perfis descritas em [Etapa 5: adicionar AWS funções a CodeCatalyst](#deploy-tut-ecs-import-roles). Para ter mais informações sobre como configurar um ambiente com um perfil do IAM padrão, consulte [Criar um ambiente](deploy-environments-creating-environment.md). ``` Name: codecatalyst-ecs-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: BuildBackend: Identifier: aws/build@v1 Environment: Name: codecatalyst-ecs-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-ecs-build-role Inputs: Sources: - WorkflowSource Variables: - Name: REPOSITORY_URI Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo - Name: IMAGE_TAG Value: ${WorkflowSource.CommitId} Configuration: Steps: #pre_build: - Run: echo Logging in to Amazon ECR... - Run: aws --version - Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com #build: - Run: echo Build started on `date` - Run: echo Building the Docker image... - Run: docker build -t $REPOSITORY_URI:latest . - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG #post_build: - Run: echo Build completed on `date` - Run: echo Pushing the Docker images... - Run: docker push $REPOSITORY_URI:latest - Run: docker push $REPOSITORY_URI:$IMAGE_TAG # Replace the variables in taskdef.json - Run: find taskdef.json -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g" - Run: find taskdef.json -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g" - Run: cat taskdef.json # The output artifact will be a zip file that contains a task definition file. Outputs: Artifacts: - Name: TaskDefArtifact Files: - taskdef.json DeployToECS: DependsOn: - BuildBackend Identifier: aws/ecs-deploy@v1 Environment: Name: codecatalyst-ecs-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-ecs-deploy-role Inputs: Sources: [] Artifacts: - TaskDefArtifact Configuration: region: us-west-2 cluster: codecatalyst-ecs-cluster service: codecatalyst-ecs-service task-definition: taskdef.json ``` No código anterior, substitua: + Ambas as instâncias de *codecatalyst-ecs-environment* com o nome do ambiente em que você criou[Pré-requisitos](#deploy-tut-ecs-prereqs). + Ambas as instâncias *codecatalyst-account-connection* com o nome de exibição da conexão da sua conta. O nome de exibição pode ser um número. Para obter mais informações, consulte [Etapa 5: adicionar AWS funções a CodeCatalyst](#deploy-tut-ecs-import-roles). + *codecatalyst-ecs-build-role*com o nome da função de construção em que você criou[Etapa 4: criar AWS funções](#deploy-tut-ecs-build-deploy-roles). + *111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo*(na `Value:` propriedade) com o URI do repositório Amazon ECR em que você criou. [Etapa 3: criar uma imagem de repositório do Amazon ECR](#deploy-tut-ecs-ecr) + *111122223333.dkr.ecr.us-west-2.amazonaws.com*(no `Run: aws ecr` comando) com o URI do repositório Amazon ECR sem o sufixo da imagem (). `/codecatalyst-ecs-image-repo` + *codecatalyst-ecs-deploy-role*com o nome da função de implantação na qual você criou[Etapa 4: criar AWS funções](#deploy-tut-ecs-build-deploy-roles). + Ambas as instâncias *us-west-2* com seu código de AWS região. Para ver uma lista de códigos de região, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints) na *Referência geral da AWS*. **nota** Se você decidiu não criar e implantar funções, *codecatalyst-ecs-deploy-role* substitua *codecatalyst-ecs-build-role* e pelo nome da `CodeCatalystWorkflowDevelopmentRole-spaceName` função. Para obter mais informações sobre esse perfil, consulte [Etapa 4: criar AWS funções](#deploy-tut-ecs-build-deploy-roles). **dica** Em vez de usar os comandos `find` e `sed` mostrados no código do fluxo de trabalho anterior para atualizar o nome do repositório e da imagem, você pode usar a ação de definição de tarefas **Renderizar Amazon ECS** para essa finalidade. Para obter mais informações, consulte [Modificação de uma definição de tarefa do Amazon ECS](render-ecs-action.md). 1. (Opcional) Selecione **Validar** para garantir que o código YAML seja válido antes de confirmar. 1. Selecione **Confirmar**. 1. Na caixa de diálogo **Confirmar fluxo de trabalho**, insira o seguinte: 1. Em **Mensagem de confirmação**, remova o texto e digite: ``` Add first workflow ``` 1. Em **Repositório**, selecione `codecatalyst-ecs-source-repository`. 1. Em **Nome da ramificação**, selecione a principal. 1. Selecione **Confirmar**. Agora você criou um fluxo de trabalho. A execução de um fluxo de trabalho é iniciada automaticamente devido ao gatilho definido na parte superior do fluxo de trabalho. Especificamente, quando você confirmou (e enviou) o arquivo `workflow.yaml` ao repositório de origem, o gatilho iniciou a execução do fluxo de trabalho. **Para visualizar o andamento da execução do fluxo de trabalho** 1. **No painel de navegação do CodeCatalyst console, escolha **CI/CD** e, em seguida, escolha Fluxos de trabalho.** 1. Escolha o fluxo de trabalho que você acabou de criar, `codecatalyst-ecs-workflow`. 1. Escolha **BuildBackend**ver o progresso da construção. 1. Escolha o **DeployToECS** para ver o progresso da implantação. Para ter mais informações sobre como visualizar os detalhes da execução, consulte o [Visualização do status e detalhes de execução do fluxo de trabalho](workflows-view-run.md). **Como verificar a implantação** 1. Abra o console clássico do Amazon ECS em [https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/). 1. Escolha seu cluster, `codecatalyst-ecs-cluster`. 1. Escolha a guia **Tasks (Tarefas)**. 1. Escolha qualquer uma das três tarefas. 1. No campo **IP público**, escolha **endereço aberto**. Uma página “Hello World” aparece no navegador, indicando que o serviço Amazon ECS implantou a aplicação. ## Etapa 9: realizar uma alteração nos arquivos de origem Nesta seção, você faz uma alteração no arquivo `index.html` no repositório de origem. Essa alteração faz com que o fluxo de trabalho crie uma nova imagem do Docker, a marque com um ID de confirmação, a envie por push ao Amazon ECR e a implante no Amazon ECS. **Para alterar o index.html** 1. No CodeCatalyst console, no painel de navegação, escolha **Código**, escolha **Repositórios de origem** e, em seguida, escolha seu repositório. `codecatalyst-ecs-source-repository` 1. Escolha `public-html` e, depois, escolha `index.html`. O conteúdo de `index.html` aparece. 1. Escolha **Editar**. 1. Na linha 14, altere o texto `Hello World` para `Tutorial complete!`. 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. A confirmação faz com que uma nova execução do fluxo de trabalho seja iniciada. 1. (Opcional) Acesse a página principal do repositório de origem, selecione **Exibir confirmações** e anote o ID da confirmação da alteração em `index.html`. 1. Assista ao andamento da implantação: 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha `codecatalyst-ecs-workflow` para ver a última execução. 1. Escolha **BuildBackend**e **DeployToECS** para ver o progresso da execução do fluxo de trabalho. 1. Verifique se a aplicação foi atualizada, da seguinte forma: 1. Abra o console clássico do Amazon ECS em [https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/). 1. Escolha seu cluster, `codecatalyst-ecs-cluster`. 1. Escolha a guia **Tasks (Tarefas)**. 1. Escolha qualquer uma das três tarefas. 1. No campo **IP público**, escolha **endereço aberto**. Uma página `Tutorial complete!` é exibida. 1. (Opcional) Em AWS, mude para o console do Amazon ECR e verifique se a nova imagem do Docker foi marcada com o ID de confirmação da etapa 6. ## Limpeza Limpe os arquivos e serviços usados neste tutorial para evitar cobranças por eles. No Console de gerenciamento da AWS, limpe nesta ordem: 1. No Amazon ECS, faça o seguinte: 1. Exclua `codecatalyst-ecs-service`. 1. Exclua `codecatalyst-ecs-cluster`. 1. Cancelar registro de `codecatalyst-ecs-task-definition`. 1. No Amazon ECR, exclua `codecatalyst-ecs-image-repo`. 1. No Amazon EC2, exclua `codecatalyst-ecs-security-group`. 1. No IAM Identity Center, exclua: 1. `CodeCatalystECSUser` 1. `CodeCatalystECSPermissionSet` No CodeCatalyst console, limpe da seguinte forma: 1. Exclua `codecatalyst-ecs-workflow`. 1. Exclua `codecatalyst-ecs-environment`. 1. Exclua `codecatalyst-ecs-source-repository`. 1. Exclua `codecatalyst-ecs-project`. Neste tutorial, você aprendeu a implantar um aplicativo em um serviço do Amazon ECS usando um CodeCatalyst fluxo de trabalho e uma ação **Deploy to Amazon ECS.** # Adição da ação “Implantar no Amazon ECS” Use as instruções a seguir para adicionar a ação **Implantar no Amazon ECS** ao seu fluxo de trabalho. ------ #### [ Visual ] **Para adicionar a ação “Implantar no Amazon ECS” usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Implantar no Amazon ECS** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Implantar no Amazon ECS**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Download** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [YAML de ação “Implantar no Amazon ECS”](deploy-action-ref-ecs.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar a ação “Implantar no Amazon ECS” usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Implantar no Amazon ECS** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Implantar no Amazon ECS**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Download** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [YAML de ação “Implantar no Amazon ECS”](deploy-action-ref-ecs.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Variáveis de “Implantar no Amazon ECS” A ação **Implantar no Amazon ECS** produz e define as seguintes variáveis em runtime. Elas são conhecidas como *variáveis predefinidas*. Para ter informações sobre como referenciar essas variáveis em um fluxo de trabalho, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). | Chave | Valor | | --- | --- | | cluster | O nome do cluster do Amazon ECS no qual foi implantado durante a execução do fluxo de trabalho. Exemplo: `codecatalyst-ecs-cluster` | | deployment-platform | O nome da plataforma de implantação. Codificado para `AWS:ECS`. | | service | O nome do serviço do Amazon ECS no qual foi implantado durante a execução do fluxo de trabalho. Exemplo: `codecatalyst-ecs-service` | | task-definition-arn | O nome do recurso da Amazon (ARN) da definição de tarefa que foi registrada durante a execução do fluxo de trabalho. Exemplo: `arn:aws:ecs:us-west-2:111122223333:task-definition/codecatalyst-task-def:8`O `:8` no exemplo anterior indica a revisão que foi registrada. | | deployment-url | Um link para a guia **Eventos** do console do Amazon ECS, onde você pode ver detalhes da implantação do Amazon ECS associada à execução do fluxo de trabalho. Exemplo: `https://console.aws.amazon.com/ecs/home?region=us-west-2#/clusters/codecatalyst-ecs-cluster/services/codecatalyst-ecs-service/events` | | region | O código da região em Região da AWS que foi implantado durante a execução do fluxo de trabalho. Exemplo: `us-west-2` | # YAML de ação “Implantar no Amazon ECS” Confira a seguir a definição de YAML da ação **Implantar no Amazon ECS**. Para saber como usar essa ação, consulte [Implantação no Amazon ECS com um fluxo de trabalho](deploy-action-ecs.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. ECSDeployAction\$1nn: Identifier: aws/ecs-deploy@v1 DependsOn: - build-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - task-definition-artifact Configuration: region: us-east-1 cluster: ecs-cluster service: ecs-service task-definition: task-definition-path force-new-deployment: false|true codedeploy-appspec: app-spec-file-path codedeploy-application: application-name codedeploy-deployment-group: deployment-group-name codedeploy-deployment-description: deployment-description ``` ## ECSDeployAction (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Padrão: `ECSDeployAction_nn`. Interface de usuário correspondente: guia Configuração/**Nome de exibição da ação** ## Identifier (*ECSDeployAction*/**Identifier**) (Obrigatório) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Padrão: `aws/ecs-deploy@v1`. **UI correspondente: diagrama de fluxo de ECSDeploy trabalho/Action\$1NN/aws/ecs-deploy @v1 label** ## DependsOn (*ECSDeployAction*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*ECSDeployAction*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*ECSDeployAction*/Compute/**Type**) (Obrigatório se [Compute](#deploy.action.ecs.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2** (editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). **UI correspondente: Configuração tab/Advanced - opcional/Tipo de computação** ## Fleet (*ECSDeployAction*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. **UI correspondente: configuração tab/Advanced - opcional/frota de computação** ## Timeout (*ECSDeployAction*/**Timeout**) (Optional) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Environment (*ECSDeployAction*/**Environment**) (Obrigatório) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*ECSDeployAction*/Environment/**Name**) (Obrigatório se [Environment](#deploy.action.ecs.environment) for incluído) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*ECSDeployAction*/Environment/**Connections**) (Opcional nas versões mais recentes da ação; obrigatório nas versões mais antigas) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Name (*ECSDeployAction*/Environment/Connections/**Name**) (Obrigatório se [Connections](#deploy.action.ecs.environment.connections) for incluído) Especifique o nome da conexão da conta. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Role (*ECSDeployAction*/Environment/Connections/**Role**) (Obrigatório se [Connections](#deploy.action.ecs.environment.connections) for incluído) Especifique o nome do perfil do IAM que a ação **Implantar no Amazon ECS** usa para acessar a AWS. Certifique-se de ter [adicionado a função ao seu CodeCatalyst espaço](ipa-connect-account-addroles.md) e de que a função inclua as seguintes políticas. Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas a seguir. + A política de permissões a seguir: **Atenção** Limite as permissões às exibidas na política a seguir. Usar um perfil com permissões mais amplas pode representar um risco de segurança. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action":[ "ecs:DescribeServices", "ecs:CreateTaskSet", "ecs:DeleteTaskSet", "ecs:ListClusters", "ecs:RegisterTaskDefinition", "ecs:UpdateServicePrimaryTaskSet", "ecs:UpdateService", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:ModifyRule", "lambda:InvokeFunction", "lambda:ListFunctions", "cloudwatch:DescribeAlarms", "sns:Publish", "sns:ListTopics", "s3:GetObject", "s3:GetObjectVersion", "codedeploy:CreateApplication", "codedeploy:CreateDeployment", "codedeploy:CreateDeploymentGroup", "codedeploy:GetApplication", "codedeploy:GetDeployment", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "codedeploy:ListDeployments", "codedeploy:StopDeployment", "codedeploy:GetDeploymentTarget", "codedeploy:ListDeploymentTargets", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision", "codedeploy:BatchGetApplicationRevisions", "codedeploy:BatchGetDeploymentGroups", "codedeploy:BatchGetDeployments", "codedeploy:BatchGetApplications", "codedeploy:ListApplicationRevisions", "codedeploy:ListDeploymentConfigs", "codedeploy:ContinueDeployment" ], "Resource":"*", "Effect":"Allow" },{"Action":[ "iam:PassRole" ], "Effect":"Allow", "Resource":"*", "Condition":{"StringLike":{"iam:PassedToService":[ "ecs-tasks.amazonaws.com", "codedeploy.amazonaws.com" ] } } }] } ``` ------ **nota** Na primeira vez em que o perfil for usado, use o caractere curinga a seguir na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` + A política de confiança personalizada a seguir: **nota** Você pode usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação, se desejar. Para obter mais informações sobre esse perfil, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' '/ Função Environment/account/role** ## Inputs (*ECSDeployAction*/**Inputs**) (Optional) A seção `Inputs` define os dados que `ECSDeployAction` precisa durante a execução de um fluxo de trabalho. **nota** Somente uma entrada (uma origem ou um artefato) é permitida por ação **Implantar no Amazon ECS**. Interface de usuário correspondente: guia **Entradas** ## Sources (*ECSDeployAction*/Inputs/**Sources**) (Obrigatório se o arquivo de definição de tarefas estiver armazenado em um repositório de origem) Se seu arquivo de definição de tarefa estiver armazenado em um repositório de origem, especifique o rótulo do repositório de origem. Atualmente, o único rótulo compatível é `WorkflowSource`. Se seu arquivo de definição de tarefa não estiver em um repositório de origem, ele deverá residir em um artefato gerado por outra ação. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*ECSDeployAction*/Inputs/**Artifacts**) (Obrigatório se o arquivo de definição de tarefa estiver armazenado em um [artefato de saída](workflows-working-artifacts-output.md) de uma ação anterior) Se o arquivo de definição de tarefa que você deseja implantar estiver em um artefato gerado por uma ação anterior, especifique esse artefato aqui. Se seu arquivo de definição de tarefa não estiver em um artefato, ele deverá residir em seu repositório de origem. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Configuração/**Artefatos - opcional** ## Configuration (*ECSDeployAction*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## region (Configuration/**region**) (Obrigatório) Especifique a AWS região em que seu cluster e serviço do Amazon ECS residem. Para ver uma lista de códigos de região, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints) na *Referência geral da AWS*. Interface de usuário correspondente: guia Configuração/**Região** ## cluster (*ECSDeployAction*/Configuration/**cluster**) (Obrigatório) Especifique o nome de um cluster existente do Amazon ECS. A ação **Implantar no Amazon ECS** implantará a aplicação em contêineres como uma tarefa nesse cluster. Para ter mais informações sobre clusters do Amazon ECS, consulte [Clusters](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Interface de usuário correspondente: guia Configuração/**Cluster** ## service (*ECSDeployAction*/Configuration/**service**) (Obrigatório) Especifique o nome de um serviço do Amazon ECS existente que instanciará o arquivo de definição de tarefas. Esse serviço deve residir no cluster especificado no campo `cluster`. Para ter mais informações sobre serviços do Amazon ECS, consulte [Serviços do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Interface de usuário correspondente: guia Configuração/**Serviço** ## task-definition (*ECSDeployAction*/Configuration/**task-definition**) (Obrigatório) Especifique o caminho para um arquivo de definição de tarefa existente. Se o arquivo residir em seu repositório de origem, o caminho é relativo à pasta raiz do repositório de origem. Se o arquivo residir em um artefato de uma ação anterior do fluxo de trabalho, o caminho é relativo à pasta raiz do artefato. Para ter mais informações sobre os arquivos de definição de tarefa, consulte [Definições de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Interface de usuário correspondente: guia Configuração/**Definição de tarefa** ## force-new-deployment (*ECSDeployAction*/Configuration/**force-new-deployment**) (Obrigatório) Se habilitado, o serviço do Amazon ECS poderá iniciar novas implantações sem alterações na definição do serviço. Forçar uma implantação faz com que o serviço interrompa todas as tarefas atualmente em execução e inicie novas tarefas. Para ter mais informações sobre como forçar novas implantações, consulte [Atualização de um serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html), no *Guia do desenvolvedor do Amazon Elastic Container Service*. Padrão: `false` Interface de usuário correspondente: guia Configuração/**Forçar uma nova implantação do serviço** ## codedeploy-appspec (*ECSDeployAction*/Configuration/**codedeploy-appspec**) (Obrigatório se você configurou seu serviço Amazon ECS para usar blue/green implantações; caso contrário, omita) Especifique o nome e o caminho para um arquivo de especificação de CodeDeploy aplicativo existente (AppSpec). Esse arquivo deve residir na raiz do seu repositório de CodeCatalyst origem. Para obter mais informações sobre AppSpec arquivos, consulte os [arquivos de especificação do CodeDeploy aplicativo (AppSpec)](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) no *Guia AWS CodeDeploy do usuário*. **nota** Forneça CodeDeploy informações somente se você tiver configurado seu serviço Amazon ECS para realizar blue/green implantações. Para implantações de atualizações contínuas (o padrão), CodeDeploy omita as informações. Para ter mais informações sobre implantações do Amazon ECS, consulte [Tipos de implantação do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html), no *Guia do Desenvolvedor do Amazon Elastic Container Service*. **nota** Os **CodeDeploy**campos podem estar ocultos no editor visual. Para fazer com que apareçam, consulte [Por que os CodeDeploy campos estão ausentes no editor visual?](troubleshooting-workflows.md#troubleshooting-workflows-codedeploy). UI correspondente: guia Configuração/ **CodeDeploy AppSpec** ## codedeploy-application (*ECSDeployAction*/Configuration/**codedeploy-application**) (Obrigatório se `codedeploy-appspec` for incluído) Especifique o nome de um CodeDeploy aplicativo existente. Para obter mais informações sobre CodeDeploy aplicativos, consulte Como [trabalhar com aplicativos CodeDeploy no](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications.html) *Guia do AWS CodeDeploy usuário*. **UI correspondente: guia de configuração/aplicativo CodeDeploy ** ## codedeploy-deployment-group (*ECSDeployAction*/Configuration/**codedeploy-deployment-group**) (Obrigatório se `codedeploy-appspec` for incluído) Especifique o nome de um grupo CodeDeploy de implantação existente. Para obter mais informações sobre grupos de CodeDeploy implantação, consulte [Trabalhando com grupos de implantação CodeDeploy no](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) *Guia AWS CodeDeploy do Usuário*. UI correspondente: guia de configuração/grupo **CodeDeploy de implantação** ## codedeploy-deployment-description (*ECSDeployAction*/Configuration/**codedeploy-deployment-description**) (Optional) Especifique uma descrição da implantação que essa ação criará. Para obter mais informações, consulte Como [trabalhar com implantações CodeDeploy no](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments.html) *Guia do AWS CodeDeploy usuário*. UI correspondente: guia de configuração/descrição **CodeDeploy da implantação** # Implantar no Amazon EKS com um fluxo de trabalho **dica** Para ver um tutorial que mostra como usar a ação **Implantar no cluster do Kubernetes**, consulte [Tutorial: Implantar uma aplicação no Amazon EKS](deploy-tut-eks.md). Esta seção descreve como implantar um aplicativo em contêiner em um cluster Kubernetes usando um fluxo de trabalho. CodeCatalyst Para fazer isso, você deve adicionar a ação **Implantar no cluster do Kubernetes** ao seu fluxo de trabalho. Essa ação implanta a aplicação em um cluster do Kubernetes que você configurou no Amazon Elastic Kubernetes Service (EKS) usando um ou mais arquivos de manifesto do Kubernetes. Para um exemplo de manifesto, consulte [deployment.yaml](deploy-tut-eks.md#deploy-tut-eks-source-files-deployment-yml) em [Tutorial: Implantar uma aplicação no Amazon EKS](deploy-tut-eks.md). Para ter mais informações sobre o Kubernetes, consulte a [documentação do Kubernetes](https://kubernetes.io/docs/home/). Para ter mais informações sobre o Amazon EKS, consulte [O que é o Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) no *Guia do usuário do Amazon EKS*. **Topics** + [ ## Como funciona a ação “Implantar no cluster do Kubernetes” ](#deploy-action-eks-howitworks) + [ ## Imagem de runtime usada pela ação “Implantar no Amazon EKS” ](#deploy-action-eks-runtime) + [ # Tutorial: Implantar uma aplicação no Amazon EKS ](deploy-tut-eks.md) + [ # Adição da ação “Implantar no cluster do Kubernetes” ](deploy-action-eks-adding.md) + [ # Variáveis de “Implantar no cluster do Kubernetes” ](deploy-action-eks-variables.md) + [ # YAML da ação “Implantar no cluster do Kubernetes” ](deploy-action-ref-eks.md) ## Como funciona a ação “Implantar no cluster do Kubernetes” A ação **Implantar no cluster do Kubernetes** funciona da seguinte forma: 1. Em tempo de execução, a ação instala o `kubectl` utilitário Kubernetes na máquina CodeCatalyst computacional em que a ação está sendo executada. A ação configura `kubectl` para apontar para o cluster do Amazon EKS que você forneceu ao configurar a ação. O utilitário `kubectl` é necessário para executar o comando `kubectl apply` a seguir. 1. A ação executa o `kubectl apply -f my-manifest.yaml` comando, que executa as instruções *my-manifest.yaml* para implantar seu aplicativo como um conjunto de contêineres e pods no cluster configurado. Para ter mais informações sobre esse comando, consulte o tópico [kubectl apply](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) na *documentação de referência do Kubernetes*. ## Imagem de runtime usada pela ação “Implantar no Amazon EKS” A ação **Implantar no Amazon EKS** é executada em uma [imagem de novembro de 2022](build-images.md#build.previous-image). Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). # Tutorial: Implantar uma aplicação no Amazon EKS Neste tutorial, você aprende a implantar um aplicativo em contêineres no Amazon Elastic Kubernetes Service usando CodeCatalyst um fluxo de trabalho da Amazon, o Amazon EKS e alguns outros serviços. AWS A aplicação implantada é um site simples “Hello, World\$1” criado em uma imagem do Docker do servidor da Web Apache. O tutorial mostra o trabalho de preparação necessário, como configurar uma máquina de desenvolvimento e um cluster do Amazon EKS, e depois descreve como criar um fluxo de trabalho para criar a aplicação e implantá-la no cluster. Após a conclusão da implantação inicial, o tutorial instrui você a fazer uma alteração na origem da aplicação. Essa alteração faz com que uma nova imagem do Docker seja criada e enviada ao seu repositório de imagens do Docker com novas informações de revisão. A nova revisão da imagem do Docker é implantada no Amazon EKS. **dica** Em vez de seguir este tutorial, você pode usar um esquema que faz uma configuração completa do Amazon EKS para você. Você precisará usar o esquema **Implantação de aplicações EKS**. Para obter mais informações, consulte [Criar um projeto com um esquema](projects-create.md#projects-create-console-template). **Topics** + [ ## Pré-requisitos ](#deploy-tut-eks-prereqs) + [ ## Etapa 1: configurar sua máquina de desenvolvimento ](#deploy-tut-eks-dev-env-create) + [ ## Etapa 2: criar um cluster do Amazon EKS ](#deploy-tut-eks-cluster) + [ ## Etapa 3: criar uma imagem de repositório do Amazon ECR ](#deploy-tut-eks-ecr) + [ ## Etapa 4: adicionar arquivos de origem ](#deploy-tut-eks-source-files) + [ ## Etapa 5: criar AWS funções ](#deploy-tut-eks-roles) + [ ## Etapa 6: Adicionar AWS funções a CodeCatalyst ](#deploy-tut-eks-import-roles) + [ ## Etapa 7: atualizar o ConfigMap ](#deploy-tut-eks-configmap) + [ ## Etapa 8: criar e executar um fluxo de trabalho ](#deploy-tut-eks-workflow) + [ ## Etapa 9: realizar uma alteração nos arquivos de origem ](#deploy-tut-eks-change) + [ ## Limpeza ](#deploy-tut-eks-cleanup) ## Pré-requisitos Antes de começar este tutorial: + Você precisa de um CodeCatalyst **espaço** na Amazon com uma AWS conta conectada. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). + Em seu espaço, você precisa de um projeto vazio chamado: ``` codecatalyst-eks-project ``` Use a opção **Começar do zero** para criar esse projeto. Para obter mais informações, consulte [Criando um projeto vazio na Amazon CodeCatalyst](projects-create.md#projects-create-empty). + Em seu projeto, você precisa de um **repositório CodeCatalyst de origem** vazio chamado: ``` codecatalyst-eks-source-repository ``` Para obter mais informações, consulte [Armazene e colabore no código com repositórios de origem no CodeCatalystArmazenamento e colaboração no código com repositórios de origem](source.md). + Em seu projeto, você precisa de um ambiente de CodeCatalyst CI/CD (não um **ambiente** de desenvolvimento) chamado: ``` codecatalyst-eks-environment ``` Configure esse ambiente da seguinte forma: + Escolha qualquer tipo, como **Não produção**. + Conecte sua AWS conta a ela. + Para o **Perfil do IAM padrão**, escolha qualquer perfil. Você especificará um perfil diferente posteriormente. Para obter mais informações, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md). ## Etapa 1: configurar sua máquina de desenvolvimento A primeira etapa deste tutorial é configurar uma máquina de desenvolvimento com algumas ferramentas que você usará ao longo deste tutorial. Essas ferramentas são: + o utilitário `eksctl` — para criação de clusters + o utilitário `kubectl` — um pré-requisito para `eksctl` + o AWS CLI — também um pré-requisito para `eksctl` Você pode instalar essas ferramentas em sua máquina de desenvolvimento existente, se tiver uma, ou pode usar um ambiente de CodeCatalyst desenvolvimento baseado em nuvem. A vantagem de um ambiente de CodeCatalyst desenvolvimento é que ele é fácil de ativar e desativar e está integrado a outros CodeCatalyst serviços, permitindo que você conclua este tutorial em menos etapas. Este tutorial pressupõe que você usará um ambiente de CodeCatalyst desenvolvimento. As instruções a seguir descrevem uma maneira rápida de iniciar um ambiente de CodeCatalyst desenvolvimento e configurá-lo com as ferramentas necessárias, mas se você quiser instruções detalhadas, consulte: + [Criar um Ambiente de Desenvolvimento](devenvironment-create.md) neste guia. + [Instalação do kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) no **Guia do usuário do Amazon EKS**. + [Instalação ou atualização do eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) no **Guia do usuário do Amazon EKS**. + [Instalação ou atualização da versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no *Guia do usuário do AWS Command Line Interface *. **Como iniciar um novo ambiente de desenvolvimento** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Navegue até o projeto, `codecatalyst-eks-project`. 1. No painel de navegação, selecione **Código** e, depois, selecione **Repositórios de origem**. 1. Escolha o nome para o seu repositório de origem, `codecatalyst-eks-source-repository`. 1. Na parte superior, escolha **Criar ambiente de desenvolvimento** e **AWS Cloud9 (no navegador)**. 1. Verifique se **Trabalhar na ramificação existente** e **principal** estão selecionados e, depois, selecione **Criar**. O Ambiente de Desenvolvimento é iniciado em uma nova guia do navegador e seu repositório (`codecatalyst-eks-source-repository`) é clonado nela. **Para instalar e configurar o kubectl** 1. No terminal do Ambiente de Desenvolvimento, insira: ``` curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/kubectl ``` 1. Insira: ``` chmod +x ./kubectl ``` 1. Insira: ``` mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin ``` 1. Insira: ``` echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc ``` 1. Insira: ``` kubectl version --short --client ``` 1. Confira se uma versão é exibida. Você agora tem o `kubectl` instalado. **Para instalar e configurar o eksctl** **nota** `eksctl` não é estritamente necessário porque você pode usar o `kubectl` em vez disso. No entanto, o `eksctl` tem a vantagem de automatizar grande parte da configuração do cluster e, portanto, é a ferramenta recomendada para este tutorial. 1. No terminal do Ambiente de Desenvolvimento, insira: ``` curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp ``` 1. Insira: ``` sudo cp /tmp/eksctl /usr/bin ``` 1. Insira: ``` eksctl version ``` 1. Confira se uma versão é exibida. Você agora tem o `eksctl` instalado. **Para verificar se o AWS CLI está instalado** 1. No terminal do Ambiente de Desenvolvimento, insira: ``` aws --version ``` 1. Verifique se uma versão aparece para verificar se o AWS CLI está instalado. Conclua os procedimentos restantes para configurar o AWS CLI com as permissões necessárias para acessar AWS. **Para configurar o AWS CLI** Você deve configurar o AWS CLI com chaves de acesso e um token de sessão para dar acesso aos AWS serviços. As instruções a seguir fornecem uma maneira rápida de configurar as chaves e o token, mas se você quiser instruções detalhadas, consulte [Configuração da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) no *Guia do usuário do AWS Command Line Interface *. 1. Crie um usuário do IAM Identity Center, da seguinte forma: 1. Faça login no Console de gerenciamento da AWS e abra o Centro de Identidade do AWS IAM console em [https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/). (Talvez seja necessário selecionar **Ativar** se você nunca tiver feito login no IAM Identity Center antes.) **nota** Certifique-se de fazer login usando o Conta da AWS que está conectado ao seu CodeCatalyst espaço. Você pode verificar qual conta está conectada navegando até seu espaço e escolhendo a guia **Contas da AWS**. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). 1. No painel de navegação, escolha **Usuários** e depois **Adicionar usuário**. 1. Em **Nome de usuário**, digite: ``` codecatalyst-eks-user ``` 1. Em **Senha**, selecione **Gerar uma senha de uso único que você possa compartilhar com esse usuário**. 1. Em **Endereço de e-mail** e **Confirmar endereço de e-mail**, insira um endereço de e-mail que ainda não exista no IAM Identity Center. 1. Em **Nome**, insira: ``` codecatalyst-eks-user ``` 1. Em **Sobrenome**, insira: ``` codecatalyst-eks-user ``` 1. Em **Nome de exibição**, mantenha: ``` codecatalyst-eks-user codecatalyst-eks-user ``` 1. Escolha **Próximo**. 1. Na página **Adicionar usuário a grupos**, selecione **Avançar**. 1. Na página **Revisar e adicionar usuário**, revise as informações e selecione **Adicionar usuário**. Uma caixa de diálogo **Senha de uso único** é exibida. 1. Selecione **Copiar** e cole as informações de login em um arquivo de texto. As informações de login consistem na URL do portal de AWS acesso, um nome de usuário e uma senha de uso único. 1. Escolha **Fechar**. 1. Crie um conjunto de permissões, da seguinte forma: 1. No painel de navegação, escolha **Conjuntos de permissões** e, depois, escolha **Criar conjunto de permissões**. 1. Escolha Conjunto de **permissões predefinido** e, em seguida, selecione **AdministratorAccess**. Esta política fornece permissões totais para todos os Serviços da AWS. 1. Escolha **Próximo**. 1. Em **Nome do conjunto de permissões**, remova `AdministratorAccess` e digite: ``` codecatalyst-eks-permission-set ``` 1. Escolha **Próximo**. 1. Na página **Revisar e criar**, revise as informações e selecione **Criar**. 1. Atribua o conjunto de permissões para `codecatalyst-eks-user`, da seguinte forma: 1. No painel de navegação **Contas da AWS**, escolha e marque a caixa de seleção ao lado da caixa de seleção na Conta da AWS qual você está conectado no momento. 1. Escolha **Atribuir usuários ou grupos**. 1. Escolha a guia **Users**. 1. Marque a caixa de seleção ao lado dos logs do `codecatalyst-eks-user`. 1. Escolha **Próximo**. 1. Marque a caixa de seleção ao lado dos logs do `codecatalyst-eks-permission-set`. 1. Escolha **Próximo**. 1. Revise suas informações e selecione **Enviar**. Agora você designou `codecatalyst-eks-user` e `codecatalyst-eks-permission-set` para o seu Conta da AWS, unindo-os. 1. Obtenha as chaves de acesso de `codecatalyst-eks-user` e o token de sessão, da seguinte forma: 1. Verifique se você tem a URL do portal de AWS acesso, o nome de usuário e a senha de uso único para`codecatalyst-eks-user`. Você deveria ter copiado essas informações para um editor de texto anteriormente. **nota** Se você não tiver essas informações, acesse a página de detalhes do `codecatalyst-eks-user` no IAM Identity Center, selecione **Redefinir senha**, **Gerar uma senha de uso único [...]** e **Redefinir senha** novamente para exibir as informações na tela. 1. Sair de AWS. 1. Cole o URL do portal de AWS acesso na barra de endereço do seu navegador. 1. Faça login com: + **Nome de usuário**: ``` codecatalyst-eks-user ``` + **Senha**: *one-time-password* 1. Em **Definir nova senha**, insira uma nova senha e selecione **Definir nova senha**. Uma caixa de **Conta da AWS** aparece na tela. 1. Selecione **Conta da AWS** e, depois, escolha o nome da Conta da AWS a que você atribuiu o usuário `codecatalyst-eks-user` e o conjunto de permissões. 1. Ao lado de `codecatalyst-eks-permission-set`, selecione **Linha de comando ou acesso programático**. 1. Copie os comandos no meio da página. Eles são semelhantes a: ``` export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" export AWS_SESSION_TOKEN="session-token" ``` ... onde *session-token* está uma longa sequência aleatória. 1. Adicione as chaves de acesso e o token de sessão ao AWS CLI, da seguinte forma: 1. Retorne ao seu ambiente de CodeCatalyst desenvolvimento. 1. No prompt do terminal, cole os comandos que você copiou. Pressione Enter. Agora você configurou o AWS CLI com chaves de acesso e um token de sessão. Agora você pode usar AWS CLI para concluir as tarefas exigidas por este tutorial. **Importante** Se, em algum momento durante este tutorial, você vir mensagens semelhantes a: `Unable to locate credentials. You can configure credentials by running "aws configure".` Ou: `ExpiredToken: The security token included in the request is expired` ... é porque sua AWS CLI sessão expirou. Nesse caso, *não* execute o comando `aws configure`. Em vez disso, use as instruções na etapa 4 desse procedimento, que começa com `Obtain codecatalyst-eks-user's access key and session token`, para atualizar sua sessão. ## Etapa 2: criar um cluster do Amazon EKS Nesta seção, você cria um cluster no Amazon EKS. As instruções abaixo descrevem uma maneira rápida de criar o cluster usando o `eksctl`, mas se você quiser instruções detalhadas, consulte: + [Conceitos básicos do eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) no ** Guia do usuário do Amazon EKS** or + [Introdução ao console e à AWS CLI](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html) no **Guia do usuário do Amazon EKS** (este tópico fornece instruções do `kubectl` para criar o cluster) **nota** Os [clusters privados](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html) não são compatíveis com a CodeCatalyst integração com o Amazon EKS. **Antes de começar** Verifique se você concluiu as seguintes tarefas na sua máquina de desenvolvimento: + Instalou o utilitário `eksctl`. + Instalou o utilitário `kubectl`. + Instalei AWS CLI e configurei com chaves de acesso e um token de sessão. Para ter informações sobre como concluir essas tarefas, consulte [Etapa 1: configurar sua máquina de desenvolvimento](#deploy-tut-eks-dev-env-create). **Para criar um cluster** **Importante** Não use a interface de usuário do serviço Amazon EKS para criar o cluster porque o cluster não será configurado corretamente. Use o utilitário `eksctl`, conforme descrito nas etapas a seguir. 1. Acesse o Ambiente de Desenvolvimento. 1. Crie um cluster e nós: ``` eksctl create cluster --name codecatalyst-eks-cluster --region us-west-2 ``` Em que: + *codecatalyst-eks-cluster*é substituído pelo nome que você deseja dar ao seu cluster. + *us-west-2*é substituído pela sua região. Depois de 10 a 20 minutos, uma mensagem semelhante à seguinte é exibida: `EKS cluster "codecatalyst-eks-cluster" in "us-west-2" region is ready` **nota** Você verá várias mensagens `waiting for CloudFormation stack` enquanto a AWS cria seu cluster. Isso é esperado. 1. Verifique se o cluster foi criado: ``` kubectl cluster-info ``` Você verá uma mensagem semelhante à seguinte, indicando uma criação de cluster bem-sucedida: ``` Kubernetes master is running at https://long-string.gr7.us-west-2.eks.amazonaws.com CoreDNS is running at https://long-string.gr7.us-west-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy ``` ## Etapa 3: criar uma imagem de repositório do Amazon ECR Nesta seção, você cria um repositório de imagens privadas no Amazon Elastic Container Registry (Amazon ECR). Esse repositório armazena a imagem do Docker do tutorial. Para obter mais informações sobre o Amazon ECR, consulte o *Guia do usuário do Amazon Elastic Container Registry*. **Para criar um repositório de imagens no Amazon ECR** 1. Acesse o Ambiente de Desenvolvimento. 1. Crie um repositório vazio no Amazon ECR: ``` aws ecr create-repository --repository-name codecatalyst-eks-image-repo ``` *codecatalyst-eks-image-repo*Substitua pelo nome que você deseja dar ao repositório Amazon ECR. Este tutorial pressupõe que você tem um repositório chamado `codecatalyst-eks-image-repo`. 1. Exiba os detalhes do repositório do Amazon ECR: ``` aws ecr describe-repositories \ --repository-names codecatalyst-eks-image-repo ``` 1. Observe o valor `“repositoryUri”:`, por exemplo, `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo`. Você precisará dele mais tarde ao adicionar o repositório ao seu fluxo de trabalho. ## Etapa 4: adicionar arquivos de origem Nesta seção, você adiciona arquivos de origem da aplicação ao seu repositório de origem (`codecatalyst-eks-source-repository`). Eles consistem em: + Um arquivo `index.html`: exibe uma mensagem “Hello, World\$1” no navegador. + Um Dockerfile: descreve a imagem básica a ser usada para sua imagem do Docker e os comandos do Docker a serem aplicados a ela. + Um arquivo `deployment.yaml`: o manifesto do Kubernetes que define o serviço e a implantação do Kubernetes. A estrutura de pastas é esta: ``` |— codecatalyst-eks-source-repository |— Kubernetes |— deployment.yaml |— public-html | |— index.html |— Dockerfile ``` **Topics** + [ ### index.html ](#deploy-tut-eks-source-files-index) + [ ### Dockerfile ](#deploy-tut-eks-source-files-dockerfile) + [ ### deployment.yaml ](#deploy-tut-eks-source-files-deployment-yml) ### index.html O arquivo `index.html` exibe uma mensagem “Hello, World\$1” no navegador. **Como adicionar o arquivo index.html** 1. Acesse o Ambiente de Desenvolvimento. 1. Em `codecatalyst-eks-source-repository`, crie uma pasta chamada `public-html`. 1. Em `/public-html`, crie um arquivo chamado `index.html` com o conteúdo a seguir: ``` Hello World

Hello, World!

``` 1. No prompt do terminal, insira: ``` cd /projects/codecatalyst-eks-source-repository ``` 1. Adicione, confirme e envie: ``` git add . git commit -m "add public-html/index.html" git push ``` O `index.html` é adicionado ao seu repositório em uma pasta `public-html`. ### Dockerfile O Dockerfile descreve a imagem base do Docker a ser usada e os comandos do Docker a serem aplicados a ela. Para ter mais informações sobre o Dockerfile, consulte a [Referência de Dockerfile](https://docs.docker.com/engine/reference/builder/). O Dockerfile especificado aqui indica o uso da imagem base do Apache 2.4 (`httpd`). Também inclui instruções para copiar um arquivo fonte chamado `index.html` para uma pasta no servidor Apache que serve páginas da Web. A instrução `EXPOSE` no Dockerfile diz ao Docker que o contêiner está escutando na porta 80. **Para adicionar o Dockerfile** 1. Em `codecatalyst-eks-source-repository`, crie um arquivo chamado `Dockerfile` com o conteúdo a seguir: ``` FROM httpd:2.4 COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html EXPOSE 80 ``` Não inclua uma extensão de arquivo. **Importante** O Dockerfile deve residir na pasta raiz do repositório. O comando `Docker build` do fluxo de trabalho espera que ele esteja lá. 1. Adicione, confirme e envie: ``` git add . git commit -m "add Dockerfile" git push ``` O Dockerfile é adicionado ao repositório. ### deployment.yaml Nesta seção, você adiciona um arquivo `deployment.yaml` ao seu repositório. O arquivo `deployment.yaml` é um manifesto do Kubernetes que define dois *tipos* de recursos do Kubernetes a serem executados: um “serviço” e uma “implantação”. + O “serviço” implanta um balanceador de carga no Amazon EC2. O balanceador de carga fornece um URL público voltado para a Internet e uma porta padrão (porta 80) que você pode usar para navegar até a aplicação “Hello, World\$1” aplicativo. + A “implantação” implanta três pods, e cada pod terá um contêiner do Docker com a aplicação “Hello, World\$1” aplicativo. Os três pods são implantados nos nós que foram criados quando você criou o cluster. O manifesto neste tutorial é curto. No entanto, um manifesto pode incluir vários tipos de recursos do Kubernetes, como pods, trabalhos, entradas e políticas de rede. Além disso, você pode usar vários arquivos de manifesto se sua implantação for complexa. **Para adicionar um arquivo deployment.yaml** 1. Em `codecatalyst-eks-source-repository`, crie uma pasta chamada `Kubernetes`. 1. Em `/Kubernetes`, crie um arquivo chamado `deployment.yaml` com o conteúdo a seguir: ``` apiVersion: v1 kind: Service metadata: name: my-service labels: app: my-app spec: type: LoadBalancer selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment labels: app: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: codecatalyst-eks-container # The $REPOSITORY_URI and $IMAGE_TAG placeholders will be replaced by actual values supplied by the build action in your workflow image: $REPOSITORY_URI:$IMAGE_TAG ports: - containerPort: 80 ``` 1. Adicione, confirme e envie: ``` git add . git commit -m "add Kubernetes/deployment.yaml" git push ``` O arquivo `deployment.yaml` é adicionado ao seu repositório em uma pasta chamada `Kubernetes`. Agora você adicionou todos os seus arquivos de origem. Reserve um momento para verificar seu trabalho e garantir que colocou todos os arquivos nas pastas corretas. A estrutura de pastas é esta: ``` |— codecatalyst-eks-source-repository |— Kubernetes |— deployment.yaml |— public-html | |— index.html |— Dockerfile ``` ## Etapa 5: criar AWS funções Nesta seção, você cria funções AWS do IAM que seu CodeCatalyst fluxo de trabalho precisará para funcionar. Esses perfis são: + **Função de criação** — concede permissão à ação de CodeCatalyst criação (no fluxo de trabalho) para acessar sua AWS conta e gravar no Amazon ECR e no Amazon EC2. + **Função de implantação** — concede à ação de **cluster CodeCatalyst Deploy to Kubernetes** (no fluxo de trabalho) permissão para acessar sua conta AWS e o Amazon EKS. Para ter informações sobre perfis do IAM, consulte [Perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) no *Guia do usuário do AWS Identity and Access Management *. **nota** Para economizar tempo, você pode criar um único perfil, chamado `CodeCatalystWorkflowDevelopmentRole-spaceName`, em vez dos dois perfis listados anteriormente. Para obter mais informações, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões bem amplas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Este tutorial pressupõe que você esteja criando os dois perfis listados anteriormente. Para criar os perfis de criação e implantação, conclua a série de procedimentos a seguir. **1. Para criar uma política de confiança para os dois perfis** 1. Acesse o Ambiente de Desenvolvimento. 1. No diretório `Cloud9-long-string`, crie um arquivo chamado `codecatalyst-eks-trust-policy.json` com o seguinte conteúdo: **2. Para criar a política de criação do perfil de criação** + No diretório `Cloud9-long-string`, crie um arquivo chamado `codecatalyst-eks-build-policy.json` com o seguinte conteúdo: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:*", "ec2:*" ], "Resource": "*" } ] } ``` ------ **nota** Na primeira vez em que o perfil for usado para executar ações de fluxo de trabalho, use o caractere curinga na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` **3. Para criar a política do perfil de implantação** + No diretório `Cloud9-long-string`, crie um arquivo chamado `codecatalyst-eks-deploy-policy.json` com o seguinte conteúdo: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] } ``` ------ **nota** Na primeira vez em que o perfil for usado para executar ações de fluxo de trabalho, use o caractere curinga na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` Agora você adicionou três documentos de política ao seu Ambiente de Desenvolvimento. A estrutura do seu diretório agora deve ficar assim: ``` |— Cloud9-long-string |— .c9 |— codecatalyst-eks-source-repository |— Kubernetes |— public-html |— Dockerfile codecatalyst-eks-build-policy.json codecatalyst-eks-deploy-policy.json codecatalyst-eks-trust-policy.json ``` **4. Para adicionar a política de compilação ao AWS** 1. No terminal do Ambiente de Desenvolvimento, insira: ``` cd /projects ``` 1. Insira: ``` aws iam create-policy \ --policy-name codecatalyst-eks-build-policy \ --policy-document file://codecatalyst-eks-build-policy.json ``` 1. Pressione **Enter**. 1. Na saída do comando, observe o valor `"arn":`, por exemplo, `arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy`. Esse ARN será necessário posteriormente. **5. Para adicionar a política de implantação ao AWS** 1. Insira: ``` aws iam create-policy \ --policy-name codecatalyst-eks-deploy-policy \ --policy-document file://codecatalyst-eks-deploy-policy.json ``` 1. Pressione **Enter**. 1. Na saída do comando, observe o valor `"arn":` da política de implantação, por exemplo, `arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy`. Esse ARN será necessário posteriormente. **6. Para criar o perfil de criação** 1. Insira: ``` aws iam create-role \ --role-name codecatalyst-eks-build-role \ --assume-role-policy-document file://codecatalyst-eks-trust-policy.json ``` 1. Pressione **Enter**. 1. Insira: ``` aws iam attach-role-policy \ --role-name codecatalyst-eks-build-role \ --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy ``` Onde *arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy* é substituído pelo ARN da política de construção que você observou anteriormente. 1. Pressione **Enter**. 1. No prompt do terminal, insira: ``` aws iam get-role \ --role-name codecatalyst-eks-build-role ``` 1. Pressione **Enter**. 1. Observe o valor `"Arn":` do perfil, por exemplo, `arn:aws:iam::111122223333:role/codecatalyst-eks-build-role`. Esse ARN será necessário posteriormente. **7. Para criar o perfil de implantação** 1. Insira: ``` aws iam create-role \ --role-name codecatalyst-eks-deploy-role \ --assume-role-policy-document file://codecatalyst-eks-trust-policy.json ``` 1. Pressione **Enter**. 1. Insira: ``` aws iam attach-role-policy \ --role-name codecatalyst-eks-deploy-role \ --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy ``` Onde *arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy* é substituído pelo ARN da política de implantação que você observou anteriormente. 1. Pressione **Enter**. 1. Insira: ``` aws iam get-role \ --role-name codecatalyst-eks-deploy-role ``` 1. Pressione **Enter**. 1. Observe o valor `"Arn":` do perfil, por exemplo, `arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role`. Esse ARN será necessário posteriormente. Agora você criou funções de criação e implantação e anotou suas ARNs. ## Etapa 6: Adicionar AWS funções a CodeCatalyst Nesta etapa, você adiciona a função de criação (`codecatalyst-eks-build-role`) e a função de implantação (`codecatalyst-eks-deploy-role`) à Conta da AWS função conectada ao seu espaço. Isso torna os perfis disponíveis para uso em seu fluxo de trabalho. **Para adicionar funções de criação e implantação ao seu Conta da AWS** 1. No CodeCatalyst console, navegue até seu espaço. 1. Na parte superior, selecione **Configurações**. 1. No painel de navegação, selecione **Contas da AWS **. Uma lista de contas é exibida. 1. Na coluna **Nome de CodeCatalyst exibição da Amazon**, copie o nome de exibição de Conta da AWS onde você criou suas funções de criação e implantação. (Pode ser um número.) Esse valor será necessário posteriormente, ao criar seu fluxo de trabalho. 1. Escolha o nome de exibição. 1. Escolha **Gerenciar funções no console de AWS gerenciamento**. A página **Adicionar função do IAM ao CodeCatalyst espaço da Amazon** é exibida. Talvez seja necessário fazer login para acessá-la. 1. Selecione **Adicionar um perfil existente que você criou no IAM**. Uma lista suspensa aparece. A lista exibe os perfis de criação e implantação e outros perfis do IAM com uma política de confiança que inclui as entidades principais de serviço `codecatalyst-runner.amazonaws.com` e `codecatalyst.amazonaws.com`. 1. Na lista suspensa, adicione: + `codecatalyst-eks-build-role` + `codecatalyst-eks-deploy-role` **nota** Se você vir `The security token included in the request is invalid`, pode ser porque você não tem as permissões corretas. Para corrigir esse problema, saia e faça login novamente com a AWS conta que você usou ao criar seu CodeCatalyst espaço. AWS 1. Volte ao CodeCatalyst console e atualize a página. Os perfis de criação e implantação agora devem aparecer em **Perfis do IAM**. Essas funções agora estão disponíveis para uso em CodeCatalyst fluxos de trabalho. ## Etapa 7: atualizar o ConfigMap Você deve adicionar o perfil de implantação que você criou em [Etapa 5: criar AWS funções](#deploy-tut-eks-roles) ao arquivo `ConfigMap` do Kubernetes para dar à ação **Implantar no cluster do Kubernetes** (no fluxo de trabalho) a capacidade de acessar e interagir com seu cluster. Você pode usar o `eksctl` ou `kubectl` para executar essa tarefa. **Para configurar o arquivo Kubernetes ConfigMap usando eksctl** + No terminal do Ambiente de Desenvolvimento, insira: ``` eksctl create iamidentitymapping --cluster codecatalyst-eks-cluster --arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role --group system:masters --username codecatalyst-eks-deploy-role --region us-west-2 ``` Em que: + *codecatalyst-eks-cluster*é substituído pelo nome do cluster Amazon EKS. + *arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role*é substituído pelo ARN da função de implantação que você criou em. [Etapa 5: criar AWS funções](#deploy-tut-eks-roles) + *codecatalyst-eks-deploy-role*(ao lado de`--username`) é substituído pelo nome da função de implantação que você criou em[Etapa 5: criar AWS funções](#deploy-tut-eks-roles). **nota** Se você decidiu não criar uma função de implantação, *codecatalyst-eks-deploy-role* substitua pelo nome da `CodeCatalystWorkflowDevelopmentRole-spaceName` função. Para obter mais informações sobre esse perfil, consulte [Etapa 5: criar AWS funções](#deploy-tut-eks-roles). + *us-west-2*é substituído pela sua região. Para saber detalhes sobre esse comando, consulte [Gerenciar usuários e perfis do IAM](https://eksctl.io/usage/iam-identity-mappings/). Uma mensagem semelhante à seguinte é exibida: ``` 2023-06-09 00:58:29 [ℹ] checking arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role against entries in the auth ConfigMap 2023-06-09 00:58:29 [ℹ] adding identity "arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role" to auth ConfigMap ``` **Para configurar o arquivo Kubernetes ConfigMap usando kubectl** 1. No terminal do Ambiente de Desenvolvimento, insira: ``` kubectl edit configmap -n kube-system aws-auth ``` O ConfigMap arquivo aparece na tela. 1. Adicione o texto em itálico vermelho: ``` # Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: v1 data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: arn:aws:iam::111122223333:role/eksctl-codecatalyst-eks-cluster-n-NodeInstanceRole-16BC456ME6YR5 username: system:node:{{EC2PrivateDNSName}} - groups: - system:masters rolearn: arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role username: codecatalyst-eks-deploy-role mapUsers: | [] kind: ConfigMap metadata: creationTimestamp: "2023-06-08T19:04:39Z" managedFields: ... ``` Em que: + *arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role*é substituído pelo ARN da função de implantação que você criou em. [Etapa 5: criar AWS funções](#deploy-tut-eks-roles) + *codecatalyst-eks-deploy-role*(ao lado de`username:`) é substituído pelo nome da função de implantação que você criou em[Etapa 5: criar AWS funções](#deploy-tut-eks-roles). **nota** Se você decidiu não criar uma função de implantação, *codecatalyst-eks-deploy-role* substitua pelo nome da `CodeCatalystWorkflowDevelopmentRole-spaceName` função. Para obter mais informações sobre esse perfil, consulte [Etapa 5: criar AWS funções](#deploy-tut-eks-roles). Para saber detalhes, consulte [Habilitar o acesso da entidade principal do IAM ao seu cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) no **Guia do usuário do Amazon EKS**. Agora você concedeu ao perfil de implantação e, por extensão, à ação **Implantar no Amazon EKS**, permissões `system:masters` para seu cluster do Kubernetes. ## Etapa 8: criar e executar um fluxo de trabalho Nesta etapa, você cria um fluxo de trabalho que cria os arquivos de origem em uma imagem do Docker e, depois, implanta a imagem em três pods no cluster do Amazon EKS. O fluxo de trabalho consiste nos seguintes blocos de compilação que são executados sequencialmente: + Um gatilho: esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + Uma ação de criação (`BuildBackend`) – No gatilho, a ação cria a imagem do Docker usando o Dockerfile e envia a imagem para o Amazon ECR. A ação de criação também atualiza as variáveis `$REPOSITORY_URI` e `$IMAGE_TAG` no arquivo `deployment.yaml` com os valores corretos e, depois, cria um artefato de saída desse arquivo e de qualquer outro na pasta `Kubernetes`. Neste tutorial, o único arquivo na pasta `Kubernetes` é `deployment.yaml`, mas você pode incluir mais arquivos. O artefato é usado como entrada para a ação de implantação, que será a seguir. Para ter mais informações sobre a ação de criação, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). + Uma ação de implantação (`DeployToEKS`) – Ao concluir a ação de criação, a ação de implantação procura o artefato de saída gerado pela ação de criação (`Manifests`), encontra o `deployment.yaml` dentro dele. Em seguida, a ação segue as instruções no arquivo `deployment.yaml` para executar três pods, cada um contendo um único “Hello, World\$1” Contêiner do Docker, dentro do cluster do Amazon EKS. **Para criar um fluxo de trabalho** 1. Vá para o CodeCatalyst console. 1. Navegue até o projeto (`codecatalyst-eks-project`). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho**. 1. Em **Repositório de origem**, selecione `codecatalyst-eks-source-repository`. 1. Em **Ramificação**, selecione `main`. 1. Escolha **Criar**. 1. Exclua o código de amostra YAML. 1. Adicione o código YAML a seguir para criar um arquivo de definição de fluxo de trabalho: **nota** Para ter mais informações sobre o arquivo de definição de fluxo de trabalho, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** No código YAML a seguir, você pode omitir as seções `Connections:` se quiser. Se você omitir essas seções, deverá garantir que o perfil especificado no campo **Perfil do IAM padrão** em seu ambiente inclua as permissões e as políticas de confiança dos dois perfis descritas em [Etapa 6: Adicionar AWS funções a CodeCatalyst](#deploy-tut-eks-import-roles). Para ter mais informações sobre como configurar um ambiente com um perfil do IAM padrão, consulte [Criar um ambiente](deploy-environments-creating-environment.md). ``` Name: codecatalyst-eks-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: BuildBackend: Identifier: aws/build@v1 Environment: Name: codecatalyst-eks-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-eks-build-role Inputs: Sources: - WorkflowSource Variables: - Name: REPOSITORY_URI Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo - Name: IMAGE_TAG Value: ${WorkflowSource.CommitId} Configuration: Steps: #pre_build: - Run: echo Logging in to Amazon ECR... - Run: aws --version - Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com #build: - Run: echo Build started on `date` - Run: echo Building the Docker image... - Run: docker build -t $REPOSITORY_URI:latest . - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG #post_build: - Run: echo Build completed on `date` - Run: echo Pushing the Docker images... - Run: docker push $REPOSITORY_URI:latest - Run: docker push $REPOSITORY_URI:$IMAGE_TAG # Replace the variables in deployment.yaml - Run: find Kubernetes/ -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g" - Run: find Kubernetes/ -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g" - Run: cat Kubernetes/* # The output artifact will be a zip file that contains Kubernetes manifest files. Outputs: Artifacts: - Name: Manifests Files: - "Kubernetes/*" DeployToEKS: DependsOn: - BuildBackend Identifier: aws/kubernetes-deploy@v1 Environment: Name: codecatalyst-eks-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-eks-deploy-role Inputs: Artifacts: - Manifests Configuration: Namespace: default Region: us-west-2 Cluster: codecatalyst-eks-cluster Manifests: Kubernetes/ ``` No código anterior, substitua: + Ambas as instâncias de *codecatalyst-eks-environment* com o nome do ambiente em que você criou[Pré-requisitos](#deploy-tut-eks-prereqs). + Ambas as instâncias *codecatalyst-account-connection* com o nome de exibição da conexão da sua conta. O nome de exibição pode ser um número. Para obter mais informações, consulte [Etapa 6: Adicionar AWS funções a CodeCatalyst](#deploy-tut-eks-import-roles). + *codecatalyst-eks-build-role*com o nome da função de construção em que você criou[Etapa 5: criar AWS funções](#deploy-tut-eks-roles). + *111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo*(na `Value:` propriedade) com o URI do repositório Amazon ECR em que você criou. [Etapa 3: criar uma imagem de repositório do Amazon ECR](#deploy-tut-eks-ecr) + *111122223333.dkr.ecr.us-west-2.amazonaws.com*(no `Run: aws ecr` comando) com o URI do repositório Amazon ECR sem o sufixo da imagem (). `/codecatalyst-eks-image-repo` + *codecatalyst-eks-deploy-role*com o nome da função de implantação na qual você criou[Etapa 5: criar AWS funções](#deploy-tut-eks-roles). + Ambas as instâncias *us-west-2* com seu código de AWS região. Para ver uma lista de códigos de região, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html) na *Referência geral da AWS*. **nota** Se você decidiu não criar e implantar funções, *codecatalyst-eks-deploy-role* substitua *codecatalyst-eks-build-role* e pelo nome da `CodeCatalystWorkflowDevelopmentRole-spaceName` função. Para obter mais informações sobre esse perfil, consulte [Etapa 5: criar AWS funções](#deploy-tut-eks-roles). 1. (Opcional) Selecione **Validar** para garantir que o código YAML seja válido antes de confirmar. 1. Selecione **Confirmar**. 1. Na caixa de diálogo **Confirmar fluxo de trabalho**, insira o seguinte: 1. Em **Mensagem de confirmação**, remova o texto e digite: ``` Add first workflow ``` 1. Em **Repositório**, selecione `codecatalyst-eks-source-repository`. 1. Em **Nome da ramificação**, selecione a principal. 1. Selecione **Confirmar**. Agora você criou um fluxo de trabalho. A execução de um fluxo de trabalho é iniciada automaticamente devido ao gatilho definido na parte superior do fluxo de trabalho. Especificamente, quando você confirmou (e enviou) o arquivo `workflow.yaml` ao repositório de origem, o gatilho iniciou a execução do fluxo de trabalho. **Para visualizar o andamento da execução do fluxo de trabalho** 1. **No painel de navegação do CodeCatalyst console, escolha **CI/CD** e, em seguida, escolha Fluxos de trabalho.** 1. Escolha o fluxo de trabalho que você acabou de criar, `codecatalyst-eks-workflow`. 1. Escolha **BuildBackend**ver o progresso da construção. 1. Escolha **DeployToEKS** para ver o progresso da implantação. Para ter mais informações sobre como visualizar os detalhes da execução, consulte o [Visualização do status e detalhes de execução do fluxo de trabalho](workflows-view-run.md). **Como verificar a implantação** 1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. À esquerda, na parte inferior, escolha **Balanceadores de carga**. 1. Selecione o balanceador de carga que foi criado como parte da sua implantação do Kubernetes. Se você não tiver certeza de qual balanceador de carga escolher, procure as seguintes tags na guia **Tags**: + `kubernetes.io/service-name` + `kubernetes.io/cluster/ekstutorialcluster` 1. Com o balanceador de carga correto selecionado, escolha a guia **Descrição**. 1. Copie e cole o valor do **Nome do DNS** na barra de endereço do navegador. A página da Web “Hello, World\$1” aparece no navegador, indicando que você implantou a aplicação com êxito. ## Etapa 9: realizar uma alteração nos arquivos de origem Nesta seção, você faz uma alteração no arquivo `index.html` no repositório de origem. Essa alteração faz com que o fluxo de trabalho crie uma nova imagem do Docker, a marque com um ID de confirmação, a envie por push ao Amazon ECR e a implante no Amazon ECS. **Para alterar o index.html** 1. Acesse o Ambiente de Desenvolvimento. 1. No prompt do terminal, mude para seu repositório de origem: ``` cd /projects/codecatalyst-eks-source-repository ``` 1. Obtenha as alterações mais recentes do fluxo de trabalho: ``` git pull ``` 1. Abra o `codecatalyst-eks-source-repository/public-html/index.html`. 1. Na linha 14, altere o texto `Hello, World!` para `Tutorial complete!`. 1. Adicione, confirme e envie: ``` git add . git commit -m "update index.html title" git push ``` A execução de um fluxo de trabalho é iniciada automaticamente. 1. (Opcional) Insira: ``` git show HEAD ``` Anote o ID de confirmação da alteração `index.html`. Esse ID de confirmação será marcado na imagem do Docker que será implantada pela execução do fluxo de trabalho que você acabou de iniciar. 1. Assista ao andamento da implantação: 1. **No CodeCatalyst console, no painel de navegação, escolha **CI/CD** e, em seguida, escolha Fluxos de trabalho.** 1. Escolha `codecatalyst-eks-workflow` para ver a última execução. 1. Escolha **BuildBackend**e **DeployToEKS** para ver o progresso da execução do fluxo de trabalho. 1. Verifique se a aplicação foi atualizada, da seguinte forma: 1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. À esquerda, na parte inferior, escolha **Balanceadores de carga**. 1. Selecione o balanceador de carga que foi criado como parte da sua implantação do Kubernetes. 1. Copie e cole o valor do **Nome do DNS** na barra de endereço do navegador. A página da Web “Tutorial concluído\$1” aparece no navegador, indicando que você implantou uma nova revisão da aplicação com êxito. 1. (Opcional) Em AWS, alterne para o console do Amazon ECR e verifique se a nova imagem do Docker foi marcada com o ID de confirmação da etapa 7 deste procedimento. ## Limpeza Você deve limpar seu ambiente para não receber cobranças desnecessárias pelos recursos de armazenamento e computação usados neste tutorial. **Para limpar** 1. Exclua seu cluster: 1. No terminal do Ambiente de Desenvolvimento, insira: ``` eksctl delete cluster --region=us-west-2 --name=codecatalyst-eks-cluster ``` Em que: + *us-west-2*é substituído pela sua região. + *codecatalyst-eks-cluster*é substituído pelo nome do cluster que você criou. Após 5 a 10 minutos, o cluster e os recursos associados são excluídos, incluindo, mas não se limitando a, CloudFormation pilhas, grupos de nós (no Amazon EC2) e balanceadores de carga. **Importante** Se o `eksctl delete cluster` comando não funcionar, talvez seja necessário atualizar suas AWS credenciais ou suas `kubectl` credenciais. Se você não tiver certeza de quais credenciais atualizar, atualize as AWS credenciais primeiro. Para atualizar suas credenciais da AWS , consulte [Como faço para corrigir os erros “Não é possível localizar credenciais” e ExpiredToken "”?](troubleshooting-workflows.md#troubleshooting-workflows-auth-errors-eks). Para atualizar suas credenciais do `kubectl`, consulte [Como faço para corrigir os erros “Não foi possível conectar-se ao servidor”?](troubleshooting-workflows.md#troubleshooting-workflows-unable-connect-eks). 1. No AWS console, limpe da seguinte forma: 1. No Amazon ECR, exclua `codecatalyst-eks-image-repo`. 1. No IAM Identity Center, exclua: 1. `codecatalyst-eks-user` 1. `codecatalyst-eks-permission-set` 1. No IAM, exclua: + `codecatalyst-eks-build-role` + `codecatalyst-eks-deploy-role` + `codecatalyst-eks-build-policy` + `codecatalyst-eks-deploy-policy` 1. No CodeCatalyst console, limpe da seguinte forma: 1. Exclua `codecatalyst-eks-workflow`. 1. Exclua `codecatalyst-eks-environment`. 1. Exclua `codecatalyst-eks-source-repository`. 1. Exclua o Ambiente de Desenvolvimento. 1. Exclua `codecatalyst-eks-project`. Neste tutorial, você aprendeu a implantar um aplicativo em um serviço Amazon EKS usando um CodeCatalyst fluxo de trabalho e uma ação de cluster **Deploy to Kubernetes.** # Adição da ação “Implantar no cluster do Kubernetes” Use as instruções a seguir para adicionar a ação **Implantar no cluster do Kubernetes** ao seu fluxo de trabalho. **Antes de começar** Antes de adicionar a ação **Implantar no cluster do Kubernetes** ao seu fluxo de trabalho, você deve preparar o seguinte: **dica** Para configurar esses pré-requisitos rapidamente, siga as instruções em [Tutorial: Implantar uma aplicação no Amazon EKS](deploy-tut-eks.md). + Um cluster do Kubernetes no Amazon EKS. Para ter informações sobre clusters, consulte o [Clusters do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html) no **Guia do usuário do Amazon EKS**. + Pelo menos um Dockerfile que descreva como montar a aplicação em uma imagem do Docker. Para ter mais informações sobre Dockerfiles, consulte a [Referência de Dockerfile](https://docs.docker.com/engine/reference/builder/). + Pelo menos um arquivo de manifesto do Kubernetes, chamado de *arquivo de configuração* ou *configuração* na documentação do Kubernetes. Para ter mais informações, consulte [Gerenciamento de recursos](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/) na documentação do Kubernetes. + Um perfil do IAM que dá à ação **Implantar no cluster do Kubernetes** a capacidade de acessar e interagir com seu cluster do Amazon EKS. Para obter mais informações, consulte o tópico [Role](deploy-action-ref-eks.md#deploy.action.eks.environment.connections.role) no [YAML da ação “Implantar no cluster do Kubernetes”](deploy-action-ref-eks.md). Depois de criar esse perfil, você deve adicioná-lo a: + Seu arquivo Kubernetes ConfigMap . Para saber como adicionar uma função a um ConfigMap arquivo, consulte [Habilitar o acesso principal do IAM ao seu cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) no **Guia do usuário do Amazon EKS**. + CodeCatalyst. Para saber como adicionar uma função do IAM ao CodeCatalyst, consulte[Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). + Um CodeCatalyst espaço, projeto e ambiente. O espaço e o ambiente devem estar conectados à AWS conta na qual você implantará seu aplicativo. Para obter mais informações, consulte [Criar um espaço](spaces-create.md), [Criando um projeto vazio na Amazon CodeCatalyst](projects-create.md#projects-create-empty) e [Implantação em e Contas da AWS VPCs](deploy-environments.md). + Um repositório de origem suportado pelo CodeCatalyst. O repositório armazena os arquivos de origem da aplicação, Dockerfiles e manifestos do Kubernetes. Para obter mais informações, consulte [Armazene e colabore no código com repositórios de origem no CodeCatalystArmazenamento e colaboração no código com repositórios de origem](source.md). ------ #### [ Visual ] **Para adicionar a ação “Implantar no cluster do Kubernetes” usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Implantar no cluster do Kubernetes** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Implantar no cluster do Kubernetes**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Download** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [YAML da ação “Implantar no cluster do Kubernetes”](deploy-action-ref-eks.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar a ação “Implantar no cluster do Kubernetes” usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Implantar no cluster do Kubernetes** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Implantar no cluster do Kubernetes**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Download** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [YAML da ação “Implantar no cluster do Kubernetes”](deploy-action-ref-eks.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Variáveis de “Implantar no cluster do Kubernetes” A ação **Implantar no cluster do Kubernetes** produz e define as seguintes variáveis em runtime. Elas são conhecidas como *variáveis predefinidas*. Para ter informações sobre como referenciar essas variáveis em um fluxo de trabalho, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). | Chave | Valor | | --- | --- | | cluster | O nome do recurso da Amazon.com (ARN) do cluster do Amazon EKS no qual foi implantado durante a execução do fluxo de trabalho. Exemplo: `arn:aws:eks:us-west-2:111122223333:cluster/codecatalyst-eks-cluster` | | deployment-platform | O nome da plataforma de implantação. Codificado para `AWS:EKS`. | | metadata | Reservado. Metadados com formatação JSON relacionados ao cluster implantado durante a execução do fluxo de trabalho. | | namespace | O namespace do Kubernetes no qual o cluster foi implantado. Exemplo: `default` | | recursos | Reservado. Metadados com formatação JSON relacionados aos recursos implantados durante a execução do fluxo de trabalho. | | servidor | O nome do endpoint do servidor de API que você pode usar para se comunicar com seu cluster usando ferramentas de gerenciamento, como `kubectl`. Para ter mais informações sobre o endpoint de serviço da API, consulte o [Controle de acesso ao endpoint do cluster do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) no **Guia do usuário do Amazon EKS**. Exemplo: `https://random-string.gr7.us-west-2.eks.amazonaws.com` | # YAML da ação “Implantar no cluster do Kubernetes” Confira a seguir a definição de YAML da ação **Implantar no cluster do Kubernetes**. Para saber como usar essa ação, consulte [Implantar no Amazon EKS com um fluxo de trabalho](deploy-action-eks.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. DeployToKubernetesCluster\$1nn: Identifier: aws/kubernetes-deploy@v1 DependsOn: - build-action Compute: - Type: EC2 | Lambda - Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: DeployToEKS Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - manifest-artifact Configuration: Namespace: namespace Region: us-east-1 Cluster: eks-cluster Manifests: manifest-path ``` ## DeployToKubernetesCluster (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Padrão: `DeployToKubernetesCluster_nn`. Interface de usuário correspondente: guia Configuração/**Nome de exibição da ação** ## Identifier (*DeployToKubernetesCluster*/**Identifier**) (Obrigatório) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Padrão: `aws/kubernetes-deploy@v1`. Interface de usuário correspondente: Diagrama de fluxo de trabalho/DeployToKubernetesCluster\$1nn/rótulo **aws/kubernetes-deploy@v1** ## DependsOn (*DeployToKubernetesCluster*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*DeployToKubernetesCluster*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*DeployToKubernetesCluster*/Compute/**Type**) (Obrigatório se [Compute](#deploy.action.eks.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2** (editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). **UI correspondente: Configuração tab/Advanced - opcional/Tipo de computação** ## Fleet (*DeployToKubernetesCluster*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. **UI correspondente: configuração tab/Advanced - opcional/frota de computação** ## Timeout (*DeployToKubernetesCluster*/**Timeout**) (Optional) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Environment (*DeployToKubernetesCluster*/**Environment**) (Obrigatório) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*DeployToKubernetesCluster*/Environment/**Name**) (Obrigatório se [Environment](#deploy.action.eks.environment) for incluído) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*DeployToKubernetesCluster*/Environment/**Connections**) (Opcional nas versões mais recentes da ação; obrigatório nas versões mais antigas) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Name (*DeployToKubernetesCluster*/Environment/Connections/**Name**) (Optional) Especifique o nome da conexão da conta. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Role (*DeployToKubernetesCluster*/Environment/Connections/**Role**) (Obrigatório se [Connections](#deploy.action.eks.environment.connections) for incluído) Especifique o nome do perfil do IAM que a ação **Implantar no cluster do Kubernetes** usa para acessar a AWS. Certifique-se de ter [adicionado a função ao seu CodeCatalyst espaço](ipa-connect-account-addroles.md) e de que a função inclua as seguintes políticas. Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas a seguir. + A política de permissões a seguir: **Atenção** Limite as permissões às exibidas na política a seguir. Usar um perfil com permissões mais amplas pode representar um risco de segurança. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] } ``` ------ **nota** Na primeira vez em que o perfil for usado, use o caractere curinga a seguir na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` + A política de confiança personalizada a seguir: Esse perfil deve ser adicionado a: + Sua conexão de conta. Para saber mais sobre como adicionar um perfil do IAM a uma conexão de conta, consulte [Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). + Seu Kubernetes ConfigMap. Para saber mais sobre como adicionar uma função do IAM a uma ConfigMap, consulte [Gerenciar usuários e funções do IAM](https://eksctl.io/usage/iam-identity-mappings/) na `eksctl` documentação. **dica** Consulte também [Tutorial: Implantar uma aplicação no Amazon EKS](deploy-tut-eks.md) para obter instruções sobre como adicionar uma função do IAM a uma conexão de conta ConfigMap e. **nota** Você pode usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação, se desejar. Para obter mais informações sobre esse perfil, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' '/ Função Environment/account/role** ## Inputs (*DeployToKubernetesCluster*/**Inputs**) (Obrigatório se [Connections](#deploy.action.eks.environment.connections) for incluído) A seção `Inputs` define os dados que `DeployToKubernetesCluster` precisa durante a execução de um fluxo de trabalho. **nota** Somente uma entrada (uma origem ou um artefato) é permitida por ação **Implantar no Amazon EKS**. Interface de usuário correspondente: guia **Entradas** ## Sources (*DeployToKubernetesCluster*/Inputs/**Sources**) (Obrigatório se o arquivo de manifesto estiver armazenado em um repositório de origem) Se os arquivos de manifesto do Kubernetes estiverem armazenados em um repositório de origem, especifique o rótulo do repositório de origem. Atualmente, o único rótulo compatível é `WorkflowSource`. Se os arquivos de manifesto não estiverem em um repositório de origem, eles deverão residir em um artefato gerado por outra ação. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*DeployToKubernetesCluster*/Inputs/**Artifacts**) (Obrigatório se o arquivo de manifesto estiver armazenado em um [artefato de saída](workflows-working-artifacts-output.md) de uma ação anterior) Se os arquivos de manifesto do Kubernetes estiverem contidos em um artefato gerado por uma ação anterior, especifique esse artefato aqui. Se os arquivos de manifesto não estiverem em um artefato, eles deverão residir em seu repositório de origem. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Configuração/**Artefatos - opcional** ## Configuration (*DeployToKubernetesCluster*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## Namespace (*DeployToKubernetesCluster*/Configuration/**Namespace**) (Optional) Especifique o namespace do Kubernetes no qual a aplicação Kubernetes será implantada. Use `default` se você não estiver usando namespaces com seu cluster. Para ter mais informações sobre namespaces, consulte [Subdivisão do cluster usando namespaces do Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#subdividing-your-cluster-using-kubernetes-namespaces) na documentação do Kubernetes. Se você omitir o namespace, um valor de `default` será usado. Interface de usuário correspondente: guia Configuração/**Namespace** ## Region (*DeployToKubernetesCluster*/Configuration/**Region**) (Obrigatório) Especifique a AWS região em que seu cluster e serviço do Amazon EKS residem. Para ver uma lista de códigos de região, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes) na *Referência geral da AWS*. Interface de usuário correspondente: guia Configuração/**Região** ## Cluster (*DeployToKubernetesCluster*/Configuration/**Cluster**) (Obrigatório) Especifique o nome de um cluster existente do Amazon EKS. A ação **Implantar no cluster do Kubernetes** implantará a aplicação em contêineres nesse cluster. Para ter informações sobre clusters do Amazon EKS, consulte [Clusters](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html) no **Guia do usuário do Amazon EKS**. Interface de usuário correspondente: guia Configuração/**Cluster** ## Manifests (*DeployToKubernetesCluster*/Configuration/**Manifests**) (Obrigatório) Especifique o caminho para seus arquivos de manifesto do Kubernetes formatados em YAML, que são chamados de *arquivos de configuração* ou, simplesmente, *configurações* na *documentação do Kubernetes*. Se você estiver usando vários arquivos de manifesto, coloque-os em uma única pasta e faça referência a essa pasta. Os arquivos de manifesto são processados alfanumericamente pelo Kubernetes, portanto, prefixe os nomes dos arquivos com números ou letras crescentes para controlar a ordem de processamento. Por exemplo: `00-namespace.yaml` `01-deployment.yaml` Se os arquivos de manifesto residirem em seu repositório de origem, o caminho é relativo à pasta raiz do repositório de origem. Se os arquivos residirem em um artefato de uma ação anterior do fluxo de trabalho, o caminho é relativo à pasta raiz do artefato. Exemplos: `Manifests/` `deployment.yaml` `my-deployment.yml` Não use curingas (`*`). **nota** Os [charts do Helm](https://helm.sh/docs/topics/charts/) e os [arquivos de personalização](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/) não são aceitos. Para ter mais informações sobre os arquivos de manifesto, consulte [Como organizar as configurações de recursos](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#organizing-resource-configurations) na documentação do Kubernetes. Interface de usuário correspondente: guia Configuração/**Manifestos** # Implantação de uma pilha CloudFormation Esta seção descreve como implantar uma AWS CloudFormation pilha usando um CodeCatalyst fluxo de trabalho. Para fazer isso, você deve adicionar a ação **Deploy CloudFormation stack** ao seu fluxo de trabalho. A ação implanta uma CloudFormation pilha de recursos AWS com base em um modelo fornecido por você. O modelo pode ser um: + CloudFormation modelo — Para obter mais informações, consulte Como [trabalhar com CloudFormation modelos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html). + AWS SAM modelo — Para obter mais informações, consulte a [especificação AWS Serverless Application Model (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html). **nota** Para usar um AWS SAM modelo, primeiro você deve empacotar seu AWS SAM aplicativo usando a `[sam package](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-package.html)` operação. Para ver um tutorial que mostra como fazer esse empacotamento automaticamente como parte de um CodeCatalyst fluxo de trabalho da Amazon, consulte[Tutorial: Implantar uma aplicação sem servidor](deploy-tut-lambda.md). Se a pilha já existir, a ação executará a CloudFormation `[CreateChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html)` operação e, em seguida, a `[ExecuteChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ExecuteChangeSet.html)` operação. A ação espera que as alterações sejam implantadas e se marca como bem-sucedida ou com falha, dependendo dos resultados. Use a ação **Deploy CloudFormation stack** se você já tiver um AWS SAM modelo CloudFormation ou que contenha recursos que gostaria de implantar, ou se planeja gerar um automaticamente como parte de uma [ação de criação](build-add-action.md) de fluxo de trabalho usando ferramentas como AWS SAM e. [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) Não há restrições sobre o modelo que você pode usar, seja o que for que você possa criar CloudFormation ou AWS SAM usar com a ação **Deploy CloudFormation stack**. **dica** Para ver um tutorial que mostra como implantar um aplicativo sem servidor usando a ação **Deploy CloudFormation stack**, consulte. [Tutorial: Implantar uma aplicação sem servidor](deploy-tut-lambda.md) **Topics** + [ ## Imagem de tempo de execução usada pela ação 'Deploy CloudFormation stack' ](#deploy-action-cfn-runtime) + [ # Tutorial: Implantar uma aplicação sem servidor ](deploy-tut-lambda.md) + [ # Adicionando a ação “Deploy CloudFormation stack” ](deploy-action-cfn-adding.md) + [ # Configurar reversões ](deploy-consumption-enable-alarms.md) + [ # Variáveis de “ CloudFormation pilha de implantação” ](deploy-action-cfn-variables.md) + [ # Ação “Implantar CloudFormation pilha” YAML ](deploy-action-ref-cfn.md) ## Imagem de tempo de execução usada pela ação 'Deploy CloudFormation stack' A ação **Deploy CloudFormation stack** é executada em uma [imagem de novembro de 2022](build-images.md#build.previous-image). Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). # Tutorial: Implantar uma aplicação sem servidor Neste tutorial, você aprende a criar, testar e implantar um aplicativo sem servidor como uma CloudFormation pilha usando um fluxo de trabalho. A aplicação neste tutorial é uma aplicação web simples que gera uma mensagem “Hello World”. Ele consiste em uma AWS Lambda função e um Amazon API Gateway, e você o cria usando o [AWS Serverless Application Model (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html), que é uma extensão do [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html). **Topics** + [ ## Pré-requisitos ](#deploy-tut-lambda-cfn-prereqs) + [ ## Etapa 1: criar um repositório de origem ](#deploy-tut-lambda-cfn-source) + [ ## Etapa 2: criar AWS funções ](#deploy-tut-lambda-cfn-roles) + [ ## Etapa 3: adicionar AWS funções a CodeCatalyst ](#deploy-tut-lambda-cfn-roles-add) + [ ## Etapa 4: criar um bucket do Amazon S3 ](#deploy-tut-lambda-cfn-s3) + [ ## Etapa 5: adicionar arquivos de origem ](#deploy-tut-lambda-cfn-files) + [ ## Etapa 6: criar e executar um fluxo de trabalho ](#deploy-tut-lambda-cfn-workflow) + [ ## Etapa 7: fazer uma alteração ](#deploy-tut-lambda-cfn-change) + [ ## Limpeza ](#deploy-tut-lambda-cfn-clean-up) ## Pré-requisitos Antes de começar + Você precisa de um CodeCatalyst **espaço** com uma AWS conta conectada. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). + Em seu espaço, você precisa de um projeto vazio chamado: ``` codecatalyst-cfn-project ``` Use a opção **Começar do zero** para criar esse projeto. Para obter mais informações, consulte [Criando um projeto vazio na Amazon CodeCatalyst](projects-create.md#projects-create-empty). + Em seu projeto, você precisa de um CodeCatalyst **ambiente** chamado: ``` codecatalyst-cfn-environment ``` Configure esse ambiente da seguinte forma: + Escolha qualquer tipo, como **Não produção**. + Conecte sua AWS conta a ela. + Para o **Perfil do IAM padrão**, escolha qualquer perfil. Você especificará um perfil diferente posteriormente. Para obter mais informações, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md). ## Etapa 1: criar um repositório de origem Nesta etapa, você cria um repositório de origem no CodeCatalyst. Esse repositório é usado para armazenar os arquivos de origem do tutorial, como o arquivo da função do Lambda. Para ter mais informações sobre repositórios de origem, consulte [Criar um repositório de origem](source-repositories-create.md). **Como criar um repositório de origem** 1. Em CodeCatalyst, no painel de navegação, escolha **Código** e, em seguida, escolha **Repositórios de origem**. 1. Escolha **Adicionar repositório** e selecione **Criar repositório**. 1. Em **Nome do repositório**, insira: ``` codecatalyst-cfn-source-repository ``` 1. Escolha **Criar**. Agora você criou um repositório chamado `codecatalyst-cfn-source-repository`. ## Etapa 2: criar AWS funções Nesta etapa, você cria as seguintes funções AWS do IAM: + **Função de implantação** — concede permissão à ação CodeCatalyst **Deploy CloudFormation stack** para acessar sua AWS conta e CloudFormation serviço onde você implantará seu aplicativo sem servidor. A ação **Deploy CloudFormation stack** faz parte do seu fluxo de trabalho. + **Função de criação** — concede à ação de CodeCatalyst criação permissão para acessar sua AWS conta e gravar no Amazon S3, onde seu pacote de aplicativos sem servidor será armazenado. A ação de criação faz parte do seu fluxo de trabalho. + **Função do Stack** — concede CloudFormation permissão para ler e modificar os recursos especificados no AWS SAM modelo que você fornecerá posteriormente. Também concede permissão para CloudWatch. Para ter informações sobre perfis do IAM, consulte [Perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) no *Guia do usuário do AWS Identity and Access Management *. **nota** Para economizar tempo, você pode criar um único perfil, chamado `CodeCatalystWorkflowDevelopmentRole-spaceName`, em vez dos três perfis listados anteriormente. Para obter mais informações, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões bem amplas que podem representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Este tutorial pressupõe que você esteja criando os três perfis listados anteriormente. **nota** Um [perfil de execução do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) também é necessário, mas você não precisa criá-lo agora porque o arquivo `sam-template.yml` o cria quando você executa o fluxo de trabalho na etapa 5. **Para criar um perfil de implantação** 1. Crie uma política para o perfil da seguinte maneira: 1. Faça login em AWS. 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação, selecione **Políticas**. 1. Escolha **Criar política**. 1. Escolha a guia **JSON**. 1. Exclua o código existente. 1. Cole o seguinte código: **nota** Na primeira vez em que o perfil for usado para executar ações de fluxo de trabalho, use o caractere curinga na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` 1. Escolha **Próximo: tags**. 1. Selecione **Próximo: revisar**. 1. Em **Nome**, insira: ``` codecatalyst-deploy-policy ``` 1. Selecione **Criar política**. Agora você criou uma política de permissões. 1. Crie o perfil de implantação, da seguinte forma: 1. No painel de navegação, escolha **Perfis** e **Criar perfil**. 1. Selecione **Política de confiança personalizada**. 1. Exclua a política de confiança personalizada existente. 1. Adicione a política de confiança personalizada a seguir: 1. Escolha **Próximo**. 1. Em **Políticas de permissões**, procure `codecatalyst-deploy-policy` e marque a caixa de seleção. 1. Escolha **Próximo**. 1. Em **Nome do perfil**, insira: ``` codecatalyst-deploy-role ``` 1. Em **Descrição do perfil**, insira: ``` CodeCatalyst deploy role ``` 1. Selecione **Criar perfil**. Agora você criou um perfil de implantação com uma política de confiança e uma política de permissões. 1. Obtenha o ARN do perfil de implantação, da seguinte forma: 1. No painel de navegação, selecione **Perfis**. 1. Na caixa de pesquisa, insira o nome do perfil que você acabou de criar (`codecatalyst-deploy-role`). 1. Escolha o perfil na lista. A página **Resumo** do perfil é exibida. 1. Na parte superior, copie o valor do **ARN**. Agora você criou o perfil de implantação com as permissões apropriadas e obteve o ARN. **Como criar um perfil de criação** 1. Crie uma política para o perfil da seguinte maneira: 1. Faça login em AWS. 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação, selecione **Políticas**. 1. Escolha **Criar política**. 1. Escolha a guia **JSON**. 1. Exclua o código existente. 1. Cole o seguinte código: **nota** Na primeira vez em que o perfil for usado para executar ações de fluxo de trabalho, use o caractere curinga na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` 1. Escolha **Próximo: tags**. 1. Selecione **Próximo: revisar**. 1. Em **Nome**, insira: ``` codecatalyst-build-policy ``` 1. Selecione **Criar política**. Agora você criou uma política de permissões. 1. Crie o perfil de criação, da seguinte forma: 1. No painel de navegação, escolha **Perfis** e **Criar perfil**. 1. Selecione **Política de confiança personalizada**. 1. Exclua a política de confiança personalizada existente. 1. Adicione a política de confiança personalizada a seguir: 1. Escolha **Próximo**. 1. Em **Políticas de permissões**, procure `codecatalyst-build-policy` e marque a caixa de seleção. 1. Escolha **Próximo**. 1. Em **Nome do perfil**, insira: ``` codecatalyst-build-role ``` 1. Em **Descrição do perfil**, insira: ``` CodeCatalyst build role ``` 1. Selecione **Criar perfil**. Agora você criou um perfil de criação com uma política de confiança e uma política de permissões. 1. Obtenha o ARN do perfil de criação, da seguinte forma: 1. No painel de navegação, selecione **Perfis**. 1. Na caixa de pesquisa, insira o nome do perfil que você acabou de criar (`codecatalyst-build-role`). 1. Escolha o perfil na lista. A página **Resumo** do perfil é exibida. 1. Na parte superior, copie o valor do **ARN**. Agora você criou o perfil de criação com as permissões apropriadas e obteve o ARN. **Para criar um perfil de pilha** 1. Faça login AWS usando a conta na qual você deseja implantar sua pilha. 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Crie o perfil de pilha, da seguinte forma: 1. No painel de navegação, selecione **Perfis**. 1. Escolha **Criar Perfil**. 1. Selecione **Serviço da AWS **. 1. Na seção **Caso de uso**, escolha na **CloudFormation**lista suspensa. 1. Selecione o botão **CloudFormation**de rádio. 1. Selecione **Avançar** na parte inferior. 1. Usando a caixa de pesquisa, encontre as políticas de permissões a seguir e marque as respectivas caixas de seleção. **nota** Se você procurar uma política e ela não aparecer, selecione **Limpar filtros** e tente novamente. + **CloudWatchFullAccess** + **AWS CloudFormationFullAccess** + **IAMFullAcesso** + **AWS Lambda\$1 FullAccess** + **APIGatewayAdministrador da Amazon** + **Amazon S3 FullAccess** + **AmazonEC2ContainerRegistryFullAccess** A primeira política permite o acesso para CloudWatch habilitar reversões de pilha quando ocorre um alarme. As políticas restantes permitem AWS SAM acessar os serviços e recursos na pilha que serão implantados neste tutorial. Para ter mais informações, consulte [Permissões](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html) no *Guia do desenvolvedor do AWS Serverless Application Model *. 1. Escolha **Próximo**. 1. Em **Nome do perfil**, insira: ``` codecatalyst-stack-role ``` 1. Selecione **Criar perfil**. 1. Obtenha o ARN do perfil de pilha, da seguinte forma: 1. No painel de navegação, selecione **Perfis**. 1. Na caixa de pesquisa, insira o nome do perfil que você acabou de criar (`codecatalyst-stack-role`). 1. Escolha o perfil na lista. 1. Na seção **Resumo**, copie o valor de **ARN**. Você precisará disso mais tarde. Agora você criou o perfil de pilha com as permissões apropriadas e obteve o ARN. ## Etapa 3: adicionar AWS funções a CodeCatalyst Nesta etapa, você adiciona a função de criação (`codecatalyst-build-role`) e a função de implantação (`codecatalyst-deploy-role`) à conexão da CodeCatalyst conta em seu espaço. **nota** Não é necessário adicionar o perfil de pilha (`codecatalyst-stack-role`) à conexão. Isso ocorre porque a função de pilha é usada por *CloudFormation*(não CodeCatalyst), *depois* que uma conexão já foi estabelecida entre CodeCatalyst e AWS usando a função de implantação. Como a função de pilha não é usada por CodeCatalyst para obter acesso AWS, ela não precisa ser associada a uma conexão de conta. **Para adicionar perfis de criação e implantação à conexão da sua conta** 1. Dentro CodeCatalyst, navegue até seu espaço. 1. Selecione **Contas da AWS **. Uma lista de conexões de conta é exibida. 1. Escolha a conexão de conta que representa a AWS conta em que você criou suas funções de criação e implantação. 1. Escolha **Gerenciar funções no console de AWS gerenciamento**. A página **Adicionar função do IAM ao CodeCatalyst espaço da Amazon** é exibida. Talvez seja necessário fazer login para acessá-la. 1. Selecione **Adicionar um perfil existente que você criou no IAM**. Uma lista suspensa aparece. A lista exibe todos os perfis do IAM com uma política de confiança que inclui as entidades principais de serviço `codecatalyst-runner.amazonaws.com` e `codecatalyst.amazonaws.com`. 1. Na lista suspensa, selecione `codecatalyst-build-role` e **Adicionar perfil**. 1. Escolha **Adicionar perfil do IAM**, selecione **Adicionar um perfil existente que você criou no IAM** e, na lista suspensa, escolha `codecatalyst-deploy-role`. Escolha **Add role (adicionar função)**. Agora você adicionou os perfis de criação e implantação ao seu espaço. 1. Copie o valor do **nome de CodeCatalyst exibição da Amazon**. Esse valor será necessário posteriormente, ao criar seu fluxo de trabalho. ## Etapa 4: criar um bucket do Amazon S3 Nesta etapa, você cria um bucket do Amazon S3 no qual armazena o arquivo .zip do pacote de implantação da aplicação sem servidor. **Como criar um bucket do Amazon S3** 1. Abra o console do Amazon S3 em [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. No painel principal, selecione **Criar bucket**. 1. Em **Nome do bucket**, insira: ``` codecatalyst-cfn-s3-bucket ``` 1. Na **região da AWS **, escolha uma região. Este tutorial pressupõe que você tenha escolhido o **Oeste dos EUA (Oregon) us-west-2**. Para ter informações sobre regiões com suporte do Amazon S3, consulte [Endpoints e cotas do Amazon Simple Storage Service](https://docs.aws.amazon.com/general/latest/gr/s3.html) na *Referência geral da AWS*. 1. Selecione **Criar bucket** na parte inferior da página. Agora você criou um bucket chamado **codecatalyst-cfn-s3-bucket** na região Oeste dos EUA (Oregon), us-west-2. ## Etapa 5: adicionar arquivos de origem Nesta etapa, você adiciona vários arquivos de origem do aplicativo ao seu repositório CodeCatalyst de origem. A pasta `hello-world` contém os arquivos da aplicação que você implantará. A pasta `tests` contém testes de unidade. A estrutura de pastas é esta: ``` . |— hello-world | |— tests | |— unit | |— test-handler.js | |— app.js |— .npmignore |— package.json |— sam-template.yml |— setup-sam.sh ``` ### Arquivo .npmignore O arquivo `.npmignore` indica quais arquivos e pastas o npm deve excluir do pacote da aplicação. Neste tutorial, o npm exclui a pasta `tests` porque ela não faz parte da aplicação. **Como adicionar o arquivo .npmignore** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto, `codecatalyst-cfn-project` 1. No painel de navegação, selecione **Código** e, depois, selecione **Repositórios de origem**. 1. Na lista de repositórios de origem, escolha o seu repositório, `codecatalyst-cfn-source-repository`. 1. Em **Arquivos**, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` .npmignore ``` 1. Na caixa de texto, insira o código a seguir: ``` tests/* ``` 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. Agora você criou um arquivo chamado `.npmignore` na raiz do repositório. ### Arquivo package.json O arquivo `package.json` contém metadados importantes sobre seu projeto Node, como nome do projeto, número da versão, descrição, dependências e outros detalhes que descrevem como interagir e executar a aplicação. O `package.json` neste tutorial inclui uma lista de dependências e um script `test`. O script de teste faz o seguinte: + Usando [mocha](https://mochajs.org/), o script de teste executa os testes de unidade especificados em `hello-world/tests/unit/` e grava os resultados em um arquivo `junit.xml` usando o repórter [xunit](). + Usando [Istambul (nyc)](https://istanbul.js.org/), o script de teste gera um relatório de cobertura de código (`clover.xml`) usando o repórter [clover](https://openclover.org/doc/manual/4.2.0/general--about-openclover.html). Para ter mais informações, consulte [Uso de repórteres alternativos](https://istanbul.js.org/docs/advanced/alternative-reporters/#clover) na documentação do Istambul. **Como adicionar o arquivo package.json** 1. No repositório, em **Arquivos**, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` package.json ``` 1. Na caixa de texto, insira o código a seguir: ``` { "name": "hello_world", "version": "1.0.0", "description": "hello world sample for NodeJS", "main": "app.js", "repository": "https://github.com/awslabs/aws-sam-cli/tree/develop/samcli/local/init/templates/cookiecutter-aws-sam-hello-nodejs", "author": "SAM CLI", "license": "MIT", "dependencies": { "axios": "^0.21.1", "nyc": "^15.1.0" }, "scripts": { "test": "nyc --reporter=clover mocha hello-world/tests/unit/ --reporter xunit --reporter-option output=junit.xml" }, "devDependencies": { "aws-sdk": "^2.815.0", "chai": "^4.2.0", "mocha": "^8.2.1" } } ``` 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. Agora você adicionou um arquivo chamado `package.json` à raiz do repositório. ### Arquivo sam-template.yml O arquivo `sam-template.yml` contém as instruções para implantar a função do Lambda e o gateway de API e configurá-los juntos. Ele segue a [especificação do AWS Serverless Application Model modelo](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html), que estende a especificação do CloudFormation modelo. Você usa um AWS SAM modelo neste tutorial em vez de um CloudFormation modelo normal porque AWS SAM oferece um tipo de recurso útil [AWS: :Serverless: :Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html). Esse tipo executa muitas behind-the-scenes configurações que você normalmente precisa escrever para usar a CloudFormation sintaxe básica. Por exemplo, o `AWS::Serverless::Function` cria uma função do Lambda, uma função de execução do Lambda e mapeamentos da origem do evento que iniciam a função. Você precisa codificar tudo isso se quiser escrevê-lo usando o básico CloudFormation. Embora este tutorial use um modelo pré-escrito, você pode gerar um como parte do seu fluxo de trabalho usando uma ação de criação. Para obter mais informações, consulte [Implantação de uma pilha CloudFormation](deploy-action-cfn.md). **Para adicionar o arquivo sam-template.yml** 1. No repositório, em **Arquivos**, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` sam-template.yml ``` 1. Na caixa de texto, insira o código a seguir: ``` AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > serverless-api Sample SAM Template for serverless-api # More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst Globals: Function: Timeout: 3 Resources: HelloWorldFunction: Type: AWS::Serverless::Function # For details on this resource type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction Properties: CodeUri: hello-world/ Handler: app.lambdaHandler Runtime: nodejs12.x Events: HelloWorld: Type: Api # For details on this event source type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api Properties: Path: /hello Method: get Outputs: # ServerlessRestApi is an implicit API created out of the events key under Serverless::Function # Find out about other implicit resources you can reference within AWS SAM at # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api HelloWorldApi: Description: "API Gateway endpoint URL for the Hello World function" Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/" HelloWorldFunction: Description: "Hello World Lambda function ARN" Value: !GetAtt HelloWorldFunction.Arn HelloWorldFunctionIamRole: Description: "Implicit Lambda execution role created for the Hello World function" Value: !GetAtt HelloWorldFunctionRole.Arn ``` 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. Agora você adicionou um arquivo chamado `sam-template.yml` à pasta raiz do repositório. ### Arquivo setup-sam.sh O `setup-sam.sh` arquivo contém as instruções para baixar e instalar o utilitário AWS SAM CLI. O fluxo de trabalho usa esse utilitário para empacotar a origem de `hello-world`. **Para adicionar o arquivo setup-sam.sh** 1. No repositório, em **Arquivos**, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` setup-sam.sh ``` 1. Na caixa de texto, insira o código a seguir: ``` #!/usr/bin/env bash echo "Setting up sam" yum install unzip -y curl -LO https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip unzip -qq aws-sam-cli-linux-x86_64.zip -d sam-installation-directory ./sam-installation-directory/install; export AWS_DEFAULT_REGION=us-west-2 ``` No código anterior, *us-west-2* substitua por sua AWS região. 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. Agora você adicionou um arquivo chamado `setup-sam.sh` à raiz do repositório. ### Arquivo app.js O `app.js` contém o código da função do Lambda. Neste tutorial, o código retorna o texto `hello world`. **Para adicionar o arquivo app.js** 1. No repositório, em **Arquivos**, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` hello-world/app.js ``` 1. Na caixa de texto, insira o código a seguir: ``` // const axios = require('axios') // const url = 'http://checkip.amazonaws.com/'; let response; /** * * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format * @param {Object} event - API Gateway Lambda Proxy Input Format * * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html * @param {Object} context * * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html * @returns {Object} object - API Gateway Lambda Proxy Output Format * */ exports.lambdaHandler = async (event, context) => { try { // const ret = await axios(url); response = { 'statusCode': 200, 'body': JSON.stringify({ message: 'hello world', // location: ret.data.trim() }) } } catch (err) { console.log(err); return err; } return response }; ``` 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. Agora você criou uma pasta chamada `hello-world` e um arquivo chamado `app.js`. ### Arquivo test-handler.js O arquivo `test-handler.js` contém testes de unidade para a função do Lambda. **Para adicionar o arquivo test-handler.js** 1. No repositório, em **Arquivos**, selecione **Criar arquivo**. 1. Em **Nome do arquivo**, insira: ``` hello-world/tests/unit/test-handler.js ``` 1. Na caixa de texto, insira o código a seguir: ``` 'use strict'; const app = require('../../app.js'); const chai = require('chai'); const expect = chai.expect; var event, context; describe('Tests index', function () { it('verifies successful response', async () => { const result = await app.lambdaHandler(event, context) expect(result).to.be.an('object'); expect(result.statusCode).to.equal(200); expect(result.body).to.be.an('string'); let response = JSON.parse(result.body); expect(response).to.be.an('object'); expect(response.message).to.be.equal("hello world"); // expect(response.location).to.be.an("string"); }); }); ``` 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. Agora você adicionou um arquivo chamado `test-handler.js` abaixo da pasta `hello-world/tests/unit`. Agora você adicionou todos os seus arquivos de origem. Reserve um momento para verificar seu trabalho e garantir que colocou todos os arquivos nas pastas corretas. A estrutura de pastas é esta: ``` . |— hello-world | |— tests | |— unit | |— test-handler.js | |— app.js |— .npmignore |— README.md |— package.json |— sam-template.yml |— setup-sam.sh ``` ## Etapa 6: criar e executar um fluxo de trabalho Nesta etapa, você cria um fluxo de trabalho que empacota o código-fonte do Lambda e o implanta. O fluxo de trabalho consiste nos seguintes blocos de compilação que são executados sequencialmente: + Um gatilho: esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + Uma ação de teste (`Test`) — No gatilho, essa ação instala o [gerenciador de pacotes Node (npm)](https://www.npmjs.com/) e, depois, executa o comando `npm run test`. Esse comando diz ao npm para executar o script `test` definido no arquivo `package.json`. O script `test`, por sua vez, executa os testes de unidade e gera dois relatórios: um relatório de teste (`junit.xml`) e um relatório de cobertura de código (`clover.xml`). Para obter mais informações, consulte [Arquivo package.json](#deploy-tut-lambda-cfn-files-package-json). Em seguida, a ação de teste transforma os relatórios XML em CodeCatalyst relatórios e os exibe no CodeCatalyst console, na guia **Relatórios** da ação de teste. Para ter mais informações sobre a ação de teste, consulte [Teste com fluxos de trabalhoTeste com fluxos de trabalho](test-workflow-actions.md). + Uma ação de construção (`BuildBackend`) — Ao concluir a ação de teste, a ação de compilação baixa e instala a AWS SAM CLI, empacota `hello-world` a fonte e copia o pacote em seu bucket do Amazon S3, onde o serviço Lambda espera que esteja. A ação também gera um novo arquivo de AWS SAM modelo chamado `sam-template-packaged.yml` e o coloca em um artefato de saída chamado. `buildArtifact` Para ter mais informações sobre a ação de criação, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). + Uma ação de implantação (`DeployCloudFormationStack`) — Ao concluir a ação de criação, a ação de implantação procura o artefato de saída gerado pela ação de construção (`buildArtifact`), encontra o AWS SAM modelo dentro dela e, em seguida, executa o modelo. O AWS SAM modelo cria uma pilha que implanta o aplicativo sem servidor. **Como criar um fluxo de trabalho** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho**. 1. Em **Repositório de origem**, selecione `codecatalyst-cfn-source-repository`. 1. Em **Ramificação**, selecione `main`. 1. Escolha **Criar**. 1. Exclua o código de amostra YAML. 1. Adicione o seguinte código YAML: **nota** No código YAML a seguir, você pode omitir as seções `Connections:` se quiser. Se você omitir essas seções, deverá garantir que o perfil especificado no campo **Perfil do IAM padrão** em seu ambiente inclua as permissões e as políticas de confiança dos dois perfis descritas em [Etapa 2: criar AWS funções](#deploy-tut-lambda-cfn-roles). Para ter mais informações sobre como configurar um ambiente com um perfil do IAM padrão, consulte [Criar um ambiente](deploy-environments-creating-environment.md). ``` Name: codecatalyst-cfn-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: Test: Identifier: aws/managed-test@v1 Inputs: Sources: - WorkflowSource Outputs: Reports: CoverageReport: Format: CLOVERXML IncludePaths: - "coverage/*" TestReport: Format: JUNITXML IncludePaths: - junit.xml Configuration: Steps: - Run: npm install - Run: npm run test BuildBackend: Identifier: aws/build@v1 DependsOn: - Test Environment: Name: codecatalyst-cfn-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-build-role Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: . ./setup-sam.sh - Run: sam package --template-file sam-template.yml --s3-bucket codecatalyst-cfn-s3-bucket --output-template-file sam-template-packaged.yml --region us-west-2 Outputs: Artifacts: - Name: buildArtifact Files: - "**/*" DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 DependsOn: - BuildBackend Environment: Name: codecatalyst-cfn-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-deploy-role Inputs: Artifacts: - buildArtifact Sources: [] Configuration: name: codecatalyst-cfn-stack region: us-west-2 role-arn: arn:aws:iam::111122223333:role/StackRole template: ./sam-template-packaged.yml capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND ``` No código anterior, substitua: + Ambas as instâncias de *codecatalyst-cfn-environment* com o nome do seu ambiente. + Ambas as instâncias *codecatalyst-account-connection* com o nome de exibição da conexão da sua conta. O nome de exibição pode ser um número. Para obter mais informações, consulte [Etapa 3: adicionar AWS funções a CodeCatalyst](#deploy-tut-lambda-cfn-roles-add). + *codecatalyst-build-role* pelo nome do perfil de criação criado em [Etapa 2: criar AWS funções](#deploy-tut-lambda-cfn-roles). + *codecatalyst-cfn-s3-bucket*com o nome do bucket do Amazon S3 em que você criou. [Etapa 4: criar um bucket do Amazon S3](#deploy-tut-lambda-cfn-s3) + Ambas as instâncias são *us-west-2* com a região em que seu bucket do Amazon S3 reside (primeira instância) e onde sua pilha será implantada (segunda instância). Essas regiões podem ser diferentes. Este tutorial pressupõe que as duas regiões estejam definidas como `us-west-2`. Para obter detalhes sobre regiões suportadas pelo Amazon S3 CloudFormation, consulte [Pontos de extremidade e cotas de serviço](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) no. *Referência geral da AWS* + *codecatalyst-deploy-role* pelo nome do perfil de implantação criado em [Etapa 2: criar AWS funções](#deploy-tut-lambda-cfn-roles). + *codecatalyst-cfn-environment*com o nome do ambiente em que você criou[Pré-requisitos](#deploy-tut-lambda-cfn-prereqs). + *arn:aws:iam::111122223333:role/StackRole*com o Amazon Resource Name (ARN) da função de pilha que você criou. [Etapa 2: criar AWS funções](#deploy-tut-lambda-cfn-roles) **nota** Se você decidiu não criar, implantar e empilhar funções *codecatalyst-build-role**codecatalyst-deploy-role*, substitua e *arn:aws:iam::111122223333:role/StackRole* pelo nome ou ARN da `CodeCatalystWorkflowDevelopmentRole-spaceName` função. Para obter mais informações sobre essa função, consulte [Etapa 2: criar AWS funções](#deploy-tut-lambda-cfn-roles). Para ter informações sobre as propriedades no código mostrado anteriormente, consulte a [Ação “Implantar CloudFormation pilha” YAML](deploy-action-ref-cfn.md). 1. (Opcional) Selecione **Validar** para garantir que o código YAML seja válido antes de confirmar. 1. Selecione **Confirmar**. 1. Na caixa de diálogo **Confirmar fluxo de trabalho**, insira o seguinte: 1. Em **Nome do arquivo do fluxo de trabalho**, mantenha o padrão, `codecatalyst-cfn-workflow`. 1. Em **Confirmar mensagem**, insira: ``` add initial workflow file ``` 1. Em **Repositório**, selecione **codecatalyst-cfn-source-repository**. 1. Em **Nome da ramificação**, selecione **principal**. 1. Selecione **Confirmar**. Agora você criou um fluxo de trabalho. A execução de um fluxo de trabalho é iniciada automaticamente devido ao gatilho definido na parte superior do fluxo de trabalho. Especificamente, quando você confirmou (e enviou) o arquivo `codecatalyst-cfn-workflow.yaml` ao repositório de origem, o gatilho iniciou a execução do fluxo de trabalho. **Para visualizar a execução do fluxo de trabalho em andamento** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha o fluxo de trabalho que você acabou de criar: `codecatalyst-cfn-workflow`. 1. Escolha a guia **Execuções**. 1. Na coluna **ID da execução**, escolha o ID da execução. 1. Selecione **Teste** para ver o andamento dos testes. 1. Escolha **BuildBackend**ver o progresso da compilação. 1. Escolha **DeployCloudFormationStack**ver o progresso da implantação. Para ter mais informações sobre como visualizar os detalhes da execução, consulte o [Visualização do status e detalhes de execução do fluxo de trabalho](workflows-view-run.md). 1. Quando a **DeployCloudFormationStack**ação terminar, faça o seguinte: + Se a execução do fluxo de trabalho for bem-sucedida, vá para o próximo procedimento. + Se a execução do fluxo de trabalho falhar no **teste** ou na **BuildBackend**ação, escolha **Logs** para solucionar o problema. + Se a execução do fluxo de trabalho falhar na **DeployCloudFormationStack**ação, escolha a ação de implantação e, em seguida, escolha a guia **Resumo**. Role até a seção de **CloudFormation eventos** para ver a mensagem de erro detalhada. Se ocorrer uma reversão, exclua a `codecatalyst-cfn-stack` pilha por meio do CloudFormation console AWS antes de executar novamente o fluxo de trabalho. **Como verificar a implantação** 1. Depois de uma implantação bem-sucedida, selecione **Variáveis (7)** na barra de menu horizontal próxima à parte superior. (Não selecione **Variáveis** no painel à direita.) 1. Em seguida **HelloWorldApi**, cole o `https://` URL em um navegador. Uma mensagem JSON **hello world** da função do Lambda é exibida, indicando que o fluxo de trabalho implantou e configurou a função do Lambda e o gateway de API. **dica** Você pode CodeCatalyst exibir esse URL no diagrama do fluxo de trabalho com algumas configurações pequenas. Para obter mais informações, consulte [Exibir o URL da aplicação no diagrama do fluxo de trabalho](deploy-app-url.md). **Para verificar os resultados do teste de unidade e a cobertura do código** 1. No diagrama do fluxo de trabalho, selecione **Teste** e, depois, escolha **Relatórios**. 1. Escolha **TestReport**visualizar os resultados do teste de unidade ou opte por **CoverageReport**visualizar os detalhes da cobertura de código dos arquivos que estão sendo testados, neste caso `app.js` `test-handler.js` e. **Para verificar os recursos implantados** 1. Faça login no Console de gerenciamento da AWS e abra o console do API Gateway em [https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/). 1. Observe a **codecatalyst-cfn-stack**API que o AWS SAM modelo criou. O nome da API vem do valor `Configuration/name` no arquivo de definição do fluxo de trabalho (`codecatalyst-cfn-workflow.yaml`). 1. Abra o AWS Lambda console em [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/). 1. Selecione **Funções** no painel de navegação. 1. Selecione a função do Lambda, `codecatalyst-cfn-stack-HelloWorldFunction-string`. 1. Você pode ver como o gateway de API é um gatilho para a função. Essa integração foi configurada automaticamente pelo tipo AWS SAM `AWS::Serverless::Function` de recurso. ## Etapa 7: fazer uma alteração Nesta etapa, você faz uma alteração no código-fonte do Lambda e o confirma. Essa confirmação inicia a execução de um novo fluxo de trabalho. Essa execução implanta a nova função do Lambda em um esquema azul esverdeado que usa a configuração padrão de mudança de tráfego especificada no console do Lambda. **Para fazer uma alteração na origem do Lambda** 1. Em CodeCatalyst, navegue até seu projeto. 1. No painel de navegação, selecione **Código** e, depois, selecione **Repositórios de origem**. 1. Escolha seu repositório de origem `codecatalyst-cfn-source-repository`. 1. Altere o arquivo da aplicação: 1. Escolha a pasta `hello-world`. 1. Escolha o arquivo `app.js`. 1. Escolha **Editar**. 1. Na linha 23, altere `hello world` para **Tutorial complete\$1**. 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. A confirmação faz com que uma execução do fluxo de trabalho seja iniciada. Essa execução falhará porque você não atualizou os testes de unidade para refletir a alteração do nome. 1. Atualize os testes de unidade: 1. Selecione `hello-world\tests\unit\test-handler.js`. 1. Escolha **Editar**. 1. Na linha 19, altere `hello world` para **Tutorial complete\$1**. 1. Selecione **Confirmar** e, depois, escolha **Confirmar** novamente. A confirmação faz com que outra execução do fluxo de trabalho seja iniciada. Essa execução será bem-sucedida. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione `codecatalyst-cfn-workflow` e **Execuções**. 1. Escolha o ID da última execução. O status ainda deve ser em andamento. 1. Escolha **Testar **BuildBackend****, e **DeployCloudFormationStack**para ver o progresso da execução do fluxo de trabalho. 1. Quando o fluxo de trabalho terminar, selecione **Variáveis (7)** na parte superior. 1. Em seguida **HelloWorldApi**, cole o `https://` URL em um navegador. Uma mensagem `Tutorial complete!` aparece no navegador, indicando que a nova aplicação foi implantada. ## Limpeza Limpe os arquivos e serviços usados neste tutorial para evitar cobranças por eles. **Para limpar no CodeCatalyst console** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Exclua `codecatalyst-cfn-workflow`. 1. Exclua `codecatalyst-cfn-environment`. 1. Exclua `codecatalyst-cfn-source-repository`. 1. Exclua `codecatalyst-cfn-project`. **Para limpar no Console de gerenciamento da AWS** 1. Limpe da CloudFormation seguinte forma: 1. Abra o CloudFormation console em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. Exclua o `codecatalyst-cfn-stack`. A exclusão da pilha remove todos os recursos do tutorial dos serviços do gateway de API e Lambda. 1. Limpe no Amazon S3, da seguinte forma: 1. Abra o console do Amazon S3 em [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Selecione a `codecatalyst-cfn-s3-bucket`. 1. Exclua os conteúdos do bucket. 1. Exclua o bucket. 1. Limpe no IAM, da seguinte forma: 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Exclua o `codecatalyst-deploy-policy`. 1. Exclua o `codecatalyst-build-policy`. 1. Exclua o `codecatalyst-stack-policy`. 1. Exclua o `codecatalyst-deploy-role`. 1. Exclua o `codecatalyst-build-role`. 1. Exclua o `codecatalyst-stack-role`. Neste tutorial, você aprendeu a implantar um aplicativo sem servidor como uma CloudFormation pilha usando um CodeCatalyst fluxo de trabalho e uma ação **Deploy CloudFormation ** stack. # Adicionando a ação “Deploy CloudFormation stack” Use as instruções a seguir para adicionar a ação **Deploy CloudFormation stack** ao seu fluxo de trabalho. ------ #### [ Visual ] **Para adicionar a ação “Implantar CloudFormation pilha” usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Pesquise a ação **Deploy CloudFormation stack** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Escolha **Deploy CloudFormation stack**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Download** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [Ação “Implantar CloudFormation pilha” YAML](deploy-action-ref-cfn.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar a ação “Implantar CloudFormation pilha” usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Pesquise a ação **Deploy CloudFormation stack** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Escolha **Deploy CloudFormation stack**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Download** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [Ação “Implantar CloudFormation pilha” YAML](deploy-action-ref-cfn.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Configurar reversões Por padrão, se a ação **Implantar CloudFormation pilha** falhar, ela fará CloudFormation com que a pilha volte para o último estado estável conhecido. Você pode alterar o comportamento para que as reversões ocorram não apenas quando a ação falhar, mas também quando ocorrer um CloudWatch alarme específico da Amazon. Para obter mais informações sobre CloudWatch alarmes, consulte [Usando CloudWatch alarmes da Amazon no Guia CloudWatch ](https://docs.aws.amazon.com/) *do usuário da Amazon*. Você também pode alterar o comportamento padrão para que CloudFormation não reverta a pilha quando a ação falhar. Use as instruções a seguir para configurar reversões. **nota** Você não pode iniciar uma reversão manualmente. ------ #### [ Visual ] **Antes de começar** 1. Certifique-se de ter um [fluxo de trabalho](workflow.md) que inclua uma ação funcional do **Deploy CloudFormation stack**. Para obter mais informações, consulte [Implantação de uma pilha CloudFormation](deploy-action-cfn.md). 1. Na função especificada no campo **opcional Função da pilha -** da ação **Implantar CloudFormation pilha**, certifique-se de incluir a **CloudWatchFullAccess**permissão. Para ter informações sobre como criar esse perfil com as permissões apropriadas, consulte [Etapa 2: criar AWS funções](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles). **Para configurar alarmes de reversão para a ação “Implantar pilha” CloudFormation** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. Escolha sua ação **Deploy CloudFormation stack**. 1. No painel de detalhes, selecione **Configuração**. 1. Na parte inferior, expanda **Avançado**. 1. Em **Monitorar alarme ARNs**, escolha **Adicionar alarme**. 1. Insira informações nos seguintes campos. + **ARN do alarme** Especifique o Amazon Resource Name (ARN) de um CloudWatch alarme da Amazon para usar como gatilho de reversão. Por exemplo, .`arn:aws:cloudwatch::123456789012:alarm/MyAlarm` Você pode ter no máximo cinco gatilhos de reversão. **nota** Se você especificar um ARN de CloudWatch alarme, também precisará configurar permissões adicionais para permitir o acesso à ação. CloudWatch Para obter mais informações, consulte [Configurar reversões](#deploy-consumption-enable-alarms). + **Tempo de monitoramento** Especifique um período de tempo, de 0 a 180 minutos, durante o qual CloudFormation monitora os alarmes especificados. O monitoramento começa *após* a implantação de todos os recursos da pilha. Se o alarme ocorrer dentro do tempo de monitoramento especificado, a implantação falhará e CloudFormation reverterá toda a operação da pilha. Padrão: 0. CloudFormation monitora apenas os alarmes enquanto os recursos da pilha estão sendo implantados, não depois. ------ #### [ YAML ] **Para configurar acionadores de reversão para a ação “Implantar pilha” CloudFormation** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha o nome de um fluxo de trabalho que inclua a ação **Implantar pilha do CloudFormation **. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Adicione as propriedades `monitor-alarm-arns` e `monitor-timeout-in-minutes` no código YAML para adicionar gatilhos de reversão. Para ver uma explicação de cada propriedade, consulte [Ação “Implantar CloudFormation pilha” YAML](deploy-action-ref-cfn.md). 1. Na função especificada na `role-arn` propriedade da ação **Deploy CloudFormation stack**, certifique-se de incluir a **CloudWatchFullAccess**permissão. Para ter informações sobre como criar esse perfil com as permissões apropriadas, consulte [Etapa 2: criar AWS funções](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles). ------ ------ #### [ Visual ] **Para desativar as reversões da ação “Implantar pilha” CloudFormation** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha o nome de um fluxo de trabalho que inclua a ação **Implantar pilha do CloudFormation **. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. Escolha sua ação **Deploy CloudFormation stack**. 1. No painel de detalhes, selecione **Configuração**. 1. Na parte inferior, expanda **Avançado**. 1. Ative a opção **Desabilitar reversão**. ------ #### [ YAML ] **Para desativar as reversões da ação “Implantar pilha” CloudFormation** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha o nome de um fluxo de trabalho que inclua a ação **Implantar pilha do CloudFormation **. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Adicione a propriedade `disable-rollback: 1` no código YAML para interromper as reversões. Para ver uma explicação dessa propriedade, consulte [Ação “Implantar CloudFormation pilha” YAML](deploy-action-ref-cfn.md). ------ # Variáveis de “ CloudFormation pilha de implantação” A ação **Deploy CloudFormation stack** produz e define as seguintes variáveis em tempo de execução. Elas são conhecidas como *variáveis predefinidas*. Para ter informações sobre como referenciar essas variáveis em um fluxo de trabalho, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). | Chave | Valor | | --- | --- | | deployment-platform | O nome da plataforma de implantação. Codificado para `AWS:CloudFormation`. | | region | O código da região em Região da AWS que foi implantado durante a execução do fluxo de trabalho. Exemplo: `us-west-2` | | stack-id | O nome do recurso da Amazon (ARN) da pilha implantada. Exemplo: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cfn-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` | # Ação “Implantar CloudFormation pilha” YAML A seguir está a definição YAML da ação **Deploy CloudFormation stack**. Para saber como usar essa ação, consulte [Implantação de uma pilha CloudFormation](deploy-action-cfn.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 DependsOn: - build-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: DeployRole Inputs: Sources: - source-name-1 Artifacts: - CloudFormation-artifact Configuration: name: stack-name region: us-west-2 template: template-path role-arn: arn:aws:iam::123456789012:role/StackRole capabilities: CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND parameter-overrides: KeyOne=ValueOne,KeyTwo=ValueTwo | path-to-JSON-file no-execute-changeset: 1|0 fail-on-empty-changeset: 1|0 disable-rollback: 1|0 termination-protection: 1|0 timeout-in-minutes: minutes notification-arns: arn:aws:sns:us-east-1:123456789012:MyTopic,arn:aws:sns:us-east-1:123456789012:MyOtherTopic monitor-alarm-arns: arn:aws:cloudwatch::123456789012:alarm/MyAlarm,arn:aws:cloudwatch::123456789012:alarm/MyOtherAlarm monitor-timeout-in-minutes: minutes tags: '[{"Key":"MyKey1","Value":"MyValue1"},{"Key":"MyKey2","Value":"MyValue2"}]' ``` ## DeployCloudFormationStack (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Padrão: `DeployCloudFormationStack_nn`. Interface de usuário correspondente: guia Configuração/**Nome de exibição da ação** ## Identifier (*DeployCloudFormationStack*/**Identifier**) (Obrigatório) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Padrão: `aws/cfn-deploy@v1`. Interface de usuário correspondente: rótulo do diagrama de fluxo de trabalho/DeployCloudFormationStack\$1nn/**aws/cfn-deploy@v1** ## DependsOn (*DeployCloudFormationStack*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*DeployCloudFormationStack*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*DeployCloudFormationStack*/Compute/**Type**) (Obrigatório se [Compute](#deploy.action.cfn.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2** (editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). **UI correspondente: Configuração tab/Advanced - opcional/Tipo de computação** ## Fleet (*DeployCloudFormationStack*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. **UI correspondente: configuração tab/Advanced - opcional/frota de computação** ## Timeout (*DeployCloudFormationStack*/**Timeout**) (Optional) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite em minutos - opcional** ## Environment (*DeployCloudFormationStack*/**Environment**) (Obrigatório) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*DeployCloudFormationStack*/Environment/**Name**) (Obrigatório se [Environment](#deploy.action.cfn.environment) for incluído) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*DeployCloudFormationStack*/Environment/**Connections**) (Opcional nas versões mais recentes da ação; obrigatório nas versões mais antigas) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Name (*DeployCloudFormationStack*/Environment/Connections/**Name**) (Obrigatório se [Connections](#deploy.action.cfn.environment.connections) for incluído) Especifique o nome da conexão da conta. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Role (*DeployCloudFormationStack*/Environment/Connections/**Role**) (Obrigatório se [Connections](#deploy.action.cfn.environment.connections) for incluído) Especifique o nome da função do IAM que a ação **Deploy CloudFormation stack** usa para acessar AWS e o CloudFormation serviço. Certifique-se de ter [adicionado a função ao seu CodeCatalyst espaço](ipa-connect-account-addroles.md) e de que a função inclua as seguintes políticas. Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas a seguir. + A política de permissões a seguir: **Atenção** Limite as permissões às exibidas na política a seguir. Usar um perfil com permissões mais amplas pode representar um risco de segurança. **nota** Na primeira vez em que o perfil for usado, use o caractere curinga a seguir na declaração de política de recursos e defina o escopo da política com o nome do recurso depois que ele estiver disponível. ``` "Resource": "*" ``` + A política de confiança personalizada a seguir: **nota** Você pode usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação, se desejar. Para obter mais informações sobre esse perfil, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' '/ Função Environment/account/role** ## Inputs (*DeployCloudFormationStack*/**Inputs**) (Optional) A seção `Inputs` define os dados que `DeployCloudFormationStack` precisa durante a execução de um fluxo de trabalho. **nota** São permitidas no máximo quatro entradas (uma fonte e três artefatos) por ação de **implantação da CloudFormation pilha**. Se você precisar consultar arquivos que residem em entradas diferentes (digamos, uma origem e um artefato), a entrada de origem será a entrada primária e o artefato será a entrada secundária. As referências a arquivos em entradas secundárias usam um prefixo especial para diferirem das primárias. Para obter detalhes, consulte [Exemplo: referência de arquivos em vários artefatos](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file). Interface de usuário correspondente: guia **Entradas** ## Sources (*DeployCloudFormationStack*/Inputs/**Sources**) (Obrigatório se o seu AWS SAM modelo CloudFormation ou modelo estiver armazenado em um repositório de origem) Se seu AWS SAM modelo CloudFormation ou modelo estiver armazenado em um repositório de origem, especifique o rótulo desse repositório de origem. Atualmente, o único rótulo compatível é `WorkflowSource`. Se o seu AWS SAM modelo CloudFormation ou modelo não estiver contido em um repositório de origem, ele deverá residir em um artefato gerado por outra ação ou em um bucket do Amazon S3. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*DeployCloudFormationStack*/Inputs/**Artifacts**) (Obrigatório se seu AWS SAM modelo CloudFormation ou modelo estiver armazenado em um [artefato de saída](workflows-working-artifacts-output.md) de uma ação anterior) Se o AWS SAM modelo CloudFormation ou que você deseja implantar estiver contido em um artefato gerado por uma ação anterior, especifique esse artefato aqui. Se seu CloudFormation modelo não estiver contido em um artefato, ele deverá residir no seu repositório de origem ou em um bucket do Amazon S3. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Configuração/**Artefatos - opcional** ## Configuration (*DeployCloudFormationStack*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## name (*DeployCloudFormationStack*/Configuration/**name**) (Obrigatório) Especifique um nome para a CloudFormation pilha que a ação **Deploy CloudFormation stack** cria ou atualiza. Interface de usuário correspondente: guia Configuração/**Nome da pilha** ## region (*DeployCloudFormationStack*/Configuration/**region**) (Obrigatório) Especifique o Região da AWS local no qual a pilha será implantada. Para obter uma lista dos códigos das regiões, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes). Interface de usuário correspondente: guia Configuração/**Região da pilha** ## template (*DeployCloudFormationStack*/Configuration/**template**) (Obrigatório) Especifique o nome e o caminho para seu arquivo CloudFormation ou arquivo AWS SAM de modelo. O modelo pode estar no formato JSON ou YAML e pode residir em um repositório de origem, em um artefato de uma ação anterior ou em um bucket do Amazon S3. Se o arquivo de modelo estiver em um repositório ou artefato de origem, o caminho será relativo à origem ou à raiz do artefato. Se o modelo estiver em um bucket do Amazon S3, o caminho será o valor do **URL do objeto** do modelo. Exemplos: `./MyFolder/MyTemplate.json` `MyFolder/MyTemplate.yml` `https://MyBucket.s3.us-west-2.amazonaws.com/MyTemplate.yml` **nota** Talvez seja necessário adicionar um prefixo ao caminho do arquivo do modelo para indicar em qual artefato ou origem encontrá-lo. Para obter mais informações, consulte [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md) e [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). Interface de usuário correspondente: guia Configuração/**Modelo** ## role-arn (*DeployCloudFormationStack*/Configuration/**role-arn**) (Obrigatório) Especifique o Amazon Resource Name (ARN) da função da pilha. CloudFormation usa essa função para acessar e modificar recursos em sua pilha. Por exemplo: `arn:aws:iam::123456789012:role/StackRole`. O perfil da pilha deve incluir: + Uma ou mais políticas de permissões. As políticas dependem dos recursos que você tem na pilha. Por exemplo, se sua pilha inclui uma AWS Lambda função, você precisa adicionar permissões que concedam acesso ao Lambda. Se você seguiu o tutorial descrito em [Tutorial: Implantar uma aplicação sem servidor](deploy-tut-lambda.md), ele inclui um procedimento intitulado [Para criar um perfil de pilha](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles-stack) que lista as permissões que o perfil de pilha precisa se você estiver implantando uma pilha típica de aplicações sem servidor. **Atenção** Limite as permissões às exigidas pelo CloudFormation serviço para acessar os recursos em sua pilha. Usar um perfil com permissões mais amplas pode representar um risco de segurança. + A seguinte política de confiança: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ Se desejar, associe esse perfil à conexão da sua conta. Para saber mais sobre como associar um perfil do IAM a uma conexão de conta, consulte [Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). Se você não associar o perfil da pilha à conexão da conta, ele não aparecerá na lista suspensa **Perfil da pilha** no editor visual. No entanto, o ARN do perfil ainda poderá ser especificado no campo `role-arn` usando o editor YAML. **nota** Você pode usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação, se desejar. Para obter mais informações sobre esse perfil, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Interface de usuário correspondente: guia Configuração/**Perfil da pilha - opcional** ## capabilities (*DeployCloudFormationStack*/Configuration/**capabilities**) (Obrigatório) Especifique uma lista dos recursos do IAM necessários para permitir CloudFormation a criação de determinadas pilhas. Na maioria dos casos, você pode sair de `capabilities` com o valor padrão de `CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND`. Se você vir `##[error] requires capabilities: [capability-name]` nos logs da ação **Implantar pilha do CloudFormation **, consulte [Como faço para corrigir erros de recursos do IAM?](troubleshooting-workflows.md#troubleshooting-workflows-capabilities) para ter informações sobre como corrigir o problema. Para obter mais informações sobre os recursos do IAM, consulte Como [reconhecer recursos do IAM em CloudFormation modelos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html#using-iam-capabilities) no *Guia do usuário do IAM*. Interface de usuário correspondente: guia Configuração/Avançada/**Recursos** ## parameter-overrides (*DeployCloudFormationStack*/Configuration/**parameter-overrides**) (Optional) Especifique parâmetros no seu CloudFormation ou no AWS SAM modelo que não tenham valores padrão ou para os quais você deseja especificar valores não padrão. Para obter mais informações sobre parâmetros, consulte [Parâmetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) no *Guia AWS CloudFormation do usuário*. A propriedade `parameter-overrides` aceita: + Um arquivo JSON contendo os parâmetros e valores. + Uma lista separada por vírgulas de parâmetros e valores. **Para especificar um arquivo JSON** 1. Verifique se o arquivo JSON usa uma das seguintes sintaxes: ``` { "Parameters": { "Param1": "Value1", "Param2": "Value2", ... } } ``` Ou... ``` [ { "ParameterKey": "Param1", "ParameterValue": "Value1" }, ... ] ``` (Existem outras sintaxes, mas elas não são suportadas CodeCatalyst no momento em que este artigo foi escrito.) *Para obter mais informações sobre a especificação de CloudFormation parâmetros em um arquivo JSON, consulte [Sintaxe JSON compatível](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudformation/deploy/index.html#supported-json-syntax) na Referência de Comandos.AWS CLI * 1. Especifique o caminho para o arquivo JSON usando um dos seguinte formatos: + Se o arquivo JSON residir em um artefato de saída de uma ação anterior, use: `file:///artifacts/current-action-name/output-artifact-name/path-to-json-file` Consulte o **Exemplo 1** para saber detalhes. + Se o arquivo JSON residir no seu repositório de origem, use: `file:///sources/WorkflowSource/path-to-json-file` Consulte o **Exemplo 2** para saber detalhes. **Exemplo 1**: o arquivo JSON reside em um artefato de saída ``` ##My workflow YAML ... Actions: MyBuildAction: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ParamArtifact Files: - params.json Configuration: ... MyDeployCFNStackAction: Identifier: aws/cfn-deploy@v1 Configuration: parameter-overrides: file:///artifacts/MyDeployCFNStackAction/ParamArtifact/params.json ``` **Exemplo 2**: o arquivo JSON reside no repositório de origem, em uma pasta chamada `my/folder` ``` ##My workflow YAML ... Actions: MyDeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 Inputs: Sources: - WorkflowSource Configuration: parameter-overrides: file:///sources/WorkflowSource/my/folder/params.json ``` **Como usar uma lista de parâmetros separada por vírgula** + Adicione pares de nome-valor do parâmetro na propriedade `parameter-overrides` usando o seguinte formato: `param-1=value-1,param-2=value-2` Por exemplo, assumindo o seguinte CloudFormation modelo: ``` ##My CloudFormation template Description: My CloudFormation template Parameters: InstanceType: Description: Defines the Amazon EC2 compute for the production server. Type: String Default: t2.micro AllowedValues: - t2.micro - t2.small - t3.medium Resources: ... ``` ... você pode definir a propriedade `parameter-overrides` da seguinte forma: ``` ##My workflow YAML ... Actions: ... DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 Configuration: parameter-overrides: InstanceType=t3.medium,UseVPC=true ``` **nota** Você pode especificar um nome de parâmetro sem um valor correspondente usando `undefined` como valor. Por exemplo: `parameter-overrides: MyParameter=undefined` O efeito é que, durante uma atualização da pilha, CloudFormation usa o valor do parâmetro existente para o nome do parâmetro fornecido. Interface de usuário correspondente: + Guia Configuração/Avançado/**Substituições de parâmetros** + tab/Advanced/ParameterSubstituições de configuração/ **Especifique substituições usando** um arquivo + tab/Advanced/ParameterSubstituições de configuração/ **Especifique substituições usando um conjunto de valores** ## no-execute-changeset (*DeployCloudFormationStack*/Configuration/**no-execute-changeset**) (Optional) Especifique se você CodeCatalyst deseja criar o conjunto de CloudFormation alterações e depois parar antes de executá-lo. Isso lhe dá a oportunidade de revisar o conjunto de alterações no CloudFormation console. Se você determinar que o conjunto de alterações parece bom, desative essa opção e execute novamente o fluxo de trabalho para que ele CodeCatalyst possa criar e executar o conjunto de alterações sem parar. O padrão é criar e executar o conjunto de alterações sem parar. Para obter mais informações, consulte o parâmetro CloudFormation [deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) na *Referência de AWS CLI Comandos*. Para ter mais informações sobre a visualização de conjuntos de alterações, consulte [Visualização de um conjunto de alterações](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-view.html) no *Guia do usuário do AWS CloudFormation *. Interface de usuário correspondente: guia Configuração/Avançado/**Sem executar o conjunto de alterações** ## fail-on-empty-changeset (*DeployCloudFormationStack*/Configuration/**fail-on-empty-changeset**) (Optional) Especifique se você deseja CodeCatalyst falhar na ação **Deploy CloudFormation stack** se o conjunto de CloudFormation alterações estiver vazio. (Se um conjunto de alterações estiver vazio, isso significa que não foram feitas alterações na pilha durante a implantação mais recente.) O padrão é permitir que a ação continue se o conjunto de alterações estiver vazio e retornar uma mensagem `UPDATE_COMPLETE` mesmo que a pilha não tenha sido atualizada. Para obter mais informações sobre essa configuração, consulte o parâmetro CloudFormation [deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) na *Referência de AWS CLI Comandos*. Para ter mais informações sobre conjuntos de alterações, consulte [Atualizar pilhas usando conjuntos de alterações](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) no *Manual do usuário do AWS CloudFormation *. Interface de usuário correspondente: guia Configuração/Avançado/**Falha no conjunto de alterações vazio** ## disable-rollback (*DeployCloudFormationStack*/Configuration/**disable-rollback**) (Optional) Especifique se você CodeCatalyst deseja reverter a implantação da pilha se ela falhar. A reversão retorna a pilha ao último estado estável conhecido. O padrão é habilitar reversões. Para obter mais informações sobre essa configuração, consulte o parâmetro CloudFormation [deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) na *Referência de AWS CLI Comandos*. Para obter mais informações sobre como a ação **Deploy CloudFormation stack** lida com reversões, consulte. [Configurar reversões](deploy-consumption-enable-alarms.md) Para ter mais informações sobre como reverter uma pilha, consulte [Opções de falha de pilha](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stack-failure-options.html) no *Guia do usuário do AWS CloudFormation *. Interface de usuário correspondente: guia Configuração/Avançado/**Desativar reversão** ## termination-protection (*DeployCloudFormationStack*/Configuration/**termination-protection**) (Optional) Especifique se você deseja que a ** CloudFormation pilha Deploy** adicione proteção de encerramento à pilha que está implantando. Se um usuário tentar excluir uma pilha com proteção contra encerramento ativada, a exclusão falhará e a pilha, incluindo o status dela, permanecerá inalterada. O padrão é desativar a proteção contra encerramento. Para ter mais informações, consulte [Proteção de uma pilha contra exclusão](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html) no *Guia do usuário do AWS CloudFormation *. Interface de usuário correspondente: guia Configuração/Avançado/**Proteção contra encerramento** ## timeout-in-minutes (*DeployCloudFormationStack*/Configuration/**timeout-in-minutes**) (Optional) Especifique a quantidade de tempo, em minutos, que CloudFormation deve ser alocada antes de expirar as operações de criação da pilha e definir o status da pilha como. `CREATE_FAILED` Se o CloudFormation não puder criar a pilha inteira dentro do tempo alocado, além de não ser criada, a pilha será revertida. Por padrão, não há tempo limite para criação da pilha. No entanto, recursos individuais podem ter seus próprios limites de tempo com base na natureza do serviço que implementam. Por exemplo, se um recurso individual em sua pilha expirar, a criação dela também expirará, ainda que o tempo limite especificado para a criação não tenha sido atingido. **UI correspondente: guia de configuração/avançado/tempo limite CloudFormation** ## notification-arns (*DeployCloudFormationStack*/Configuration/**notification-arns**) (Optional) Especifique o ARN de um tópico do Amazon SNS para o qual você CodeCatalyst deseja enviar mensagens de notificação. Por exemplo, .`arn:aws:sns:us-east-1:111222333:MyTopic` Quando a ação **Deploy CloudFormation stack** é executada, CodeCatalyst CloudFormation coordena-se para enviar uma notificação por CloudFormation evento que ocorre durante o processo de criação ou atualização da pilha. (Os eventos são visíveis na guia **Eventos** do CloudFormation console para a pilha.) Você pode definir até cinco tópicos. Para ter mais informações, consulte [O que é a Amazon SNS?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) **UI correspondente: guia Configuração/Avançado/Notificação ARNs** ## monitor-alarm-arns (*DeployCloudFormationStack*/Configuration/**monitor-alarm-arns**) (Optional) Especifique o Amazon Resource Name (ARN) de um CloudWatch alarme da Amazon para usar como gatilho de reversão. Por exemplo, .`arn:aws:cloudwatch::123456789012:alarm/MyAlarm` Você pode ter no máximo cinco gatilhos de reversão. **nota** Se você especificar um ARN de CloudWatch alarme, também precisará configurar permissões adicionais para permitir o acesso à ação. CloudWatch Para obter mais informações, consulte [Configurar reversões](deploy-consumption-enable-alarms.md). **UI correspondente: guia de configuração/avançado/alarme de monitor ARNs** ## monitor-timeout-in-minutes (*DeployCloudFormationStack*/Configuration/**monitor-timeout-in-minutes**) (Optional) Especifique um período de tempo, de 0 a 180 minutos, durante o qual CloudFormation monitora os alarmes especificados. O monitoramento começa *após* a implantação de todos os recursos da pilha. Se o alarme ocorrer dentro do tempo de monitoramento especificado, a implantação falhará e CloudFormation reverterá toda a operação da pilha. Padrão: 0. CloudFormation monitora apenas os alarmes enquanto os recursos da pilha estão sendo implantados, não depois. Interface de usuário correspondente: guia Configuração/Avançado/**Tempo de monitoramento** ## tags (*DeployCloudFormationStack*/Configuration/**tags**) (Optional) Especifique as tags para anexar à sua CloudFormation pilha. As tags são pares de chave/valor arbitrários que você pode usar para identificar sua pilha em relação à finalidade, como alocação de custos. Para obter mais informações sobre o que as tags são e como elas podem ser usadas, consulte [Marcar recursos](https://docs.aws.amazon.com/) no *Guia do usuário do Amazon EC2*. Para obter mais informações sobre como marcar CloudFormation, consulte [Configuração das opções de CloudFormation pilha](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html) no Guia do *AWS CloudFormation usuário*. Uma chave pode ter caracteres alfanuméricos ou espaços e pode ter até 127 caracteres. Um valor pode ter caracteres alfanuméricos ou espaços e pode ter até 255 caracteres. É possível adicionar até 50 tags exclusivas para cada pilha. Interface de usuário correspondente: guia Configuração/Avançado/**Tags** # Implantando um AWS CDK aplicativo com um fluxo de trabalho Esta seção descreve como implantar um AWS Cloud Development Kit (AWS CDK) aplicativo em sua AWS conta usando um fluxo de trabalho. Para fazer isso, você deve adicionar a ação **Implantação do AWS CDK ** ao seu fluxo de trabalho. A ação de **AWS CDK implantação** sintetiza e implanta seu AWS Cloud Development Kit (AWS CDK) aplicativo em. AWS Se seu aplicativo já existir em AWS, a ação o atualizará, se necessário. Para obter informações gerais sobre como criar aplicativos usando o AWS CDK, consulte [O que é o AWS CDK?](https://docs.aws.amazon.com/cdk/v2/guide/home.html) no *Guia do AWS Cloud Development Kit (AWS CDK) desenvolvedor*. **Topics** + [ ## Quando usar a ação 'AWS CDK implantar' ](#cdk-dep-action-when-to-use) + [ ## Como a ação 'AWS CDK implantar' funciona ](#cdk-dep-action-how-it-works) + [ ## Versões da CLI do CDK usadas pela ação 'implantar'AWS CDK ](#cdk-dep-action-cdk-version) + [ ## Imagem de tempo de execução usada pela ação 'AWS CDK implantar' ](#cdk-dep-action-runtime) + [ ## Quantas pilhas a ação pode implantar? ](#cdk-dep-action-how-many-stacks) + [ # Exemplo: implantação de um aplicativo AWS CDK ](cdk-dep-action-example-workflow.md) + [ # Adicionando a ação 'AWS CDK implantar' ](cdk-dep-action-add.md) + [ # Variáveis de “Implantação do AWS CDK ” ](cdk-dep-action-variables.md) + [ # YAML da ação “Implantação do AWS CDK ” ](cdk-dep-action-ref.md) ## Quando usar a ação 'AWS CDK implantar' Use essa ação se você desenvolveu um aplicativo usando o AWS CDK e agora deseja implantá-lo automaticamente como parte do fluxo de trabalho de integração e entrega contínuas automatizadas (CI/CD). Por exemplo, talvez você queira implantar seu AWS CDK aplicativo automaticamente sempre que alguém mesclar uma pull request relacionada à fonte do seu AWS CDK aplicativo. ## Como a ação 'AWS CDK implantar' funciona A **Implantação do AWS CDK ** funciona da seguinte maneira: 1. [Em tempo de execução, se você especificou a versão 1.0.12 ou anterior da ação, a ação baixará a CLI CDK mais recente (também chamada de Tookit) para a imagem AWS CDK do ambiente de tempo de execução. CodeCatalyst ](#cdk-dep-action-runtime) Se você especificou a versão 1.0.13 ou posterior, a ação vem junto com uma [versão específica](#cdk-dep-action-cdk-version) da CLI do CDK e, portanto, nenhum download ocorre. 1. A ação usa a CLI do CDK para executar o comando `cdk deploy`. Esse comando sintetiza e implanta seu AWS CDK aplicativo em. AWS Para ter mais informações sobre esse comando, consulte o tópico [Kit de ferramentas do AWS CDK (comando cdk)](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html) no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. ## Versões da CLI do CDK usadas pela ação 'implantar'AWS CDK A tabela a seguir mostra qual versão da CLI do CDK é usada por padrão por diferentes versões da ação **Implantação do AWS CDK **. **nota** Talvez você consiga substituir o padrão. Para ter mais informações, consulte [CdkCliVersion](cdk-dep-action-ref.md#cdk.dep.cdk.cli.version) no [YAML da ação “Implantação do AWS CDK ”](cdk-dep-action-ref.md). | Versão da ação “Implantação do AWS CDK ” | AWS CDK Versão CLI | | --- | --- | | 1.0.0 – 1.0.12 | mais recente | | 1.0.13 ou posterior | 2.99.1 | ## Imagem de tempo de execução usada pela ação 'AWS CDK implantar' A tabela a seguir mostra as imagens do ambiente de execução CodeCatalyst usadas para executar diferentes versões da ação de **AWS CDK implantação**. As imagens incluem diferentes conjuntos de ferramentas pré-instaladas. Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). **nota** Recomendamos atualizar sua ação **Implantação do AWS CDK ** para a versão 2.x para aproveitar as ferramentas mais recentes disponíveis na imagem de março de 2024. Para atualizar a ação, defina a propriedade `Identifier` como `aws/cdk-deploy@v2` no arquivo de definição de fluxo de trabalho. Para obter mais informações, consulte [YAML da ação “Implantação do AWS CDK ”](cdk-dep-action-ref.md). | Versão da ação “Implantação do AWS CDK ” | Imagens de ambiente de runtime | | --- | --- | | 1.x | Imagens de novembro de 2022 | | 2.x | Imagens de março de 2024 | ## Quantas pilhas a ação pode implantar? A **Implantação do AWS CDK ** pode implantar somente uma única pilha. Se seu AWS CDK aplicativo consistir em várias pilhas, você deverá criar uma pilha principal com pilhas aninhadas e implantar a principal usando essa ação. # Exemplo: implantação de um aplicativo AWS CDK O exemplo de fluxo de trabalho a seguir inclui a ação **Implantação do AWS CDK **, junto com a ação **Inicialização do AWS CDK **. O fluxo de trabalho consiste nos seguintes blocos de compilação que são executados sequencialmente: + Um **gatilho**: esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Esse repositório contém seu AWS CDK aplicativo. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + Uma ação de **AWS CDK bootstrap** (`CDKBootstrap`) — No gatilho, a ação implanta a pilha de `CDKToolkit` bootstrap em. AWS Se a pilha do `CDKToolkit` já existir no ambiente, ela será atualizada se necessário; caso contrário, nada acontecerá e a ação será marcada como bem-sucedida. + Uma ação de **AWS CDK implantação** (`AWS CDK Deploy`) — Ao concluir a ação de **AWS CDK bootstrap**, a ação de **AWS CDK implantação** sintetiza o código do seu AWS CDK aplicativo em um CloudFormation modelo e implanta a pilha definida no modelo em. AWS **nota** O exemplo de fluxo de trabalho a seguir serve para fins ilustrativos e não funcionará sem configuração adicional. **nota** No código YAML a seguir, você pode omitir as seções `Connections:` se quiser. Se você omitir essas seções, deverá garantir que o perfil especificado no campo **Perfil do IAM padrão** em seu ambiente inclua as permissões e as políticas de confiança exigidas pelas ações **Inicialização do AWS CDK ** e **Implantação do AWS CDK **. Para ter mais informações sobre como configurar um ambiente com um perfil do IAM padrão, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Para ter mais informações sobre as permissões e as políticas de confiança exigidas pelas ações **Inicialização do AWS CDK ** e **Implantação do AWS CDK **, consulte a descrição da propriedade `Role` na [YAML da ação “Inicialização do AWS CDK ”](cdk-boot-action-ref.md) e [YAML da ação “Implantação do AWS CDK ”](cdk-dep-action-ref.md). ``` Name: codecatalyst-cdk-deploy-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: CDKBootstrap: Identifier: aws/cdk-bootstrap@v2 Inputs: Sources: - WorkflowSource Environment: Name: codecatalyst-cdk-deploy-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-cdk-bootstrap-role Configuration: Region: us-west-2 CDKDeploy: Identifier: aws/cdk-deploy@v2 DependsOn: - CDKBootstrap Environment: Name: codecatalyst-cdk-deploy-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-cdk-deploy-role Inputs: Sources: - WorkflowSource Configuration: StackName: my-app-stack Region: us-west-2 ``` # Adicionando a ação 'AWS CDK implantar' Use as instruções a seguir para adicionar a ação **Implantação do AWS CDK ** ao seu fluxo de trabalho. **Antes de começar** Antes de adicionar a ação **Implantação do AWS CDK ** ao seu fluxo de trabalho, conclua as seguintes tarefas: 1. **Tenha um AWS CDK aplicativo pronto**. Você pode escrever seu AWS CDK aplicativo usando AWS CDK v1 ou v2, em qualquer linguagem de programação compatível com o. AWS CDK Verifique se os arquivos da aplicação AWS CDK estão disponíveis em: + Um [repositório de CodeCatalyst origem](source.md) ou + Um [artefato CodeCatalyst de saída](workflows-working-artifacts.md) gerado por outra ação do fluxo de trabalho 1. **Inicialize seu AWS ambiente.** Para inicializar, você pode: + Usar um dos métodos descritos em [Como inicializar](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-howto) no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. + Usar a ação **Inicialização do AWS CDK **. Você pode adicionar essa ação no mesmo fluxo de trabalho da **Implantação do AWS CDK ** ou em um diferente. Apenas garanta que a ação de inicialização seja executada pelo menos uma vez antes de executar a ação **Implantação do AWS CDK ** para que os recursos necessários estejam disponíveis. Para obter mais informações sobre a ação de **AWS CDK bootstrap**, consulte[Inicializando um AWS CDK aplicativo com um fluxo de trabalho](cdk-boot-action.md). Para ter mais informações sobre inicialização, consulte [Inicialização](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. ------ #### [ Visual ] **Para adicionar a ação 'AWS CDK implantar' usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Implantação do AWS CDK ** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Escolha **Implantação do AWS CDK **. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Download** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [YAML da ação “Implantação do AWS CDK ”](cdk-dep-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. **nota** Se a ação **Implantação do AWS CDK ** falhar com um erro `npm install`, consulte [Como faço para corrigir erros de “instalação npm”?](troubleshooting-workflows.md#troubleshooting-workflows-npm) para ter informações sobre como corrigir o erro. ------ #### [ YAML ] **Para adicionar a ação 'AWS CDK implantar' usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Implantação do AWS CDK ** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Escolha **Implantação do AWS CDK **. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Download** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [YAML da ação “Implantação do AWS CDK ”](cdk-dep-action-ref.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. **nota** Se a ação **Implantação do AWS CDK ** falhar com um erro `npm install`, consulte [Como faço para corrigir erros de “instalação npm”?](troubleshooting-workflows.md#troubleshooting-workflows-npm) para ter informações sobre como corrigir o erro. ------ # Variáveis de “Implantação do AWS CDK ” A ação **Implantação do AWS CDK ** produz e define as seguintes variáveis em runtime. Elas são conhecidas como *variáveis predefinidas*. Para ter informações sobre como referenciar essas variáveis em um fluxo de trabalho, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). | Chave | Valor | | --- | --- | | stack-id | O Amazon Resource Name (ARN) da pilha de AWS CDK aplicativos que foi implantada durante a execução do fluxo de trabalho. Exemplo: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-app-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` | | deployment-platform | O nome da plataforma de implantação. Codificado para `AWS:CloudFormation`. | | region | O código da região em Região da AWS que foi implantado durante a execução do fluxo de trabalho. Exemplo: `us-west-2` | | SKIP-DEPLOYMENT | Um valor de `true` indica que a implantação da pilha de AWS CDK aplicativos foi ignorada durante a execução do fluxo de trabalho. Uma implantação da pilha será ignorada se não houver nenhuma alteração na pilha desde a última implantação. Essa variável só será produzida se o valor for `true`. Codificado para `true`. | | *CloudFormation variables* | Além de gerar as variáveis listadas anteriormente, a ação de **AWS CDK implantação** também expõe as variáveis de *CloudFormation*saída como variáveis de *fluxo* de trabalho para uso em ações subsequentes do fluxo de trabalho. Por padrão, a ação expõe somente as primeiras quatro (ou menos) CloudFormation variáveis encontradas. Para determinar quais estão expostas, execute a ação **Implantação do AWS CDK ** uma vez e, depois, consulte a guia **Variáveis** da página de detalhes da execução. Se as variáveis listadas na guia **Variáveis** não forem as desejadas, você poderá configurar outras usando a propriedade YAML `CfnOutputVariables`. Para ter mais informações, consulte a descrição da propriedade [CfnOutputVariables](cdk-dep-action-ref.md#cdk.dep.cfn.out) na [YAML da ação “Implantação do AWS CDK ”](cdk-dep-action-ref.md). | # YAML da ação “Implantação do AWS CDK ” Confira a seguir a definição de YAML da ação **Implantação do AWS CDK **. Para saber como usar essa ação, consulte [Implantando um AWS CDK aplicativo com um fluxo de trabalho](cdk-dep-action.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. CDKDeploy\$1nn: Identifier: aws/cdk-deploy@v2 DependsOn: - CDKBootstrap Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - artifact-name Outputs: Artifacts: - Name: cdk_artifact Files: - "cdk.out/**/*" Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Configuration: StackName: my-cdk-stack Region: us-west-2 Tags: '{"key1": "value1", "key2": "value2"}' Context: '{"key1": "value1", "key2": "value2"}' CdkCliVersion: version CdkRootPath: directory-containing-cdk.json-file CfnOutputVariables: '["CnfOutputKey1","CfnOutputKey2","CfnOutputKey3"]' CloudAssemblyRootPath: path-to-cdk.out ``` ## CDKDeploy (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Padrão: `CDKDeploy_nn`. Interface de usuário correspondente: guia Configuração/**Nome da ação** ## Identifier (*CDKDeploy*/**Identifier**) (Obrigatório) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). **nota** A especificação de `aws/cdk-deploy@v2` faz com que a ação seja executada na [imagem de março de 2024](build-images.md#build.default-image), que inclui ferramentas mais recentes, como Node.js 18. A especificação de `aws/cdk-deploy@v1` faz com que a ação seja executada na [imagem de novembro de 2022](build-images.md#build.previous-image), que inclui ferramentas mais antigas, como Node.js 16. Padrão: `aws/cdk-deploy@v2`. Interface de usuário correspondente: Diagrama de fluxo de trabalho/CDKDeploy\$1nn/rótulo **aws/cdk-deploy@v2** ## DependsOn (*CDKDeploy*/**DependsOn**) (Optional) Especifique uma ação ou um grupo de ação que deve ser executado para que a ação **Implantação do AWS CDK ** seja executada. Recomendamos especificar a ação **Inicialização do AWS CDK ** na propriedade `DependsOn`, da seguinte forma: ``` CDKDeploy: Identifier: aws/cdk-deploy@v2 DependsOn: - CDKBootstrap ``` **nota** A [inicialização é um pré-requisito obrigatório para a implantação de um aplicativo](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html). AWS CDK Se você não incluir a ação **Inicialização do AWS CDK ** no fluxo de trabalho, deverá encontrar outra maneira de implantar a pilha de inicialização do AWS CDK antes de executar a ação **Implantação do AWS CDK **. Para obter mais informações, consulte [Adicionando a ação 'AWS CDK implantar'](cdk-dep-action-add.md) em [Implantando um AWS CDK aplicativo com um fluxo de trabalho](cdk-dep-action.md). Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*CDKDeploy*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*CDKDeploy*/Compute/**Type**) (Obrigatório se [Compute](#cdk.dep.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2**(editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). **UI correspondente: Configuração tab/Advanced - opcional/Tipo de computação** ## Fleet (*CDKDeploy*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. **UI correspondente: configuração tab/Advanced - opcional/frota de computação** ## Timeout (*CDKDeploy*/**Timeout**) (Obrigatório) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Inputs (*CDKDeploy*/**Inputs**) (Optional) A seção `Inputs` define os dados que `CDKDeploy` precisa durante a execução de um fluxo de trabalho. **nota** Somente uma entrada (uma fonte ou um artefato) é permitida para cada ação **Implantação do AWS CDK **. Interface de usuário correspondente: guia **Entradas** ## Sources (*CDKDeploy*/Inputs/**Sources**) (Obrigatório se o AWS CDK aplicativo que você deseja implantar estiver armazenado em um repositório de origem) Se seu AWS CDK aplicativo estiver armazenado em um repositório de origem, especifique o rótulo desse repositório de origem. A ação **Implantação do AWS CDK ** sintetiza a aplicação nesse repositório antes de iniciar o processo de implantação. Atualmente, o único rótulo compatível é `WorkflowSource`. Se seu AWS CDK aplicativo não estiver contido em um repositório de origem, ele deverá residir em um artefato gerado por outra ação. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*CDKDeploy*/Inputs/**Artifacts**) (Obrigatório se o AWS CDK aplicativo que você deseja implantar estiver armazenado em um [artefato de saída](workflows-working-artifacts-output.md) de uma ação anterior) Se seu AWS CDK aplicativo estiver contido em um artefato gerado por uma ação anterior, especifique esse artefato aqui. A ação de **AWS CDK implantação** sintetiza o aplicativo no artefato especificado em um CloudFormation modelo antes de iniciar o processo de implantação. Se seu AWS CDK aplicativo não estiver contido em um artefato, ele deverá residir no seu repositório de origem. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Entradas/**Artefatos - opcional** ## Outputs (*CDKDeploy*/**Outputs**) (Optional) Define os dados que são gerados pela ação durante a execução de um fluxo de trabalho. Interface de usuário correspondente: guia **Saídas** ## Artifacts - output (*CDKDeploy*/Outputs/**Artifacts** (Optional) Especifique os artefatos gerados pela ação. Você pode referenciar esses artefatos como entrada em outras ações. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Saídas/**Artefatos** ## Name (*CDKDeploy*/Outputs/Artifacts/**Name**) (Obrigatório se [Artifacts - output](#cdk.dep.outputs.artifacts) for incluído) Especifique o nome do artefato que conterá o CloudFormation modelo sintetizado pela ação de **AWS CDK implantação** em tempo de execução. O valor padrão é `cdk_artifact`. Se você não especificar um artefato, a ação sintetizará o modelo, mas não o salvará em um artefato. Pense em salvar o modelo sintetizado em um artefato para preservar um registro dele para fins de teste ou solução de problemas. **UI correspondente: artefato de tab/Artifacts/Add saída/Nome do artefato de construção** ## Files (*CDKDeploy*/Outputs/Artifacts/**Files**) (Obrigatório se [Artifacts - output](#cdk.dep.outputs.artifacts) for incluído) Especifique os arquivos a serem incluídos no artefato. Você deve especificar `"cdk.out/**/*"` para incluir o modelo sintetizado CloudFormation do seu AWS CDK aplicativo. **nota** `cdk.out` é o diretório padrão no qual os arquivos sintetizados são salvos. Se você especificou um diretório de saída diferente de `cdk.out` no arquivo `cdk.json`, especifique esse diretório aqui em vez de `cdk.out`. **UI correspondente: produz tab/Artifacts/Add artefatos/arquivos produzidos pela compilação** ## Environment (*CDKDeploy*/**Environment**) (Obrigatório) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*CDKDeploy*/Environment/**Name**) (Obrigatório se [Environment](#cdk.dep.environment) for incluído) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*CDKDeploy*/Environment/**Connections**) (Opcional nas versões mais recentes da ação; obrigatório nas versões mais antigas) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Name (*CDKDeploy*/Environment/Connections/**Name**) (Obrigatório se [Connections](#cdk.dep.environment.connections) for incluído) Especifique o nome da conexão da conta. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Role (*CDKDeploy*/Environment/Connections/**Role**) (Obrigatório se [Connections](#cdk.dep.environment.connections) for incluído) Especifique o nome da conexão da conta. Especifique o nome da função do IAM que a ação de **AWS CDK implantação** usa para acessar AWS e implantar a pilha de AWS CDK aplicativos. Certifique-se de ter [adicionado a função ao seu CodeCatalyst espaço](ipa-connect-account-addroles.md) e de que a função inclua as seguintes políticas. Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas a seguir. + A política de permissões a seguir: **Atenção** Limite as permissões às exibidas na política a seguir. Usar um perfil com permissões mais amplas pode representar um risco de segurança. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "cloudformation:DescribeStackEvents", "cloudformation:DescribeChangeSet", "cloudformation:DescribeStacks", "cloudformation:ListStackResources" ], "Resource": "*" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/cdk-*" } ] } ``` ------ + A política de confiança personalizada a seguir: **nota** Você pode usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação, se desejar. Para obter mais informações sobre essa função, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' '/ Função Environment/account/role** ## Configuration (*CDKDeploy*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## StackName (*CDKDeploy*/Configuration/**StackName**) (Obrigatório) O nome da sua pilha de AWS CDK aplicativos, conforme aparece no arquivo do ponto de entrada no diretório do seu AWS CDK aplicativo. `bin` O exemplo a seguir mostra o conteúdo de um arquivo de TypeScript ponto de entrada, com o nome da pilha destacado em. *red italics* Se o arquivo do ponto de entrada estiver em outra linguagem, ele terá uma aparência semelhante. ``` import * as cdk from 'aws-cdk-lib'; import { CdkWorksopTypescriptStack } from '../lib/cdk_workshop_typescript-stack'; const app = new cdk.App(); new CdkWorkshopTypescriptStack(app, 'CdkWorkshopTypescriptStack'); ``` Você pode especificar apenas uma pilha. **dica** Se você tiver várias pilhas, poderá criar uma pilha principal com pilhas aninhadas. Em seguida, você pode especificar a pilha principal nessa ação para implantar todas as pilhas. Interface de usuário correspondente: guia Configuração/**Nome da pilha** ## Region (*CDKDeploy*/Configuration/**Region**) (Optional) Especifique Região da AWS no qual a pilha de AWS CDK aplicativos será implantada. Para obter uma lista dos códigos das regiões, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes). Se você não especificar uma região, a ação de implantação será **AWS CDK implantada** na região especificada em seu AWS CDK código. Para ter mais informações, consulte [Ambientes](https://docs.aws.amazon.com/cdk/v2/guide/environments.html) no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. Interface de usuário correspondente: guia Configuração/**Região** ## Tags (*CDKDeploy*/Configuration/**Tags**) (Optional) Especifique as tags que você deseja aplicar aos AWS recursos na pilha de AWS CDK aplicativos. As tags são aplicadas à pilha em si, bem como aos recursos individuais na pilha. Para ter mais informações sobre marcação, consulte [Marcação](https://docs.aws.amazon.com/cdk/v2/guide/tagging.html), no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. **UI correspondente: Configuração tab/Advanced - opcional/Tags** ## Context (*CDKDeploy*/Configuration/**Context**) (Optional) Especifique contextos, na forma de pares de valores-chave, para associar à pilha de aplicativos. AWS CDK Para ter mais informações sobre contextos, consulte [Contextos de runtime](https://docs.aws.amazon.com/cdk/v2/guide/context.html) no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. **UI correspondente: Configuração tab/Advanced - opcional/Contexto** ## CdkCliVersion (*CDKDeploy*/Configuration/**CdkCliVersion**) (Optional) Essa propriedade está disponível com a versão 1.0.13 ou posterior da ação **Implantação do AWS CDK ** e a versão 1.0.8 ou posterior da ação **Inicialização do AWS CDK **. Especifique um dos seguintes: + A versão completa da interface de linha de AWS Cloud Development Kit (AWS CDK) comando (CLI) (também chamada de AWS CDK kit de ferramentas) que você deseja que essa ação use. Exemplo: `2.102.1`. Considere especificar uma versão completa para garantir consistência e estabilidade ao criar e implantar a aplicação. Ou + `latest`. Pense em especificar `latest` para aproveitar os recursos e correções mais recentes da CLI do CDK. A ação baixará a versão especificada (ou a versão mais recente) da AWS CDK CLI para a [imagem de CodeCatalyst compilação](build-images.md) e, em seguida, usará essa versão para executar os comandos necessários para implantar seu aplicativo CDK ou inicializar seu ambiente. AWS Para ter uma lista das versões compatíveis da CLI do CDK que você pode usar, consulte [Versões do AWS CDK](https://docs.aws.amazon.com/cdk/api/versions.html). Se você omitir essa propriedade, a ação usará uma versão padrão da AWS CDK CLI descrita em um dos tópicos a seguir: + [Versões da CLI do CDK usadas pela ação 'implantar'AWS CDK](cdk-dep-action.md#cdk-dep-action-cdk-version) + [Versões do CDK CLI usadas pela ação AWS CDK "bootstrap”](cdk-boot-action.md#cdk-boot-action-cdk-version) UI correspondente: guia de configuração/versão **AWS CDK CLI** ## CdkRootPath (*CDKDeploy*/Configuration/**CdkRootPath**) (Optional) O caminho para o diretório que contém o `cdk.json` arquivo do seu AWS CDK projeto. A ação **Implantação do AWS CDK ** é executada nessa pasta e todas as saídas criadas pela ação serão adicionadas a esse diretório. Se não for especificada, a ação de **AWS CDK implantação** pressupõe que o `cdk.json` arquivo esteja na raiz do seu AWS CDK projeto. Interface de usuário correspondente: guia Configuração/**Diretório em que o cdk.json reside** ## CfnOutputVariables (*CDKDeploy*/Configuration/**CfnOutputVariables**) (Optional) Especifique quais `CfnOutput` construções no código do AWS CDK aplicativo você deseja expor como variáveis de saída do fluxo de trabalho. Depois, você pode referenciar as variáveis de saída do fluxo de trabalho em ações subsequentes no fluxo de trabalho. Para obter mais informações sobre variáveis em CodeCatalyst, consulte[Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Por exemplo, se o código do seu AWS CDK aplicativo tiver a seguinte aparência: ``` import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib'; import * as dynamodb from 'aws-cdk-lib/aws-dynamodb'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Construct } from 'constructs'; import * as cdk from 'aws-cdk-lib'; export class HelloCdkStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', { removalPolicy: RemovalPolicy.DESTROY, }); new CfnOutput(this, 'bucketName', { value: bucket.bucketName, description: 'The name of the s3 bucket', exportName: 'amzn-s3-demo-bucket', }); const table = new dynamodb.Table(this, 'todos-table', { partitionKey: {name: 'todoId', type: dynamodb.AttributeType.NUMBER}, billingMode: dynamodb.BillingMode.PAY_PER_REQUEST, removalPolicy: RemovalPolicy.DESTROY, }) new CfnOutput(this, 'tableName', { value: table.tableName, description: 'The name of the dynamodb table', exportName: 'myDynamoDbTable', }); ... } } ``` ... e a propriedade `CfnOutputVariables` for semelhante a: ``` Configuration: ... CfnOutputVariables: '["bucketName","tableName"]' ``` ... a ação gera as seguintes variáveis de saída do fluxo de trabalho: | Chave | Valor | | --- | --- | | bucketName | `bucket.bucketName` | | tableName | `table.tableName` | Depois, você pode referenciar as variáveis `bucketName` e `tableName` em ações subsequentes. Para saber como referenciar variáveis de saída do fluxo de trabalho em ações subsequentes, consulte [Referência a uma variável predefinida](workflows-working-with-variables-reference-output-vars.md). Se você não especificar nenhuma `CfnOutput` construção na `CfnOutputVariables` propriedade, a ação expõe as primeiras quatro (ou menos) variáveis de saída encontradas como variáveis CloudFormation de saída do fluxo de trabalho. Para obter mais informações, consulte [Variáveis de “Implantação do AWS CDK ”](cdk-dep-action-variables.md). **dica** Para obter uma lista de todas as variáveis de CloudFormation saída que a ação produz, execute o fluxo de trabalho que contém a ação de **AWS CDK implantação** uma vez e, em seguida, consulte a guia **Registros** da ação. Os registros contêm uma lista de todas as variáveis CloudFormation de saída associadas ao seu AWS CDK aplicativo. Depois de saber quais são todas as CloudFormation variáveis, você pode especificar quais deseja converter em variáveis de saída do fluxo de trabalho usando a `CfnOutputVariables` propriedade. Para obter mais informações sobre variáveis de CloudFormation saída, consulte a documentação da `CfnOutput` construção, disponível em [class CfnOutput (construct)](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutput.html) na *Referência da AWS Cloud Development Kit (AWS CDK) API*. UI correspondente: guia de configuração/variáveis **CloudFormation de saída** ## CloudAssemblyRootPath (*CDKDeploy*/Configuration/**CloudAssemblyRootPath**) (Optional) Se você já sintetizou a pilha do seu AWS CDK aplicativo em uma montagem em nuvem (usando a `cdk synth` operação), especifique o caminho raiz do diretório de montagem em nuvem (). `cdk.out` O CloudFormation modelo localizado no diretório de montagem de nuvem especificado será implantado pela ação de **AWS CDK implantação** em você Conta da AWS usando o `cdk deploy --app` comando. Quando a opção `--app` está presente, a operação `cdk synth` não ocorre. Se você não especificar um diretório de assembly de nuvem, a ação **Implantação do AWS CDK ** executará o comando `cdk deploy` sem a opção `--app`. Sem a `--app` opção, a `cdk deploy` operação sintetizará (`cdk synth`) e implantará seu AWS CDK aplicativo no seu. Conta da AWS **Por que eu especificaria um conjunto de nuvem existente e sintetizado quando a ação “AWS CDK implantar” pode fazer a síntese em tempo de execução?** Talvez você queira especificar um assembly de nuvem sintetizado existente para: + **Garanta que exatamente o mesmo conjunto de recursos seja implantado sempre que a ação “AWS CDK implantar” for executada** Se você não especificar um assembly de nuvem, é possível que a ação **Implantação do AWS CDK ** sintetize e implante arquivos diferentes, dependendo de quando ela for executada. Por exemplo, a ação **Implantação do AWS CDK ** pode sintetizar um assembly de nuvem com um conjunto de dependências durante um estágio de teste e outro conjunto de dependências durante um estágio de produção (se essas dependências mudarem entre os estágios). Para garantir a paridade exata entre o que foi testado e o que foi implantado, recomendamos sintetizar uma vez e depois usar o campo **Caminho para o diretório de assembly de nuvem** (editor visual) ou a propriedade `CloudAssemblyRootPath` (editor YAML) para especificar o assembly de nuvem já sintetizado. + **Usar gerenciadores de pacotes e ferramentas não padrão com a aplicação AWS CDK ** Durante uma operação `synth`, a ação **Implantação do AWS CDK ** tenta executar a aplicação usando ferramentas padrão, como npm ou pip. Se a ação não conseguir executar a aplicação usando essas ferramentas, a síntese não ocorrerá e a ação falhará. Para contornar esse problema, você pode especificar os comandos exatos necessários para executar seu aplicativo com êxito no `cdk.json` arquivo do AWS CDK aplicativo e, em seguida, sintetizar seu aplicativo usando um método que não envolva a **AWS CDK ação de implantação**. Depois que o assembly de nuvem for gerado, você poderá especificá-lo no campo **Caminho para o diretório de assembly de nuvem** (editor visual) ou na propriedade `CloudAssemblyRootPath` (editor YAML) da ação **Implantação do AWS CDK **. Para obter informações sobre como configurar o `cdk.json` arquivo para incluir comandos para instalar e executar seu AWS CDK aplicativo, consulte [Especificação do comando do aplicativo](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-app-command). Para ter informações sobre os comandos `cdk deploy` e `cdk synth`, bem como sobre a opção `--app`, consulte [Implantação de pilhas](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy), [Sintetização de pilhas](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-synth) e [Como ignorar a síntese](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-nosynth) no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. Para ter informações sobre assemblies de nuvem, consulte [Assembly de nuvem](https://docs.aws.amazon.com/cdk/api/v2/docs/cloud-assembly-schema-readme.html) na *AWS Cloud Development Kit (AWS CDK) API Reference*. Interface de usuário correspondente: guia Configuração/**Caminho para o diretório de assembly de nuvem** # Inicializando um AWS CDK aplicativo com um fluxo de trabalho Esta seção descreve como inicializar um AWS CDK aplicativo usando um CodeCatalyst fluxo de trabalho. Para fazer isso, você deve adicionar a ação **Inicialização do AWS CDK ** ao seu fluxo de trabalho. A ação **Inicialização do AWS CDK ** provisiona uma pilha de inicialização no ambiente da AWS usando o [modelo moderno](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-template). Se já existir uma pilha de inicialização, a ação a atualizará, se necessário. Ter uma pilha de bootstrap presente AWS é um pré-requisito para implantar um aplicativo. AWS CDK Para ter mais informações sobre inicialização, consulte [Inicialização](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. **Topics** + [ ## Quando usar a ação 'AWS CDK bootstrap' ](#cdk-boot-action-when-to-use) + [ ## Como funciona a ação 'AWS CDK bootstrap' ](#cdk-boot-action-how-it-works) + [ ## Versões do CDK CLI usadas pela ação AWS CDK "bootstrap” ](#cdk-boot-action-cdk-version) + [ ## Imagem de tempo de execução usada pela ação 'AWS CDK bootstrap' ](#cdk-boot-action-runtime) + [ # Exemplo: inicialização de um aplicativo AWS CDK ](cdk-boot-action-example-workflow.md) + [ # Adicionando a ação 'AWS CDK bootstrap' ](cdk-boot-action-add.md) + [ # variáveis de “Inicialização do AWS CDK ” ](cdk-boot-action-variables.md) + [ # YAML da ação “Inicialização do AWS CDK ” ](cdk-boot-action-ref.md) ## Quando usar a ação 'AWS CDK bootstrap' Use essa ação se você tiver um fluxo de trabalho que implanta um AWS CDK aplicativo e quiser implantar (e atualizar, se necessário) a pilha de bootstrap ao mesmo tempo. Nesse caso, você adicionaria a ação de **AWS CDK bootstrap** ao mesmo fluxo de trabalho que implanta seu AWS CDK aplicativo. **Não** use essa ação se uma das seguintes opções se aplicar: + Você já implantou uma pilha de inicialização usando outro mecanismo e deseja mantê-la intacta (sem atualizações). + Você quer usar um [modelo de inicialização personalizado](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-customizing), que não é compatível com a ação **Inicialização do AWS CDK **. ## Como funciona a ação 'AWS CDK bootstrap' A **Inicialização do AWS CDK ** funciona da seguinte maneira: 1. [Em tempo de execução, se você especificou a versão 1.0.7 ou anterior da ação, a ação baixará a CLI CDK mais recente (também chamada de AWS CDK Tookit) para a imagem de compilação. CodeCatalyst ](build-images.md) Se você especificou a versão 1.0.8 ou posterior, a ação vem junto com uma [versão específica](cdk-dep-action.md#cdk-dep-action-cdk-version) da CLI do CDK e, portanto, nenhum download ocorre. 1. A ação usa a CLI do CDK para executar o comando `cdk bootstrap`. Esse comando executa as tarefas de inicialização descritas no tópico [Inicialização](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) no *Guia do desenvolvedor do AWS Cloud Development Kit (AWS CDK) *. ## Versões do CDK CLI usadas pela ação AWS CDK "bootstrap” A tabela a seguir mostra qual versão da CLI do CDK é usada por padrão por diferentes versões da ação **Inicialização do AWS CDK **. **nota** Talvez você consiga substituir o padrão. Para ter mais informações, consulte [CdkCliVersion](cdk-boot-action-ref.md#cdk.boot.cdk.cli.version) no [YAML da ação “Inicialização do AWS CDK ”](cdk-boot-action-ref.md). | versão de ação “Inicialização do AWS CDK ” | AWS CDK Versão CLI | | --- | --- | | 1.0.0 – 1.0.7 | mais recente | | 1.0.8 ou posterior | 2.99.1 | ## Imagem de tempo de execução usada pela ação 'AWS CDK bootstrap' A tabela a seguir mostra as imagens do ambiente de execução CodeCatalyst usadas para executar diferentes versões da ação de **AWS CDK bootstrap**. As imagens incluem diferentes conjuntos de ferramentas pré-instaladas. Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). **nota** Recomendamos atualizar sua ação **Inicialização do AWS CDK ** para a versão 2.x para aproveitar as ferramentas mais recentes disponíveis na imagem de março de 2024. Para atualizar a ação, defina a propriedade `Identifier` como `aws/cdk-bootstrap@v2` no arquivo de definição de fluxo de trabalho. Para obter mais informações, consulte [YAML da ação “Implantação do AWS CDK ”](cdk-dep-action-ref.md). | versão de ação “Inicialização do AWS CDK ” | Imagens de ambiente de runtime | | --- | --- | | 1.x | Imagens de novembro de 2022 | | 2.x | Imagens de março de 2024 | # Exemplo: inicialização de um aplicativo AWS CDK Consulte o [Exemplo: implantação de um aplicativo AWS CDK](cdk-dep-action-example-workflow.md) na [Implantando um AWS CDK aplicativo com um fluxo de trabalho](cdk-dep-action.md) para obter um fluxo de trabalho que inclui a ação **AWS CDK bootstrap**. # Adicionando a ação 'AWS CDK bootstrap' Use as instruções a seguir para adicionar a ação **Inicialização do AWS CDK ** ao seu fluxo de trabalho. **Antes de começar** Antes de usar a ação **Inicialização do AWS CDK **, verifique se você tem uma aplicação AWS CDK pronta. A ação bootstrap sintetizará o AWS CDK aplicativo antes da inicialização. Você pode escrever a aplicação em qualquer linguagem de programação compatível com o AWS CDK. Verifique se os arquivos AWS CDK do seu aplicativo estão disponíveis em: + Um [repositório de CodeCatalyst origem](source.md) ou + Um [artefato CodeCatalyst de saída](workflows-working-artifacts.md) gerado por outra ação do fluxo de trabalho ------ #### [ Visual ] **Para adicionar a ação 'AWS CDK bootstrap' usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Inicialização do AWS CDK ** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Inicialização do AWS CDK **. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas**, **Configuração** e **Saídas**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [YAML da ação “Inicialização do AWS CDK ”](cdk-boot-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. **nota** Se a ação **Inicialização do AWS CDK ** falhar com um erro `npm install`, consulte [Como faço para corrigir erros de “instalação npm”?](troubleshooting-workflows.md#troubleshooting-workflows-npm) para ter informações sobre como corrigir o erro. ------ #### [ YAML ] **Para adicionar a ação 'AWS CDK bootstrap' usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Inicialização do AWS CDK ** e selecione **\$1** para adicioná-la ao diagrama do fluxo de trabalho e abrir o painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [YAML da ação “Inicialização do AWS CDK ”](cdk-boot-action-ref.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. **nota** Se a ação **Inicialização do AWS CDK ** falhar com um erro `npm install`, consulte [Como faço para corrigir erros de “instalação npm”?](troubleshooting-workflows.md#troubleshooting-workflows-npm) para ter informações sobre como corrigir o erro. ------ # variáveis de “Inicialização do AWS CDK ” A ação **Inicialização do AWS CDK ** produz e define as seguintes variáveis em runtime. Elas são conhecidas como *variáveis predefinidas*. Para ter informações sobre como referenciar essas variáveis em um fluxo de trabalho, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). | Chave | Valor | | --- | --- | | deployment-platform | O nome da plataforma de implantação. Codificado para `AWS:CloudFormation`. | | region | O código de região em Região da AWS que a pilha de AWS CDK bootstrap foi implantada durante a execução do fluxo de trabalho. Exemplo: `us-west-2` | | stack-id | O Amazon Resource Name (ARN) da pilha de bootstrap implantada. AWS CDK Exemplo: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-bootstrap-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` | | SKIP-DEPLOYMENT | Um valor de `true` indica que a implantação da sua pilha de AWS CDK bootstrap foi ignorada durante a execução do fluxo de trabalho. Uma implantação da pilha será ignorada se não houver nenhuma alteração na pilha desde a última implantação. Essa variável só será produzida se o valor for `true`. Codificado para `true`. | # YAML da ação “Inicialização do AWS CDK ” Confira a seguir a definição de YAML da ação **Inicialização do AWS CDK **. Para saber como usar essa ação, consulte [Inicializando um AWS CDK aplicativo com um fluxo de trabalho](cdk-boot-action.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. CDKBootstrapAction\$1nn: Identifier: aws/cdk-bootstrap@v2 DependsOn: - action-name Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - artifact-name Outputs: Artifacts: - Name: cdk_bootstrap_artifacts Files: - "cdk.out/**/*" Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Configuration: Region: us-west-2 CdkCliVersion: version ``` ## CDKBootstrapAction (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Padrão: `CDKBootstrapAction_nn`. Interface de usuário correspondente: guia Configuração/**Nome de exibição da ação** ## Identifier (*CDKBootstrapAction*/**Identifier**) (Obrigatório) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). **nota** A especificação de `aws/cdk-bootstrap@v2` faz com que a ação seja executada na [imagem de março de 2024](build-images.md#build.default-image), que inclui ferramentas mais recentes, como Node.js 18. A especificação de `aws/cdk-bootstrap@v1` faz com que a ação seja executada na [imagem de novembro de 2022](build-images.md#build.previous-image), que inclui ferramentas mais antigas, como Node.js 16. Padrão: `aws/cdk-bootstrap@v2`. Interface de usuário correspondente: Diagrama de fluxo de trabalho/CDKBootstrapAction\$1nn/rótulo **aws/cdk-bootstrap@v2** ## DependsOn (*CDKBootstrapAction*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*CDKBootstrapAction*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*CDKBootstrapAction*/Compute/**Type**) (Obrigatório se [Compute](#cdk.boot.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2**(editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). **UI correspondente: Configuração tab/Advanced - opcional/Tipo de computação** ## Fleet (*CDKBootstrapAction*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. **UI correspondente: configuração tab/Advanced - opcional/frota de computação** ## Timeout (*CDKBootstrapAction*/**Timeout**) (Obrigatório) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Inputs (*CDKBootstrapAction*/**Inputs**) (Optional) A seção `Inputs` define os dados que a ação **Inicialização do AWS CDK ** precisa durante a execução de um fluxo de trabalho. Interface de usuário correspondente: guia **Entradas** **nota** Somente uma entrada (uma fonte ou um artefato) é permitida para cada ação **Inicialização do AWS CDK **. ## Sources (*CDKBootstrapAction*/Inputs/**Sources**) (Obrigatório se seu AWS CDK aplicativo estiver armazenado em um repositório de origem) Se seu AWS CDK aplicativo estiver armazenado em um repositório de origem, especifique o rótulo desse repositório de origem. A ação **Inicialização do AWS CDK ** sintetiza a aplicação nesse repositório antes de iniciar o processo de inicialização. Atualmente, o único rótulo do repositório compatível é `WorkflowSource`. Se seu AWS CDK aplicativo não estiver contido em um repositório de origem, ele deverá residir em um artefato gerado por outra ação. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*CDKBootstrapAction*/Inputs/**Artifacts**) (Obrigatório se seu AWS CDK aplicativo estiver armazenado em um [artefato de saída](workflows-working-artifacts-output.md) de uma ação anterior) Se seu AWS CDK aplicativo estiver contido em um artefato gerado por uma ação anterior, especifique esse artefato aqui. A ação **AWS CDK bootstrap** sintetiza o aplicativo no artefato especificado em um CloudFormation modelo antes de iniciar o processo de inicialização. Se a aplicação AWS CDK não estiver em um artefato, ela deverá residir em seu repositório de origem. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Entradas/**Artefatos - opcional** ## Outputs (*CDKBootstrapAction*/**Outputs**) (Optional) Define os dados que são gerados pela ação durante a execução de um fluxo de trabalho. Interface de usuário correspondente: guia **Saídas** ## Artifacts - output (*CDKBootstrapAction*/Outputs/**Artifacts**) (Optional) Especifique os artefatos gerados pela ação. Você pode referenciar esses artefatos como entrada em outras ações. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Saídas/**Artefatos** ## Name (*CDKBootstrapAction*/Outputs/Artifacts/**Name**) (Obrigatório se [Artifacts - output](#cdk.boot.outputs.artifacts) for incluído) Especifique o nome do artefato que conterá o CloudFormation modelo sintetizado pela ação de **AWS CDK bootstrap** em tempo de execução. O valor padrão é `cdk_bootstrap_artifacts`. Se você não especificar um artefato, a ação sintetizará o modelo, mas não o salvará em um artefato. Pense em salvar o modelo sintetizado em um artefato para preservar um registro dele para fins de teste ou solução de problemas. **UI correspondente: artefato de tab/Artifacts/Add saída/Nome do artefato de construção** ## Files (*CDKBootstrapAction*/Outputs/Artifacts/**Files**) (Obrigatório se [Artifacts - output](#cdk.boot.outputs.artifacts) for incluído) Especifique os arquivos a serem incluídos no artefato. Você deve especificar `"cdk.out/**/*"` para incluir o modelo sintetizado CloudFormation do seu AWS CDK aplicativo. **nota** `cdk.out` é o diretório padrão no qual os arquivos sintetizados são salvos. Se você especificou um diretório de saída diferente de `cdk.out` no arquivo `cdk.json`, especifique esse diretório aqui em vez de `cdk.out`. **UI correspondente: produz tab/Artifacts/Add artefatos/arquivos produzidos pela compilação** ## Environment (*CDKBootstrapAction*/**Environment**) (Obrigatório) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*CDKBootstrapAction*/Environment/**Name**) (Obrigatório se [Environment](#cdk.boot.environment) for incluído) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*CDKBootstrapAction*/Environment/**Connections**) (Opcional nas versões mais recentes da ação; obrigatório nas versões mais antigas) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Name (*CDKBootstrapAction*/Environment/Connections/**Name**) (Obrigatório se [Connections](#cdk.boot.environment.connections) for incluído) Especifique o nome da conexão da conta. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Role (*CDKBootstrapAction*/Environment/Connections/**Role**) (Obrigatório se [Connections](#cdk.boot.environment.connections) for incluído) Especifique o nome da função do IAM que a ação **AWS CDK bootstrap** usa para acessar AWS e adicionar a pilha de bootstrap. Certifique-se de ter [adicionado a função ao seu CodeCatalyst espaço](ipa-connect-account-addroles.md) e de que a função inclua as seguintes políticas. Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas apropriadas. Você pode usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação, se desejar. Para obter mais informações sobre essa função, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' '/ Função Environment/account/role** ## Configuration (*CDKBootstrapAction*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## Region (*CDKBootstrapAction*/Configuration/**Region**) (Obrigatório) Especifique Região da AWS no qual a pilha de bootstrap será implantada. Essa região deve corresponder àquela na qual seu AWS CDK aplicativo está implantado. Para obter uma lista dos códigos das regiões, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes). Interface de usuário correspondente: guia Configuração/**Região** ## CdkCliVersion (*CDKBootstrapAction*/Configuration/**CdkCliVersion**) (Optional) Essa propriedade está disponível com a versão 1.0.13 ou posterior da ação **Implantação do AWS CDK ** e a versão 1.0.8 ou posterior da ação **Inicialização do AWS CDK **. Especifique um dos seguintes: + A versão completa da interface de linha de AWS Cloud Development Kit (AWS CDK) comando (CLI) (também chamada de AWS CDK kit de ferramentas) que você deseja que essa ação use. Exemplo: `2.102.1`. Considere especificar uma versão completa para garantir consistência e estabilidade ao criar e implantar a aplicação. Ou + `latest`. Pense em especificar `latest` para aproveitar os recursos e correções mais recentes da CLI do CDK. A ação baixará a versão especificada (ou a versão mais recente) da AWS CDK CLI para a [imagem de CodeCatalyst compilação](build-images.md) e, em seguida, usará essa versão para executar os comandos necessários para implantar seu aplicativo CDK ou inicializar seu ambiente. AWS Para ter uma lista das versões compatíveis da CLI do CDK que você pode usar, consulte [Versões do AWS CDK](https://docs.aws.amazon.com/cdk/api/versions.html). Se você omitir essa propriedade, a ação usará uma versão padrão da AWS CDK CLI descrita em um dos tópicos a seguir: + [Versões da CLI do CDK usadas pela ação 'implantar'AWS CDK](cdk-dep-action.md#cdk-dep-action-cdk-version) + [Versões do CDK CLI usadas pela ação AWS CDK "bootstrap”](cdk-boot-action.md#cdk-boot-action-cdk-version) UI correspondente: guia de configuração/versão **AWS CDK CLI** # Publicação de arquivos no Amazon S3 com um fluxo de trabalho Esta seção descreve como publicar arquivos no Amazon S3 usando um CodeCatalyst fluxo de trabalho. Para fazer isso, você deve adicionar a ação **Publicação no Amazon S3** ao seu fluxo de trabalho. A ação **Publicar do Amazon S3** copia arquivos de um diretório de origem para um bucket do Amazon S3. O diretório de origem pode residir em: + Um [repositório de origem](source.md) ou + Um [artefato de saída](workflows-working-artifacts.md) gerado por outra ação do fluxo de trabalho **Topics** + [ ## Quando usar a ação “Publicação no Amazon S3” ](#s3-pub-action-when-to-use) + [ ## Imagem de runtime usada pela ação “Publicação no Amazon S3” ](#s3-pub-action-runtime) + [ # Exemplo: publicação de arquivos no Amazon S3 ](s3-pub-action-example-workflow.md) + [ # Adicionar a ação “Publicação no Amazon S3” ](s3-pub-action-add.md) + [ # Ação YAML de “Publicação no Amazon S3” ](s3-pub-action-ref.md) ## Quando usar a ação “Publicação no Amazon S3” Use esta ação se: + Você tiver um fluxo de trabalho que gera arquivos que você deseja armazenar no Amazon S3. Por exemplo, você pode ter um fluxo de trabalho que cria um site estático que deseja hospedar no Amazon S3. Nesse caso, seu fluxo de trabalho incluiria uma [ação de criação](build-add-action.md) para compilar os arquivos HTML e de suporte do site e uma ação **Publicação no Amazon S3** para copiar os arquivos no Amazon S3. + Você tem um repositório de origem que contém arquivos que deseja armazenar no Amazon S3. Por exemplo, você pode ter um repositório de origem com arquivos de origem da aplicação que deseja arquivar todas as noites no Amazon S3. ## Imagem de runtime usada pela ação “Publicação no Amazon S3” A ação **Publicação no Amazon S3** é executada em uma [imagem de novembro de 2022](build-images.md#build.previous-image). Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). # Exemplo: publicação de arquivos no Amazon S3 O exemplo de fluxo de trabalho a seguir inclui a ação **Publicação no Amazon S3**, junto com uma ação de criação. O fluxo de trabalho compila um site de documentação estática e depois o publica no Amazon S3, onde está hospedado. O fluxo de trabalho consiste nos seguintes blocos de compilação que são executados sequencialmente: + Um **gatilho**: esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + Uma ação de **criação** (`BuildDocs`) – No gatilho, a ação compila um site de documentação estática (`mkdocs build`) e adiciona os arquivos HTML associados e os metadados de suporte a um artefato chamado `MyDocsSite`. Para ter mais informações sobre a ação de criação, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). + Uma ação **Publicação no Amazon S3** (`PublishToS3`) – Ao concluir a ação de criação, essa ação copia o site no artefato `MyDocsSite` para o Amazon S3 para hospedagem. **nota** O exemplo de fluxo de trabalho a seguir serve para fins ilustrativos e não funcionará sem configuração adicional. **nota** No código YAML a seguir, você pode omitir a seção `Connections:` se quiser. Se você omitir esta seção, deverá garantir que o perfil especificado no campo **Perfil do IAM padrão** em seu ambiente inclua as permissões e políticas de confiança exigidas pela ação **Publicação no Amazon S3**. Para ter mais informações sobre como configurar um ambiente com um perfil do IAM padrão, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Para ter mais informações sobre as permissões e as políticas de confiança exigidas pela ação **Publicação no Amazon S3**, consulte a descrição da propriedade [Role](s3-pub-action-ref.md#s3.pub.environment.connections.role) em [Ação YAML de “Publicação no Amazon S3”](s3-pub-action-ref.md). ``` Name: codecatalyst-s3-publish-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: BuildDocs: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: echo BuildDocs started on `date` - Run: pip install --upgrade pip - Run: pip install mkdocs - Run: mkdocs build - Run: echo BuildDocs completed on `date` Outputs: Artifacts: - Name: MyDocsSite Files: - "site/**/*" PublishToS3: Identifier: aws/s3-publish@v1 Environment: Name: codecatalyst-s3-publish-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-s3-publish-build-role Inputs: Sources: - WorkflowSource Artifacts: - MyDocsSite Configuration: DestinationBucketName: amzn-s3-demo-bucket SourcePath: /artifacts/PublishToS3/MyDocSite/site TargetPath: my/docs/site ``` # Adicionar a ação “Publicação no Amazon S3” Use as instruções a seguir para adicionar a ação **Publicação no Amazon S3** ao seu fluxo de trabalho. ------ #### [ Visual ] **Para adicionar a ação “Publicação no Amazon S3” usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Publicação no Amazon S3** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Publicação no Amazon S3**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas**, **Configuração** e **Saídas**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [Ação YAML de “Publicação no Amazon S3”](s3-pub-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar a ação “Publicação no Amazon S3” usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Publicação no Amazon S3** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Publicação no Amazon S3**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [Ação YAML de “Publicação no Amazon S3”](s3-pub-action-ref.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Ação YAML de “Publicação no Amazon S3” Confira a seguir a definição de YAML da ação **Publicação no Amazon S3**. Para saber como usar essa ação, consulte [Publicação de arquivos no Amazon S3 com um fluxo de trabalho](s3-pub-action.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. S3Publish\$1nn: Identifier: aws/s3-publish@v1 DependsOn: - build-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: Sources: - source-name-1 Artifacts: - artifact-name Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Configuration: SourcePath: my/source DestinationBucketName: amzn-s3-demo-bucket TargetPath: my/target ``` ## S3Publish (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Padrão: `S3Publish_nn`. Interface de usuário correspondente: guia Configuração/**Nome da ação** ## Identifier (*S3Publish*/**Identifier**) (Obrigatório) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Padrão: `aws/s3-publish@v1`. Interface de usuário correspondente: Diagrama de fluxo de trabalho/S3Publish\$1nn/rótulo **aws/s3-publish@v1** ## DependsOn (*S3Publish*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*S3Publish*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*S3Publish*/Compute/**Type**) (Obrigatório se [Compute](#s3.pub.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2**(editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). Interface de usuário correspondente: guia Configuração/**Tipo de computação** ## Fleet (*S3Publish*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. Interface de usuário correspondente: guia Configuração/**Frota de computação** ## Timeout (*S3Publish*/**Timeout**) (Obrigatório) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Inputs (*S3Publish*/**Inputs**) (Optional) A seção `Inputs` define os dados que `S3Publish` precisa durante a execução de um fluxo de trabalho. **nota** São permitidas no máximo quatro entradas (uma origem e três artefatos) para cada ação **Implantação do AWS CDK **. As variáveis não são contadas nesse total. Se você precisar consultar arquivos que residem em entradas diferentes (digamos, uma origem e um artefato), a entrada de origem será a entrada primária e o artefato será a entrada secundária. As referências a arquivos em entradas secundárias usam um prefixo especial para diferirem das primárias. Para obter detalhes, consulte [Exemplo: referência de arquivos em vários artefatos](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file). Interface de usuário correspondente: guia **Entradas** ## Sources (*S3Publish*/Inputs/**Sources**) (Obrigatório se os arquivos que você deseja publicar no Amazon S3 estiverem armazenados em um repositório de origem) Se os arquivos que você deseja publicar no Amazon S3 estiverem armazenados em um repositório de origem, especifique o rótulo desse repositório de origem. Atualmente, o único rótulo compatível é `WorkflowSource`. Se os arquivos que você deseja publicar no Amazon S3 não estiverem contidos em um repositório de origem, eles devem residir em um artefato gerado por outra ação. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*S3Publish*/Inputs/**Artifacts**) (Obrigatório se os arquivos que você deseja publicar no Amazon S3 estiverem armazenados em um [artefato de saída](workflows-working-artifacts-output.md) de uma ação anterior) Se os arquivos que você deseja publicar no Amazon S3 estiverem em um artefato gerado por uma ação anterior, especifique esse artefato aqui. Se as aplicações não estiverem em um artefato, elas deverão residir no repositório de origem. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Configuração/**Artefatos - opcional** ## Variables - input (*S3Publish*/Inputs/**Variables**) (Optional) Especifique uma sequência de name/value pares que defina as variáveis de entrada que você deseja disponibilizar para a ação. Os nomes de variável são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de variável. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Interface de usuário correspondente: guia Entradas/**Variáveis - opcional** ## Environment (*S3Publish*/**Environment**) (Obrigatório) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*S3Publish*/Environment/**Name**) (Obrigatório se [Environment](#s3.pub.environment) for incluído) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*S3Publish*/Environment/**Connections**) (Opcional nas versões mais recentes da ação; obrigatório nas versões mais antigas) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Name (*S3Publish*/Environment/Connections/**Name**) (Obrigatório se [Connections](#s3.pub.environment.connections) for incluído) Especifique o nome da conexão da conta. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Role (*S3Publish*/Environment/Connections/**Role**) (Obrigatório se [Connections](#s3.pub.environment.connections) for incluído) Especifique o nome da função do IAM que a ação de **publicação do Amazon S3** usa para acessar AWS e copiar arquivos para o Amazon S3. Certifique-se de ter [adicionado a função ao seu CodeCatalyst espaço](ipa-connect-account-addroles.md) e de que a função inclua as seguintes políticas. Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas a seguir. + A política de permissões a seguir: **Atenção** Limite as permissões às exibidas na política a seguir. Usar um perfil com permissões mais amplas pode representar um risco de segurança. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:ListBucket", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] } ] } ``` ------ + A política de confiança personalizada a seguir: **nota** Você pode usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação, se desejar. Para obter mais informações sobre essa função, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' '/ Função Environment/account/role** ## Configuration (*S3Publish*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## SourcePath (*S3Publish*/Configuration/**SourcePath**) (Obrigatório) Especifique o nome e o caminho de um diretório ou arquivo que você deseja publicar no Amazon S3. O diretório ou arquivo pode residir em um repositório de origem ou em um artefato de uma ação anterior e é relativo ao repositório de origem ou à raiz do artefato. Exemplos: A especificação `./myFolder/` copia o conteúdo de `/myFolder` para o Amazon S3 e preserva a estrutura de diretórios subjacente. A especificação `./myFolder/myfile.txt` copia *somente *`myfile.txt` para o Amazon S3. (A estrutura de diretórios foi removida.) Não é possível usar curingas. **nota** Talvez seja necessário adicionar um prefixo ao diretório ou caminho do arquivo para indicar em qual artefato ou origem encontrá-lo. Para obter mais informações, consulte [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md) e [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). Interface de usuário correspondente: guia Configuração/**Caminho de origem** ## DestinationBucketName (*S3Publish*/Configuration/**DestinationBucketName**) (Obrigatório) Especifique o nome do bucket do Amazon S3 em que você deseja publicar os arquivos. Interface de usuário correspondente: guia Configuração/**Bucket de destino - opcional** ## TargetPath (*S3Publish*/Configuration/**TargetPath**) (Optional) Especifique o nome e o caminho do diretório no Amazon S3 em que você deseja publicar seus arquivos. Se o diretório não existir, ele será criada. O caminho do diretório não deve incluir o nome do bucket. Exemplos: `myS3Folder` `./myS3Folder/myS3Subfolder` Interface de usuário correspondente: guia Configuração/**Diretório de destino - opcional** # Implantação em e Contas da AWS VPCs Usando [CodeCatalyst fluxos de trabalho](workflow.md), você pode implantar aplicativos e outros recursos para atingir Conta da AWS s e Amazon VPCs na AWS nuvem. Para habilitar essas implantações, você deve configurar CodeCatalyst ambientes. Um CodeCatalyst *ambiente*, que não deve ser confundido com um [ambiente de desenvolvimento](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html), define o Amazon VPC de destino Conta da AWS e opcional ao qual um CodeCatalyst [fluxo de trabalho](workflow.md) se conecta. Um ambiente também define a [função do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um fluxo de trabalho precisa para acessar os AWS serviços e recursos na conta de destino. É possível configurar vários ambientes e atribuir a eles nomes, como desenvolvimento, teste, preparação e produção. Quando você implanta nesses ambientes, as informações sobre as implantações aparecem nas CodeCatalyst guias **Atividade** de **implantação e Destinos** de implantação no ambiente. ## Como começo a usar ambientes? As etapas de alto nível para adicionar e usar um CodeCatalyst ambiente são as seguintes: 1. No seu CodeCatalyst espaço, **conecte uma ou mais AWS contas**. Durante esse processo, adicione os perfis do IAM que seu fluxo de trabalho exige para acessar recursos na sua Conta da AWS. Para obter mais informações, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). 1. Em seu CodeCatalyst projeto, **crie um ambiente** que inclua uma das funções Conta da AWS s e IAM da etapa 1. Para obter mais informações, consulte [Criar um ambiente](deploy-environments-creating-environment.md). 1. Em seu CodeCatalyst projeto, em um fluxo de trabalho, **adicione uma [ação](workflows-actions.md) que aponte para o ambiente** que você criou na etapa 2. Para obter mais informações, consulte [Adição de uma ação a um fluxo de trabalho](workflows-add-action.md). Agora você configurou um ambiente. A ação agora pode implantar recursos na Conta da AWS especificada no ambiente. **nota** Você também pode adicionar uma Amazon VPC ao ambiente. Para obter mais informações, consulte [Adicionar conexões VPC a um espaço](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) no *Guia de CodeCatalyst Administração e.* [Associação de uma VPC a um ambiente](deploy-environments-associate-vpc.md) ## Podem existir vários ambientes em um único fluxo de trabalho? Sim. Se um fluxo de trabalho incluir várias ações, cada uma dessas ações poderá ser atribuída a um ambiente. Por exemplo, você pode ter um fluxo de trabalho que inclua duas ações de implantação, em que uma é atribuída a um ambiente `my-staging-enviroment` e outra a um ambiente `my-production-environment`. ## Quais ações de fluxo de trabalho oferecem suporte aos ambientes? Qualquer ação de fluxo de trabalho que implanta recursos na AWS nuvem ou se comunica com os AWS serviços por outros motivos (como monitoramento e geração de relatórios) oferece suporte aos ambientes. ## Quais ações permitem que suas informações de implantação sejam exibidas CodeCatalyst? Das ações de fluxo de trabalho que oferecem suporte a ambientes, apenas algumas oferecem suporte para que suas informações de implantação sejam exibidas nas páginas **Atividade** de **implantação e Destinos** de implantação do CodeCatalyst console. As ações de fluxo de trabalho a seguir permitem que as informações de implantação sejam exibidas: + **Deploy CloudFormation stack** — Para obter mais informações, consulte [Implantação de uma pilha CloudFormation](deploy-action-cfn.md) + **Implantar no Amazon ECS**: para ter mais informações, consulte [Implantação no Amazon ECS com um fluxo de trabalho](deploy-action-ecs.md) + **Implantar no cluster do Kubernetes**: para ter mais informações, consulte [Implantar no Amazon EKS com um fluxo de trabalho](deploy-action-eks.md) + **AWS CDK implantar** — Para obter mais informações, consulte [Implantando um AWS CDK aplicativo com um fluxo de trabalho](cdk-dep-action.md) ## Regiões aceitas A página **Ambientes** pode exibir recursos em qualquer região da AWS . ## Um ambiente é obrigatório? Um ambiente é obrigatório se a ação do fluxo de trabalho à qual ele está atribuído implantar recursos na AWS nuvem ou se comunicar com os AWS serviços por outros motivos (como monitoramento e geração de relatórios). Por exemplo, se você tem uma ação de criação que cria um aplicativo, mas não precisa se comunicar com sua VPC Conta da AWS ou com a Amazon VPC, não é necessário atribuir um ambiente à ação. Se, no entanto, a ação de criação enviar registros para o CloudWatch serviço da Amazon em seu Conta da AWS, a ação deverá ter um ambiente atribuído. **Topics** + [ ## Como começo a usar ambientes? ](#deploy-environments-get-started) + [ ## Podem existir vários ambientes em um único fluxo de trabalho? ](#deploy-environments-multiple) + [ ## Quais ações de fluxo de trabalho oferecem suporte aos ambientes? ](#deploy-environments-supported) + [ ## Quais ações permitem que suas informações de implantação sejam exibidas CodeCatalyst? ](#deploy-environments-supported-targets) + [ ## Regiões aceitas ](#deploy-environments-supported-regions) + [ ## Um ambiente é obrigatório? ](#deploy-environments-optional-or-mandatory) + [ # Criar um ambiente ](deploy-environments-creating-environment.md) + [ # Associação de um ambiente a uma ação ](deploy-environments-add-app-to-environment.md) + [ # Associação de uma VPC a um ambiente ](deploy-environments-associate-vpc.md) + [ # Associando um Conta da AWS a um ambiente ](deploy-environments-associate-account.md) + [ # Alteração do perfil do IAM de uma ação ](deploy-environments-switch-role.md) # Criar um ambiente Use as instruções a seguir para criar um ambiente que você possa associar posteriormente a uma ação de fluxo de trabalho. **Antes de começar** Você precisará do seguinte: + Um CodeCatalyst espaço. Para obter mais informações, consulte [Configuração e login no CodeCatalystConfiguração e login no CodeCatalyst](setting-up-topnode.md). + Um CodeCatalyst projeto. Para obter mais informações, consulte [Criar um projeto com um esquema](projects-create.md#projects-create-console-template). + Uma conexão de AWS conta que inclui as funções do IAM que sua ação de fluxo de trabalho precisará acessar AWS. Para ter informações sobre a criação de uma conexão de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Você pode usar no máximo uma conexão de conta por ambiente. **nota** Você pode criar um ambiente sem uma conexão de conta. No entanto, você precisará voltar e adicionar a conexão posteriormente. + Uma das seguintes CodeCatalyst funções: + **Administrador do espaço** + **Administrador do projeto** + **Contributor (Colaborador)** **nota** Se você tiver o **Perfil de colaborador**, poderá criar um ambiente, mas não poderá associá-lo a uma conexão de Conta da AWS . Você precisará pedir a alguém com a função de **administrador do Space** ou **administrador do projeto** que associe o ambiente a uma Conta da AWS conexão. Para ter mais informações sobre permissões e perfis, consulte [Concessão de permissões de projeto aos usuários](projects-members.md). **Para criar um ambiente** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, selecione **CI/CD** e **Ambientes**. 1. Em **Nome do ambiente**, insira um nome, como **Production** ou **Staging**. 1. Em **Tipo de ambiente**, selecione uma das seguintes opções: + **Não produção**: um ambiente em que você pode testar a aplicação para garantir que ela esteja funcionando conforme o esperado antes de colocá-la em produção. + **Produção**: um ambiente “ativo” que está disponível publicamente e hospeda a aplicação finalizada. Se você selecionar **Produção**, um selo **Produção** aparecerá na interface de usuário ao lado de todas as ações às quais o ambiente esteja associado. O selo ajuda você a ver rapidamente quais ações estão sendo implantadas na produção. Além da aparência do selo, não há diferenças entre ambientes de produção e não produção. 1. (Opcional) Em **Descrição**, insira uma descrição como **Production environment for the hello-world app**. 1. Em **Conta da AWS conexão - opcional**, escolha a conexão de AWS conta que você deseja associar a esse ambiente. As ações de fluxo de trabalho atribuídas a esse ambiente poderão se conectar à Conta da AWS associada. Para obter mais informações sobre a criação de Conta da AWS conexões em CodeCatalyst, consulte[Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Se a Conta da AWS conexão que você deseja usar não estiver listada, talvez seja porque ela não é permitida em seu projeto. Para obter mais informações, consulte [Configuração de conexões de contas restritas a projetos](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html) no *Amazon CodeCatalyst * Administrator Guide. 1. Em **Perfil do IAM padrão**, escolha o perfil do IAM que você deseja associar a esse ambiente. As ações de fluxo de trabalho atribuídas a esse ambiente herdarão essa função do IAM e poderão usá-la para se conectar aos serviços e recursos em seu Conta da AWS. Se você precisar atribuir o ambiente a várias ações e essas ações precisarem de perfis do IAM diferentes do padrão especificado aqui, você poderá especificar os diferentes perfis na guia **Configuração** de cada ação, usando a opção **Alternar perfil**. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Se a função do IAM que você deseja usar como padrão não estiver listada, pode ser porque você ainda não a adicionou à sua Conta da AWS conexão. Para adicionar um perfil do IAM a uma conexão de conta, consulte [Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). 1. (Opcional) Em **Conexão VPC**, escolha uma conexão VPC que você deseja associar a esse ambiente. Para obter mais informações sobre a criação de conexões VPC, consulte Gerenciando [Amazon Virtual Private Clouds](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html) no *Amazon CodeCatalyst Administrator Guide*. Se a conexão VPC que você deseja usar não estiver listada, talvez seja porque ela inclui uma Conta da AWS conexão que não é permitida em seu projeto. Para obter mais informações, consulte [Configuração de conexões de contas restritas a projetos](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html) no *Amazon CodeCatalyst * Administrator Guide. 1. Escolha **Criar ambiente**. CodeCatalyst cria um ambiente vazio. **Próximas etapas** + Agora que criou um ambiente, você pode associá-lo a uma ação de fluxo de trabalho. Para obter mais informações, consulte [Associação de um ambiente a uma ação](deploy-environments-add-app-to-environment.md). # Associação de um ambiente a uma ação Quando você associa um ambiente a uma [ação de fluxo de trabalho compatível](deploy-environments.md#deploy-environments-supported), a função padrão do IAM do ambiente e a Amazon VPC opcional são atribuídas à ação. Conta da AWS A ação pode se conectar e implantar na Conta da AWS usando o perfil do IAM e também se conectar à Amazon VPC opcional. Use as instruções a seguir para associar um ambiente a uma ação. ## Etapa 1: associar o ambiente a uma ação de fluxo de trabalho Use o procedimento a seguir para associar um ambiente a uma ação de fluxo de trabalho. ------ #### [ Visual ] **Para associar um ambiente a uma ação de fluxo de trabalho usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, escolha uma ação compatível com ambientes. Para obter mais informações, consulte [Quais ações permitem que suas informações de implantação sejam exibidas CodeCatalyst?](deploy-environments.md#deploy-environments-supported-targets). 1. Escolha a guia **Configuração** e especifique as informações no campo **Ambiente**, da seguinte forma. **Ambiente** Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). 1. (Opcional) Altere o perfil do IAM associado à ação. Você talvez queira alterar o perfil se ele contiver o conjunto errado de permissões para a ação. Para alterar o perfil: 1. No **What's in*my-environment*?** caixa e escolha o ícone de elipse vertical (). ![\[Ellipsis.\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/elipsis.png) 1. Escolha uma das seguintes opções: + **Alternar perfil**. Escolha essa opção para alterar o perfil do IAM usado por essa ação, e somente essa ação. Outras ações continuam usando o perfil do IAM padrão especificado no ambiente associado. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). + **Editar ambiente**. Escolha essa opção para alterar o perfil do IAM padrão listado em seu ambiente. Quando você escolhe essa opção, sua ação — e qualquer outra ação associada ao mesmo ambiente — começa a usar o novo perfil do IAM padrão. **Importante** Tenha cuidado ao atualizar o perfil do IAM padrão. Alterar o perfil pode levar a falhas de ação se as permissões no perfil não forem suficientes para todas as ações que compartilham o ambiente. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para associar um ambiente a uma ação de fluxo de trabalho usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Na ação do fluxo de trabalho que você deseja associar a um ambiente, adicione um código semelhante ao seguinte: ``` action-name: Environment: Name: environment-name ``` Para ter mais informações, consulte o tópico [Tipos de ação](workflows-actions.md#workflows-actions-types). Este tópico tem links para a documentação de cada ação, incluindo a referência YAML. 1. (Opcional) Se você quiser que a ação use um perfil diferente do perfil do IAM padrão listado no ambiente, adicione uma seção `Connections:` que inclua o perfil que você deseja usar. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ ## Etapa 2: preencher a página de atividades de implantação Depois de associar um ambiente a uma ação de fluxo de trabalho, você pode preencher as páginas **Atividade de implantação** **e Destino** de implantação na seção **Ambientes** do CodeCatalyst console com informações de implantação. Use as instruções a seguir para preencher essas páginas. **nota** Apenas algumas ações permitem que suas informações de implantação sejam exibidas no CodeCatalyst console. Para obter mais informações, consulte [Quais ações permitem que suas informações de implantação sejam exibidas CodeCatalyst?](deploy-environments.md#deploy-environments-supported-targets). **Para adicionar informações de implantação ao CodeCatalyst** 1. Se a execução de um fluxo de trabalho não foi iniciada automaticamente quando você confirmou as alterações em [Etapa 1: associar o ambiente a uma ação de fluxo de trabalho](#deploy-environments-add-app-to-environment-assoc), inicie manualmente a execução da seguinte forma: 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Executar**. A execução do fluxo de trabalho inicia uma nova implantação, o que faz com que CodeCatalyst as informações de implantação sejam adicionadas CodeCatalyst a. 1. Verifique se a atividade de implantação foi adicionada ao CodeCatalyst console: 1. No painel de navegação, selecione **CI/CD** e **Ambientes**. 1. Escolha seu ambiente (por exemplo, `Production`). 1. Escolha a guia **Atividade de implantação** e verifique se uma implantação aparece com o **Status** **BEM-SUCEDIDO**. Isso indica que a execução de um fluxo de trabalho implantou os recursos da aplicação. 1. Escolha a guia **Destinos de implantação** e verifique se os recursos da aplicação aparecem. # Associação de uma VPC a um ambiente Quando uma ação é configurada com um ambiente que tem uma conexão VPC, a ação é executada conectada à VPC, aderindo às regras de rede e aos recursos de acesso especificados pela VPC associada. A mesma conexão VPC pode ser usada por um ou mais ambientes. Use as instruções a seguir para associar uma conexão VPC a um ambiente. **Para associar uma conexão VPC a um ambiente** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, selecione **CI/CD** e **Ambientes**. 1. Escolha seu ambiente (por exemplo, `Production`). 1. Escolha a guia **Propriedades do ambiente**. 1. Selecione **Gerenciar conexão VPC**, escolha a conexão VPC desejada e selecione **Confirmar**. Isso associa a conexão VPC selecionada a esse ambiente. **nota** Se a conexão VPC que você deseja usar não estiver listada, talvez seja porque ela inclui uma Conta da AWS conexão que não é permitida em seu projeto. Para obter mais informações, consulte [Configuração de conexões de contas restritas a projetos](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html) no *Amazon CodeCatalyst* Administrator Guide. Para obter mais informações, consulte [Gerenciando Amazon Virtual Private Clouds](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html) no *Guia CodeCatalyst do Administrador*. # Associando um Conta da AWS a um ambiente Use as instruções a seguir para associar um Conta da AWS a um ambiente. Quando você associa um Conta da AWS a um ambiente, as ações do fluxo de trabalho atribuídas ao ambiente poderão se conectar ao Conta da AWS. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). **Antes de começar** Você precisará do seguinte: + Uma conexão de AWS conta que inclui as funções do IAM que sua ação de fluxo de trabalho precisará acessar AWS. Para ter informações sobre a criação de uma conexão de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Você pode usar no máximo uma conexão de conta por ambiente. + Uma das seguintes CodeCatalyst funções: **administrador do espaço ou administrador** **do projeto**. Para obter mais informações, consulte [Concessão de permissões de projeto aos usuários](projects-members.md). **Para associar um Conta da AWS a um ambiente** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, selecione **CI/CD** e **Ambientes**. 1. Escolha seu ambiente (por exemplo, `Production`). 1. Selecione **Editar ambiente**. 1. Em **Propriedades do ambiente**, na lista suspensa **Conexão da Conta da AWS - opcional**, escolha a Conta da AWS desejada. Se a Conta da AWS conexão que você deseja usar não estiver listada, talvez seja porque ela não é permitida em seu projeto. Para obter mais informações, consulte [Configuração de conexões de contas restritas a projetos](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html) no *Amazon CodeCatalyst * Administrator Guide. 1. Em **Perfil do IAM padrão**, escolha o perfil do IAM que você deseja associar a esse ambiente. As ações de fluxo de trabalho atribuídas a esse ambiente herdarão essa função do IAM e poderão usá-la para se conectar aos serviços e recursos em seu Conta da AWS. Se a função do IAM que você deseja usar como padrão não estiver listada, pode ser porque você ainda não a adicionou à sua Conta da AWS conexão. Para adicionar um perfil do IAM a uma conexão de conta, consulte [Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). # Alteração do perfil do IAM de uma ação Por padrão, quando você associa um [ambiente](deploy-environments.md) a uma [ação](workflows-actions.md) de fluxo de trabalho, a ação herda o perfil do IAM padrão especificado no ambiente. Você pode alterar esse comportamento para que a ação use um perfil diferente. Talvez você queira que uma ação use um perfil diferente se o perfil do IAM padrão não tiver as permissões de que a ação precisa para operar na nuvem da AWS . Para atribuir um perfil do IAM diferente a uma ação, você pode usar a opção **Alternar perfil** no editor visual ou a propriedade `Connections:` no editor YAML. O novo perfil substitui o perfil do IAM padrão especificado no ambiente, permitindo que você mantenha o perfil do IAM padrão como está. Talvez você queira manter o perfil do IAM padrão como está se houver outras ações que o usem. Use as instruções a seguir para configurar uma ação para usar um perfil do IAM diferente do especificado no ambiente. ------ #### [ Visual ] **Para atribuir um perfil do IAM diferente a uma ação (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Escolha a caixa que representa a ação cujo perfil do IAM você deseja atualizar. 1. Escolha a guia **Configuração**. 1. No **What's in*my-environment*?** caixa, escolha o ícone de elipse vertical (). ![\[Ellipsis.\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/elipsis.png) 1. Selecione **Alternar perfil**. 1. Na caixa de diálogo **Alternar perfil**, na lista suspensa **Perfil do IAM**, escolha o perfil do IAM que você deseja que a ação use. Esse perfil substituirá o perfil do IAM padrão no ambiente. Se o perfil que você deseja usar não estiver na lista, adicione-o ao seu espaço. Para obter mais informações, consulte [Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). A função escolhida agora aparece na seção **What's in*my-environment*?** caixa junto com um selo **Definido no fluxo de trabalho**. O perfil também aparece no arquivo de definição do fluxo de trabalho, na seção `Connections:`. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para atribuir um perfil do IAM diferente a uma ação (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Na ação do fluxo de trabalho em que você deseja usar um perfil do IAM diferente, adicione uma seção `Connections:` semelhante à seguinte: ``` action-name: Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name ``` No código anterior, *account-connection-name* substitua pelo nome da [conexão da conta](ipa-connect-account.md) que contém a função do IAM e *iam-role-name* substitua pelo nome da função do IAM que você deseja que a ação use. Esse perfil substituirá o perfil do IAM padrão no ambiente. Verifique se adicionou o perfil ao seu espaço. Para obter mais informações, consulte [Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). Para ter mais informações, consulte o tópico [Tipos de ação](workflows-actions.md#workflows-actions-types). Este tópico tem links para a documentação de cada ação, incluindo a referência YAML. ------ # Exibir o URL da aplicação no diagrama do fluxo de trabalho Se o seu fluxo de trabalho implantar um aplicativo, você poderá configurar CodeCatalyst a Amazon para exibir a URL do aplicativo como um link clicável. Esse link aparece no CodeCatalyst console, dentro da ação que o implantou. O diagrama de fluxo de trabalho a seguir mostra o URL de **Exibir aplicação** que aparece na parte inferior de uma ação. ![\[Exibir URL da aplicação\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/deploy/view-app-url.png) Ao tornar essa URL clicável no CodeCatalyst console, você pode verificar rapidamente a implantação do seu aplicativo. **nota** O URL da aplicação não é compatível com a ação **Implantar no Amazon ECS**. Para habilitar esse recurso, adicione uma variável de saída à sua ação com um nome que contenha `appurl` ou `endpointurl`. Você pode usar um nome com ou sem um traço (`-`), sublinhado (`_`) ou espaço (` `). A string diferencia maiúsculas e minúsculas. Defina o valor da variável como o URL `http` ou `https` da aplicação implantada. **nota** Se você estiver atualizando uma variável de saída existente para incluir o `app url`, ou a string `endpoint url`, atualize todas as referências a essa variável para usar o novo nome da variável. Para ver as etapas detalhadas, consulte um destes procedimentos: + [Para exibir o URL do aplicativo na ação “AWS CDK implantar”](#deploy-app-url-cdk) + [Para exibir o URL do aplicativo na ação “Implantar CloudFormation pilha”](#deploy-app-url-cfn) + [Para exibir o URL da aplicação em todas as outras ações](#deploy-app-url-other) Quando terminar de configurar o URL, verifique se ele aparece conforme o esperado seguindo estas instruções: + [Como verificar se o URL da aplicação foi adicionado](#deploy-app-url-verify) **Para exibir o URL do aplicativo na ação “AWS CDK implantar”** 1. Se você estiver usando a ação de **AWS CDK implantação**, adicione uma `CfnOutput` construção (que é um par de valores-chave) no código do seu AWS CDK aplicativo: + O nome da chave deve conter `appurl`, ou`endpointurl`, com ou sem um traço (`-`), sublinhado (`_`) ou espaço (` `). A string diferencia maiúsculas e minúsculas. + O valor deve ser o URL `http` ou `https` da aplicação implantada. Por exemplo, seu AWS CDK código pode ter a seguinte aparência: ``` import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib'; import * as dynamodb from 'aws-cdk-lib/aws-dynamodb'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Construct } from 'constructs'; import * as cdk from 'aws-cdk-lib'; export class HelloCdkStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', { removalPolicy: RemovalPolicy.DESTROY, }); new CfnOutput(this, 'APP-URL', { value: https://mycompany.myapp.com, description: 'The URL of the deployed application', exportName: 'myApp', }); ... } } ``` Para obter mais informações sobre a `CfnOutput` construção, consulte a [interface CfnOutputProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutputProps.html) na *Referência AWS Cloud Development Kit (AWS CDK) da API*. 1. Salve e confirme seu código. 1. Vá para [Como verificar se o URL da aplicação foi adicionado](#deploy-app-url-verify). **Para exibir o URL do aplicativo na ação “Implantar CloudFormation pilha”** 1. Se você estiver usando a ação **Deploy CloudFormation stack**, adicione uma saída à `Outputs` seção em seu CloudFormation modelo ou AWS SAM modelo com estas características: + A chave (também chamada de ID lógico) deve conter `appurl`, ou`endpointurl`, com ou sem um traço (`-`), sublinhado (`_`) ou espaço (` `). A string diferencia maiúsculas e minúsculas. + O valor deve ser o URL `http` ou `https` da aplicação implantada. Por exemplo, seu CloudFormation modelo pode ter a seguinte aparência: ``` "Outputs" : { "APP-URL" : { "Description" : "The URL of the deployed app", "Value" : "https://mycompany.myapp.com", "Export" : { "Name" : "My App" } } } ``` Para obter mais informações sobre CloudFormation saídas, consulte [Saídas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html) no Guia do *AWS CloudFormation usuário*. 1. Salve e confirme seu código. 1. Vá para [Como verificar se o URL da aplicação foi adicionado](#deploy-app-url-verify). **Para exibir o URL da aplicação em todas as outras ações** Se você estiver usando outra ação para implantar seu aplicativo, como a ação de criação ou **GitHub Ações**, faça o seguinte para que a URL do aplicativo seja exibida. 1. Defina uma variável de ambiente na seção `Inputs` ou `Steps` da ação no arquivo de definição do fluxo de trabalho. A variável deve ter estas características: + O `name` deve conter `appurl`, ou `endpointurl`, com ou sem um traço (`-`), sublinhado (`_`) ou espaço (` `). A string diferencia maiúsculas e minúsculas. + O valor deve ser o URL `http` ou `https` da aplicação implantada. Por exemplo, uma ação de criação pode ser semelhante a esta: ``` Build-action: Identifier: aws/build@v1 Inputs: Variables: - Name: APP-URL Value: https://mycompany.myapp.com ``` … Ou esta: ``` Actions: Build: Identifier: aws/build@v1 Configuration: Steps: - Run: APP-URL=https://mycompany.myapp.com ``` Para ter mais informações sobre definição de variáveis de ambiente, consulte [Definição de uma variável](workflows-working-with-variables-define-input.md). 1. Exporte a variável. Por exemplo, sua ação de criação pode ser semelhante a esta: ``` Build-action: ... Outputs: Variables: - APP-URL ``` Para ter informações sobre exportação de variáveis, consulte [Exportação de uma variável para que outras ações possam usá-la](workflows-working-with-variables-export-input.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. 1. Vá para [Como verificar se o URL da aplicação foi adicionado](#deploy-app-url-verify). **Como verificar se o URL da aplicação foi adicionado** + Inicie a execução de um fluxo de trabalho, caso ele não tenha sido iniciado automaticamente. A nova execução deve ter o URL da aplicação exibido como um link clicável no diagrama de fluxo de trabalho. Para ter mais informações sobre como iniciar execuções, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md). # Remoção de um destino de implantação Você pode remover um destino de implantação, como um cluster ou CloudFormation pilha do Amazon ECS, da página de **destinos de implantação** no CodeCatalyst console. **Importante** Quando você remove um destino de implantação, ele é removido do CodeCatalyst console, mas permanece disponível no AWS serviço que o hospeda (se ainda existir). Considere remover um alvo de implantação se o alvo estiver obsoleto. CodeCatalyst Os destinos podem ficar obsoletos se: + Você excluir o fluxo de trabalho implantado no destino. + Você alterar a pilha ou o cluster no qual está implantando. + Você excluiu a pilha ou o cluster do serviço Amazon ECS CloudFormation ou do Amazon ECS no AWS console. **Para remover um destino de implantação** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, selecione **CI/CD** e **Ambientes**. 1. Escolha o nome do ambiente que contém o destino de implantação que você deseja remover. Para ter informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md). 1. Escolha a guia **Destinos de implantação**. 1. Marque a caixa de opção ao lado do destino de implantação que você deseja remover. 1. Escolha **Remover **. O destino é removido da página. # Rastreamento do status de implantação por confirmação A qualquer momento do ciclo de vida do desenvolvimento, é importante conhecer o status de implantação de confirmações específicas, como correções de bugs, novos recursos ou outras mudanças impactantes. Pense nos seguintes cenários nos quais o recurso de rastreamento do status de implantação é útil para as equipes de desenvolvimento: + Como desenvolvedor, você fez uma correção para solucionar um bug e deseja relatar o status da sua implantação nos ambientes de implantação da sua equipe. + Como gerente de lançamento, você deseja visualizar uma lista de confirmações implantadas para rastrear e relatar o status de implantação. CodeCatalyst fornece uma visualização que você pode usar para determinar rapidamente onde confirmações ou alterações individuais foram implantadas e em qual ambiente. Essa visualização inclui: + Uma lista de confirmações. + O status das implantações que incluem as confirmações. + Os ambientes em que as confirmações são implantadas com sucesso. + O status de todos os testes executados em relação aos commits em seu CI/CD fluxo de trabalho. O procedimento a seguir detalha como navegar até essa visualização e usá-la para rastrear alterações em seu projeto. **nota** O rastreamento do status de implantação por confirmação só é compatível com [CodeCatalyst repositórios.](source.md) Você não pode usar esse recurso com um [GitHub repositório, repositório Bitbucket ou GitLab repositório de projetos](extensions.md). **Para rastrear o status de implantação por confirmação** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, selecione **CI/CD** e **Alterar rastreamento**. 1. Nas duas listas suspensas na parte superior do painel principal, escolha o repositório de origem e a ramificação que contêm os commits cujo status de lançamento você deseja visualizar. 1. Selecione **Visualizar alterações**. Uma lista de confirmações é exibida. Para cada confirmação, é possível visualizar o seguinte: + Confirme informações, como ID, autor, mensagem e quando foram confirmadas. Para obter mais informações, consulte [Armazene e colabore no código com repositórios de origem no CodeCatalystArmazenamento e colaboração no código com repositórios de origem](source.md). + O status das implantações em cada ambiente. Para obter mais informações, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md). + Resultados do teste e da cobertura do código. Para obter mais informações, consulte [Teste com fluxos de trabalhoTeste com fluxos de trabalho](test-workflow-actions.md). **nota** Os resultados da Análise de composição de software (SCA) não são exibidos. 1. (Opcional) Para visualizar mais informações sobre as alterações relacionadas a uma confirmação específica, incluindo a implantação mais recente e informações detalhadas sobre a cobertura do código e o teste de unidade, selecione **Visualizar detalhes** para essa confirmação. # Visualização dos logs de implantação Você pode visualizar registros relacionados a ações de implantação específicas para solucionar problemas na Amazon CodeCatalyst. Você pode visualizar os logs em um [fluxo de trabalho](workflow.md) ou um [ambiente](deploy-environments.md). **Para visualizar os logs de uma ação de implantação em um fluxo de trabalho** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Selecione **Execuções**. 1. Escolha a execução do fluxo de trabalho que implantou a aplicação. 1. No diagrama do fluxo de trabalho, escolha a ação cujos logs você deseja exibir. 1. Escolha a guia **Logs** e expanda as seções para revelar as mensagens de log. 1. Para ver mais registros, escolha a guia **Resumo** e, em seguida, escolha **Exibir em CloudFormation** (se estiver disponível) para ver mais registros lá. Talvez seja necessário fazer login na AWS. **Para visualizar os logs de uma ação de implantação em um ambiente** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, selecione **CI/CD** e **Ambientes**. 1. Escolha o ambiente no qual a aplicação foi implantada. 1. Em **Atividade de implantação**, encontre a coluna **ID de execução do fluxo de trabalho** e escolha a execução do fluxo de trabalho que implantou sua pilha. 1. No diagrama do fluxo de trabalho, escolha a ação cujos logs você deseja exibir. 1. Escolha a guia **Logs** e expanda as seções para revelar as mensagens de log. 1. Para ver mais registros, escolha a guia **Resumo** e, em seguida, escolha **Exibir em CloudFormation** (se estiver disponível) para ver mais registros lá. Talvez seja necessário fazer login na AWS. # Visualizar informações de implantação Você pode ver as seguintes informações sobre uma implantação na Amazon CodeCatalyst: + Atividade de implantação, incluindo o status da implantação, a hora de início, a hora de término, o histórico e a duração dos eventos. + Nome da pilha Região da AWS, horário da última atualização e fluxos de trabalho associados. + Confirmações e solicitações pull. + Informações específicas da ação, por exemplo, CloudFormation eventos e resultados. Você pode visualizar as informações de implantação em um [fluxo de trabalho](workflow.md), um [ambiente](deploy-environments.md) ou uma [ação](workflows-concepts.md#workflows-concepts-actions) de fluxo de trabalho. **Para visualizar as informações de implantação em um fluxo de trabalho** + Acesse a execução do fluxo de trabalho que implantou a aplicação. Para instruções, consulte [Visualização do status e detalhes de execução do fluxo de trabalho](workflows-view-run.md). **Para visualizar as informações de implantação em um ambiente** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, selecione **CI/CD** e **Ambientes**. 1. Escolha o ambiente em que sua pilha foi implantada, por exemplo, `Production`. 1. Selecione **Atividade de implantação** para visualizar o histórico de implantação de suas pilhas, o status das implantações (por exemplo, **SUCCEEDED** ou **FAILED**) e outras informações relacionadas à implantação. 1. Selecione **Destino de implantação** para visualizar informações sobre as pilhas, clusters ou outros destinos implantados no ambiente. Você pode visualizar informações como nome da pilha, região, provedor e identificador. **Para visualizar as informações de implantação em uma ação** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. No diagrama do fluxo de trabalho, escolha a ação do fluxo de trabalho que implantou a aplicação. Por exemplo, você pode escolher **DeployCloudFormationStack**. 1. Revise o conteúdo no painel direito para ter informações de implantação específicas da ação. # Criação de um fluxo de trabalho *Fluxo de trabalho* é um procedimento automatizado que descreve como criar, testar e implantar o código como parte de um sistema de integração contínua e entrega contínua (CI/CD). Um fluxo de trabalho define uma série de etapas ou *ações* a serem realizadas durante a execução de um fluxo de trabalho. Um fluxo de trabalho também define os eventos, ou *gatilhos*, que fazem com que o fluxo de trabalho seja iniciado. Para configurar um fluxo de trabalho, você cria um *arquivo de definição de fluxo* de trabalho usando o [editor visual ou YAML](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors) do CodeCatalyst console. **dica** Para ver rapidamente como usar fluxos de trabalho em um projeto, [crie um projeto com um esquema](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template). Cada esquema implanta um fluxo de trabalho funcional que você pode revisar, executar e experimentar. Use o procedimento a seguir para criar um fluxo de trabalho em CodeCatalyst. O fluxo de trabalho será armazenado como um arquivo YAML em uma pasta `~/.codecatalyst/workflows/` no repositório de origem escolhido. Você também pode armazenar o fluxo de trabalho em uma subpasta de `~/.codecatalyst/workflows/` ou colocando o nome da pasta antes do nome do arquivo do fluxo de trabalho ao confirmá-lo. Para ter mais informações, consulte as instruções a seguir. Para obter mais informações sobre fluxos de trabalho, consulte [Compilação, teste e implantação com fluxos de trabalhoCompilação, teste e implantação com fluxos de trabalho](workflow.md). ------ #### [ Visual ] **Como criar um fluxo de trabalho usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho**. A caixa de diálogo **Criar fluxo de trabalho** é exibida. 1. No campo **Repositório de origem**, selecione um repositório de origem no qual o arquivo de definição do fluxo de trabalho residirá. Se não existir nenhum repositório de origem, [crie um](source-repositories-create.md). 1. No campo **Ramificação**, selecione uma ramificação na qual o arquivo de definição do fluxo de trabalho residirá. 1. Escolha **Criar**. A Amazon CodeCatalyst salva as informações do repositório e da filial na memória, mas o fluxo de trabalho ainda não está comprometido. 1. Selecione **Visual**. 1. Crie o fluxo de trabalho: 1. (Opcional) No diagrama do fluxo de trabalho, selecione a caixa **Origem** e **Gatilhos**. Um painel **Gatilhos** é exibido. Selecione **Adicionar gatilho** para adicionar um gatilho. Para obter mais informações, consulte [Adição de gatilhos aos fluxos de trabalho](workflows-add-trigger-add.md). 1. Selecione **\$1 Ações** (canto superior esquerdo). O catálogo de **ações** é exibido. 1. Selecione o sinal de adição (**\$1**) dentro de uma ação para adicioná-la ao fluxo de trabalho. Use o painel à direita para configurar a ação. Para obter mais informações, consulte [Adição de uma ação a um fluxo de trabalho](workflows-add-action.md). 1. (Opcional) Selecione **Propriedades do fluxo de trabalho** (canto superior direito). Um painel de **Propriedades do fluxo de trabalho** é exibido. Configure o nome do fluxo de trabalho, o modo de execução e a computação. Para obter mais informações, consulte [Configurar o comportamento de enfileiramento das execuções](workflows-configure-runs.md) e [Configuração de imagens de computação e runtime](workflows-working-compute.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar** e, na caixa de diálogo **Confirmar fluxo de trabalho**, faça o seguinte: 1. Em **Nome do arquivo do fluxo de trabalho**, deixe o nome padrão ou digite o seu próprio. O arquivo será armazenado como uma pasta `~/.codecatalyst/workflows/` no repositório de origem e ramificação selecionados. Coloque uma pasta ou uma subpasta antes do nome do arquivo. Exemplos: + A especificação de `my-workflow` (sem pasta) armazena o arquivo como `~/.codecatalyst/workflows/my-workflow.yaml` + A especificação de `folder/subfolder/my-workflow` armazena o arquivo como `~/.codecatalyst/workflows/folder/subfolder/my-workflow.yaml` 1. Em **Confirmar mensagem**, deixe a mensagem padrão ou insira a sua. 1. Em **Repositório** e **Ramificação**, selecione o repositório e a ramificação de origem para o arquivo de definição do fluxo de trabalho. Esses campos devem ser definidos para o repositório e a ramificação especificados anteriormente na caixa de diálogo **Criar fluxo de trabalho**. Se desejar, altere o repositório e a ramificação agora. **nota** Depois de confirmar o arquivo de definição de fluxo de trabalho, ele não poderá ser associado a outro repositório ou ramificação, portanto, escolha-os com cuidado. 1. Selecione **Confirmar** para confirmar o arquivo de definição do fluxo de trabalho. ------ #### [ YAML ] **Como criar um fluxo de trabalho usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho**. A caixa de diálogo **Criar fluxo de trabalho** é exibida. 1. No campo **Repositório de origem**, selecione um repositório de origem no qual o arquivo de definição do fluxo de trabalho residirá. Se não existir nenhum repositório de origem, [crie um](source-repositories-create.md). 1. No campo **Ramificação**, selecione uma ramificação na qual o arquivo de definição do fluxo de trabalho residirá. 1. Escolha **Criar**. A Amazon CodeCatalyst salva as informações do repositório e da filial na memória, mas o fluxo de trabalho ainda não está comprometido. 1. Selecione **YAML**. 1. Crie o fluxo de trabalho: 1. (Opcional) Adicione um gatilho ao código YAML. Para obter mais informações, consulte [Adição de gatilhos aos fluxos de trabalho](workflows-add-trigger-add.md). 1. Selecione **\$1 Ações** (canto superior esquerdo). O catálogo de **ações** é exibido. 1. Selecione o sinal de adição (**\$1**) dentro de uma ação para adicioná-la ao fluxo de trabalho. Use o painel à direita para configurar a ação. Para obter mais informações, consulte [Adição de uma ação a um fluxo de trabalho](workflows-add-action.md). 1. (Opcional) Selecione **Propriedades do fluxo de trabalho** (canto superior direito). Um painel de **Propriedades do fluxo de trabalho** é exibido. Configure o nome do fluxo de trabalho, o modo de execução e a computação. Para obter mais informações, consulte [Configurar o comportamento de enfileiramento das execuções](workflows-configure-runs.md) e [Configuração de imagens de computação e runtime](workflows-working-compute.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar** e, na caixa de diálogo **Confirmar fluxo de trabalho**, faça o seguinte: 1. Em **Nome do arquivo do fluxo de trabalho**, deixe o nome padrão ou digite o seu próprio. O arquivo será armazenado como uma pasta `~/.codecatalyst/workflows/` no repositório de origem e ramificação selecionados. Coloque uma pasta ou uma subpasta antes do nome do arquivo. Exemplos: + A especificação de `my-workflow` (sem pasta) armazena o arquivo como `~/.codecatalyst/workflows/my-workflow.yaml` + A especificação de `folder/subfolder/my-workflow` armazena o arquivo como `~/.codecatalyst/workflows/folder/subfolder/my-workflow.yaml` 1. Em **Confirmar mensagem**, deixe a mensagem padrão ou insira a sua. 1. Em **Repositório** e **Ramificação**, selecione o repositório e a ramificação de origem para o arquivo de definição do fluxo de trabalho. Esses campos devem ser definidos para o repositório e a ramificação especificados anteriormente na caixa de diálogo **Criar fluxo de trabalho**. Se desejar, altere o repositório e a ramificação agora. **nota** Depois de confirmar o arquivo de definição de fluxo de trabalho, ele não poderá ser associado a outro repositório ou ramificação, portanto, escolha-os com cuidado. 1. Selecione **Confirmar** para confirmar o arquivo de definição do fluxo de trabalho. ------ # Executar um fluxo de trabalho *Execução* é uma iteração única de um fluxo de trabalho. Durante uma execução, CodeCatalyst executa as ações definidas no arquivo de configuração do fluxo de trabalho e gera os registros, artefatos e variáveis associados. Você pode iniciar uma execução manual ou automaticamente por meio de um *gatilho de fluxo de trabalho*. Um exemplo de gatilho de fluxo de trabalho pode ser um desenvolvedor de software enviando uma confirmação para sua ramificação principal. Você também pode parar manualmente a execução de um fluxo de trabalho em andamento, caso a tenha iniciado por engano. Se várias execuções de fluxo de trabalho forem iniciadas ao mesmo tempo, você poderá configurar como deseja que essas execuções sejam enfileiradas. Use o comportamento de enfileiramento padrão, em que as execuções são enfileiradas uma após a outra na ordem em que foram iniciadas, ou você pode fazer com que uma execução posterior substitua (ou “assuma o controle”) de uma anterior para acelerar sua execução durante todo o processo. Configurar as execuções do fluxo de trabalho para que ocorram paralelamente, de forma que nenhuma execução espere por outra, também é possível. Depois de iniciar a execução de um fluxo de trabalho, manual ou automaticamente, você pode ver o status da execução e outros detalhes. Por exemplo, você pode ver quando ela foi iniciada, por quem ela foi iniciada e se ainda está em execução. **Topics** + [ # Iniciar um fluxo de trabalho executado manualmente ](workflows-manually-start.md) + [ # Início da execução automática de um fluxo de trabalho usando gatilhos ](workflows-add-trigger.md) + [ # Configurar gatilhos somente manuais ](workflows-manual-only.md) + [ # Parada de uma execução de fluxo de trabalho ](workflows-stop.md) + [ # Bloquear uma execução de fluxo de trabalho ](workflows-gates.md) + [ # Solicitar aprovações em execuções de fluxo de trabalho ](workflows-approval.md) + [ # Configurar o comportamento de enfileiramento das execuções ](workflows-configure-runs.md) + [ # Armazenar arquivos em cache entre execuções de fluxo de trabalho ](workflows-caching.md) + [ # Visualização do status e detalhes de execução do fluxo de trabalho ](workflows-view-run.md) # Iniciar um fluxo de trabalho executado manualmente Na Amazon CodeCatalyst, você pode iniciar um fluxo de trabalho executado manualmente a partir do CodeCatalyst console. Para ter mais informações sobre execuções de fluxos de trabalho, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). **nota** Você também pode iniciar a execução de um fluxo de trabalho manualmente ao [configurar um gatilho](workflows-add-trigger.md). **Como iniciar um fluxo de trabalho executado manualmente** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Executar**. # Início da execução automática de um fluxo de trabalho usando gatilhos Você pode iniciar a execução automática de um CodeCatalyst fluxo de trabalho da Amazon com um gatilho de fluxo de trabalho. Um *gatilho de fluxo de trabalho*, ou simplesmente um *gatilho*, permite que você inicie a execução automática de um fluxo de trabalho quando determinados eventos ocorrerem, como um envio de código. Talvez você queira configurar gatilhos para liberar seus desenvolvedores de software da necessidade de iniciar execuções de fluxo de trabalho manualmente por meio do CodeCatalyst console. É possível usar três tipos de gatilho: + **Envio**: um gatilho de envio de código faz com que a execução de um fluxo de trabalho seja iniciada sempre que uma confirmação é enviada. + **Solicitação pull**: um gatilho de solicitação pull faz com que a execução de um fluxo de trabalho seja iniciada sempre que uma solicitação pull é criada, revisada ou fechada. + **Programação**: um gatilho de programação faz com que a execução de um fluxo de trabalho comece em uma programação definida por você. Pense em usar um gatilho de programação para executar compilações noturnas do software para que a versão mais recente esteja pronta para os desenvolvedores de software trabalharem na manhã seguinte. É possível usar gatilhos de envio, solicitação pull e programação de maneira independente ou combinados no mesmo fluxo de trabalho. Os gatilhos são opcionais. Se você não configurar nenhum, só poderá iniciar um fluxo de trabalho manualmente. **dica** Para ver um gatilho em ação, inicie um projeto com um esquema. A maioria dos esquemas contém um fluxo de trabalho com um gatilho. Procure a propriedade `Trigger` no arquivo de definição do fluxo de trabalho do esquema. Para obter mais informações sobre esquemas, consulte [Criar um projeto com um esquema](projects-create.md#projects-create-console-template). **Topics** + [ # Exemplos: gatilhos em fluxos de trabalho ](workflows-add-trigger-examples.md) + [ # Diretrizes para o uso de gatilhos e ramificações ](workflows-add-trigger-considerations.md) + [ # Adição de gatilhos aos fluxos de trabalho ](workflows-add-trigger-add.md) # Exemplos: gatilhos em fluxos de trabalho Os exemplos a seguir mostram como adicionar diferentes tipos de gatilhos em um arquivo de definição de CodeCatalyst fluxo de trabalho da Amazon. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). **Topics** + [ ## Exemplo: um simples gatilho de envio de código ](#workflows-add-trigger-examples-push-simple) + [ ## Exemplo: um gatilho simples “enviar para principal” ](#workflows-add-trigger-examples-push-main) + [ ## Exemplo: um simples gatilho de solicitação pull ](#workflows-add-trigger-examples-pull-simple) + [ ## Exemplo: um gatilho de programação simples ](#workflows-add-trigger-examples-schedule-simple) + [ ## Exemplo: um gatilho com uma programação e ramificações ](#workflows-add-trigger-examples-schedule-branches) + [ ## Exemplo: um gatilho com uma programação, um envio e ramificações ](#workflows-add-trigger-examples-schedule-push-branches) + [ ## Exemplo: um gatilho com uma extração e ramificações ](#workflows-add-trigger-examples-pull-branches) + [ ## Exemplo: um gatilho com uma extração, ramificações e um evento “FECHADO” ](#workflows-add-trigger-examples-push-pull-close) + [ ## Exemplo: um gatilho com um envio, ramificações e arquivos ](#workflows-add-trigger-examples-push-multi) + [ ## Exemplo: um gatilho manual ](#workflows-add-trigger-examples-manual) + [ ## Exemplo: acionadores em uma configuração de vários fluxos de trabalho CI/CD ](#workflows-add-trigger-usecases) ## Exemplo: um simples gatilho de envio de código O exemplo a seguir mostra um gatilho que inicia a execução de um fluxo de trabalho sempre que o código é enviado para *qualquer* ramificação no seu repositório de origem. Quando esse gatilho é ativado, CodeCatalyst inicia a execução de um fluxo de trabalho usando os arquivos na ramificação *para* a qual você está enviando (ou seja, a ramificação de destino). Por exemplo, se você enviar um commit para`main`, CodeCatalyst iniciará a execução de um fluxo de trabalho usando o arquivo de definição do fluxo de trabalho e outros arquivos de origem ativados. `main` Como outro exemplo, se você enviar um commit para`feature-branch-123`, CodeCatalyst iniciará a execução de um fluxo de trabalho usando o arquivo de definição do fluxo de trabalho e outros arquivos de origem ativados. `feature-branch-123` ``` Triggers: - Type: PUSH ``` **nota** Se você quiser que a execução de um fluxo de trabalho inicie somente quando enviar para `main`, consulte [Exemplo: um gatilho simples “enviar para principal”](#workflows-add-trigger-examples-push-main). ## Exemplo: um gatilho simples “enviar para principal” O exemplo a seguir mostra um gatilho que inicia a execução de um fluxo de trabalho sempre que o código é enviado para a ramificação `main` – e *apenas* a ramificação `main` – no seu repositório de origem. ``` Triggers: - Type: PUSH Branches: - main ``` ## Exemplo: um simples gatilho de solicitação pull O exemplo a seguir mostra um gatilho que inicia a execução de um fluxo de trabalho sempre que uma solicitação pull é criada ou revisada no seu repositório de origem. Quando esse gatilho é ativado, CodeCatalyst inicia a execução de um fluxo de trabalho usando o arquivo de definição do fluxo de trabalho e outros arquivos de origem na ramificação da qual você está *extraindo* (ou seja, a ramificação de origem). Por exemplo, se você criar uma pull request com uma ramificação de origem chamada `feature-123` e uma ramificação de destino chamada`main`, CodeCatalyst iniciará a execução de um fluxo de trabalho usando o arquivo de definição do fluxo de trabalho e outros arquivos de origem ativados. `feature-123` ``` Triggers: - Type: PULLREQUEST Events: - OPEN - REVISION ``` ## Exemplo: um gatilho de programação simples O exemplo a seguir mostra um gatilho que inicia a execução de um fluxo de trabalho à meia-noite (UTC\$10) de segunda a sexta. Quando esse gatilho é ativado, CodeCatalyst inicia uma única execução de fluxo de trabalho para cada ramificação em seu repositório de origem que contém um arquivo de definição de fluxo de trabalho com esse gatilho. Por exemplo, se você tiver três ramificações em seu repositório de origem,,, `main` `release-v1``feature-123`, e cada uma dessas ramificações contiver um arquivo de definição de fluxo de trabalho com o gatilho a seguir, CodeCatalyst iniciará três execuções de fluxo de trabalho: uma usando os arquivos em`main`, outra usando os arquivos em `release-v1` e outra usando os arquivos em`feature-123`. ``` Triggers: - Type: SCHEDULE Expression: "0 0 ? * MON-FRI *" ``` Para ver mais exemplos de expressões cron que podem ser usadas na propriedade `Expression`, consulte [Expression](workflow-reference.md#workflow.triggers.expression). ## Exemplo: um gatilho com uma programação e ramificações O exemplo a seguir mostra um gatilho que inicia uma execução de fluxo de trabalho às 18h15 (UTC\$10) todos os dias. Quando esse gatilho é ativado, CodeCatalyst inicia a execução de um fluxo de trabalho usando os arquivos na `main` ramificação e inicia execuções adicionais para cada ramificação que começa com`release-`. Por exemplo, se você tiver ramificações chamadas`main`, `release-v1``bugfix-1`, e `bugfix-2` no seu repositório de origem, CodeCatalyst iniciará duas execuções de fluxo de trabalho: uma usando os arquivos em `main` e outra usando os arquivos em`release-v1`. Ele *não* inicia as execuções do fluxo de trabalho para as ramificações `bugfix-1` e `bugfix-1`. ``` Triggers: - Type: SCHEDULE Expression: "15 18 * * ? *" Branches: - main - release\-.* ``` Para ver mais exemplos de expressões cron que podem ser usadas na propriedade `Expression`, consulte [Expression](workflow-reference.md#workflow.triggers.expression). ## Exemplo: um gatilho com uma programação, um envio e ramificações O exemplo a seguir mostra um gatilho que inicia a execução de um fluxo de trabalho à meia-noite (UTC\$10) todos os dias e sempre que o código é enviado para a ramificação `main`. Neste exemplo: + A execução do fluxo de trabalho começa à meia-noite todos os dias. A execução do fluxo de trabalho usa o arquivo de definição do fluxo de trabalho e outros arquivos de origem na ramificação `main`. + A execução do fluxo de trabalho também é iniciada sempre que você envia uma confirmação para a ramificação `main`. A execução do fluxo de trabalho usa o arquivo de definição do fluxo de trabalho e outros arquivos de origem na ramificação de destino (`main`). ``` Triggers: - Type: SCHEDULE Expression: "0 0 * * ? *" Branches: - main - Type: PUSH Branches: - main ``` Para ver mais exemplos de expressões cron que podem ser usadas na propriedade `Expression`, consulte [Expression](workflow-reference.md#workflow.triggers.expression). ## Exemplo: um gatilho com uma extração e ramificações O exemplo a seguir mostra um gatilho que inicia a execução de um fluxo de trabalho sempre que alguém abre ou modifica uma solicitação pull com uma ramificação de destino chamada `main`. Embora a ramificação especificada na configuração `Triggers` seja `main`, a execução do fluxo de trabalho usará o arquivo de definição do fluxo de trabalho e outros arquivos de origem na ramificação de *origem* (que é a ramificação *da* qual você está extraindo). ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` ## Exemplo: um gatilho com uma extração, ramificações e um evento “FECHADO” O exemplo a seguir mostra um gatilho que inicia uma execução de fluxo de trabalho sempre que uma solicitação pull é fechada em uma ramificação que começa com `main`. Neste exemplo: + Quando você fecha uma solicitação pull com uma ramificação de destino que começa com `main`, a execução de um fluxo de trabalho é iniciada automaticamente usando o arquivo de definição do fluxo de trabalho e outros arquivos de origem na ramificação de origem (agora fechada). + Se você configurou seu repositório de origem para excluir ramificações automaticamente após a mesclagem de uma solicitação pull, essas ramificações nunca terão a chance de entrar no estado `CLOSED`. Isso significa que as ramificações mescladas não ativarão o gatilho `CLOSED` da solicitação pull. A única maneira de ativar o gatilho `CLOSED` nesse cenário é fechar a solicitação pull sem mesclá-la. ``` Triggers: - Type: PULLREQUEST Branches: - main.* Events: - CLOSED ``` ## Exemplo: um gatilho com um envio, ramificações e arquivos O exemplo a seguir mostra um gatilho que inicia a execução de um fluxo de trabalho sempre que uma alteração é feita no arquivo `filename.txt`, ou em qualquer arquivo no diretório `src`, na ramificação `main`. Quando esse gatilho é ativado, CodeCatalyst inicia a execução de um fluxo de trabalho usando o arquivo de definição do fluxo de trabalho e outros arquivos de origem na `main` ramificação. ``` Triggers: - Type: PUSH Branches: - main FilesChanged: - filename.txt - src\/.* ``` ## Exemplo: um gatilho manual Para configurar um gatilho manual, omita a seção `Triggers` do arquivo de definição do fluxo de trabalho. Sem essa seção, os usuários são forçados a iniciar o fluxo de trabalho manualmente escolhendo o botão **Executar** no CodeCatalyst console. Para obter mais informações, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md). ## Exemplo: acionadores em uma configuração de vários fluxos de trabalho CI/CD Este exemplo descreve como configurar gatilhos quando você deseja usar CodeCatalyst fluxos de trabalho separados da Amazon para integração contínua (CI) e implantação contínua (CD). Nesse cenário, você configura dois fluxos de trabalho: + um **fluxo de trabalho de CI**: esse fluxo de trabalho cria e testa a aplicação quando uma solicitação pull é criada ou revisada. + um **fluxo de trabalho de CD**: esse fluxo de trabalho compila e implanta a aplicação quando uma solicitação pull é mesclada. O arquivo de definição do **fluxo de trabalho de CI** seria semelhante a este: ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION Actions: BuildAction: instructions-for-building-the-app TestAction: instructions-for-test-the-app ``` O `Triggers` código indica que um fluxo de trabalho deve ser executado automaticamente sempre que um desenvolvedor de software cria uma pull request (ou [modifica uma](pull-requests-update.md)) solicitando a fusão de sua ramificação de recursos com a `main` ramificação. CodeCatalyst inicia a execução do fluxo de trabalho usando o código-fonte na ramificação de origem (que é a ramificação do recurso). O arquivo de definição do **fluxo de trabalho de CD** seria semelhante a este: ``` Triggers: - Type: PUSH Branches: - main Actions: BuildAction: instructions-for-building-the-app DeployAction: instructions-for-deploying-the-app ``` O `Triggers` código indica que o fluxo de trabalho deve ser iniciado automaticamente quando `main` ocorre uma mesclagem. CodeCatalyst inicia a execução do fluxo de trabalho usando o código-fonte na `main` ramificação. # Diretrizes para o uso de gatilhos e ramificações Esta seção descreve algumas das principais diretrizes ao configurar CodeCatalyst gatilhos da Amazon que incluem filiais. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + **Diretriz 1:** para os gatilhos de envio e solicitação pull, se você for especificar uma ramificação, deverá especificar a ramificação de destino (ou “para”) na configuração do gatilho. Nunca especifique a ramificação de origem (ou “de”). No exemplo a seguir, um envio de qualquer ramificação para `main` ativa o fluxo de trabalho. ``` Triggers: - Type: PUSH Branches: - main ``` No exemplo a seguir, uma solicitação pull de qualquer ramificação para `main` ativa o fluxo de trabalho. ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` + **Diretriz 2:** para gatilhos de envio, depois que o fluxo de trabalho for ativado, ele será executado usando o arquivo de definição do fluxo de trabalho e os arquivos de origem na ramificação de *destino*. + **Diretriz 3:** para gatilhos de solicitação pull, depois que o fluxo de trabalho for ativado, ele será executado usando o arquivo de definição de fluxo de trabalho e os arquivos de origem na ramificação de *origem* (mesmo que você tenha especificado a ramificação de destino na configuração do gatilho). + **Diretriz 4:** o mesmo gatilho em uma ramificação pode não ser executado em outra ramificação. Considere o gatilho de envio a seguir: ``` Triggers: - Type: PUSH Branches: - main ``` Se o arquivo de definição do fluxo de trabalho que contém esse gatilho existir em `main` e for clonado para `test`, o fluxo de trabalho nunca começará a usar automaticamente os arquivos em `test` (embora você possa iniciar o fluxo de trabalho *manualmente* para que ele use os arquivos em `test`). Revise a **Diretriz 2** para entender por que o fluxo de trabalho nunca será executado automaticamente usando os arquivos em `test`. Considere também o seguinte gatilho de solicitação pull: ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` Se o arquivo de definição do fluxo de trabalho contendo esse gatilho existir em `main`, o fluxo de trabalho nunca será executado usando os arquivos em `main`. (No entanto, se você criar uma ramificação `test` a partir de `main`, o fluxo de trabalho será executado usando os arquivos em `test`.) Revise a **Diretriz 3** para entender o porquê. # Adição de gatilhos aos fluxos de trabalho Use as instruções a seguir para adicionar um gatilho push, pull ou schedule ao seu CodeCatalyst fluxo de trabalho da Amazon. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). ------ #### [ Visual ] **Para adicionar um gatilho (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a caixa **Origem** e **Gatilhos**. 1. No painel de configuração, selecione **Adicionar gatilho**. 1. Na caixa de diálogo **Adicionar gatilho**, forneça as informações nos campos, da seguinte forma. **Tipo de gatilho** Especifique o tipo de gatilho. É possível usar um dos seguintes valores: + **Envio** (editor visual) ou `PUSH` (editor YAML) Um gatilho de envio inicia a execução de um fluxo de trabalho quando uma alteração é enviada para seu repositório de origem. A execução do fluxo de trabalho usará os arquivos na ramificação *para* a qual você está enviando (ou seja, a ramificação de destino). + **Solicitação pull** (editor visual) ou `PULLREQUEST` (editor YAML) Um gatilho de solicitação pull inicia a execução de um fluxo de trabalho quando uma solicitação pull é aberta, atualizada ou fechada no seu repositório de origem. A execução do fluxo de trabalho usará os arquivos na ramificação *da* a qual você está extraindo (ou seja, a ramificação de origem). + **Programação** (editor visual) ou `SCHEDULE` (editor YAML) Um gatilho de programação inicia a execução do fluxo de trabalho em uma programação definida por uma expressão cron especificada por você. Uma execução de fluxo de trabalho separada será iniciada para cada ramificação em seu repositório de origem usando os arquivos da ramificação. (Para limitar as ramificações nas quais o gatilho é ativado, use o campo **Ramificações** (editor visual) ou a propriedade `Branches` (editor YAML).) Ao configurar um gatilho de programação, siga estas instruções: + Use apenas um gatilho de programação por fluxo de trabalho. + Se você definiu vários fluxos de trabalho em seu CodeCatalyst espaço, recomendamos que você agende no máximo 10 deles para começarem simultaneamente. + Certifique-se de configurar a expressão cron do gatilho com tempo adequado entre as execuções. Para obter mais informações, consulte [Expression](workflow-reference.md#workflow.triggers.expression). Para obter exemplos, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). **Eventos para solicitação pull** Esse campo só aparece se você selecionou o tipo de gatilho de **solicitação pull**. Especifique o tipo de eventos de solicitação pull que iniciarão a execução de um fluxo de trabalho. Os valores válidos são os seguintes: + **A solicitação pull é criada** (editor visual) ou `OPEN` (editor YAML) A execução do fluxo de trabalho é iniciada quando uma solicitação pull é criada. + **A solicitação pull é fechada** (editor visual) ou `CLOSED` (editor YAML) A execução do fluxo de trabalho é iniciada quando uma solicitação pull é fechada. O comportamento do evento `CLOSED` é complicado e é melhor compreendido por meio de um exemplo. Consulte [Exemplo: um gatilho com uma extração, ramificações e um evento “FECHADO”](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close) para obter mais informações. + **Uma nova revisão é feita para solicitação pull** (editor visual) ou `REVISION` (editor YAML) A execução do fluxo de trabalho é iniciada quando uma revisão da solicitação pull é criada. A primeira revisão é criada quando a solicitação pull é criada. Depois disso, uma nova revisão é criada sempre que alguém envia uma nova confirmação para a ramificação de origem especificada na solicitação pull. Se você incluir o evento `REVISION` em seu gatilho de solicitação pull, poderá omitir o evento `OPEN`, pois `REVISION` é um superconjunto de `OPEN`. Você pode especificar vários eventos no mesmo gatilho de solicitação pull. Para obter exemplos, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). **Programação** Esse campo só aparece se você selecionou o tipo de gatilho **Programação**. Especifique a expressão cron que descreve quando você deseja que suas execuções de fluxo de trabalho programadas ocorram. As expressões Cron CodeCatalyst usam a seguinte sintaxe de seis campos, em que cada campo é separado por um espaço: *minutes* *hours* *days-of-month* *month* *days-of-week* *year* **Exemplos de expressões cron** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/workflows-add-trigger-add.html) Ao especificar expressões cron em CodeCatalyst, siga estas diretrizes: + Especifique uma única expressão cron por gatilho `SCHEDULE`. + Coloque a expressão cron entre aspas duplas (`"`) no editor YAML. + Especifique o horário em Tempo Universal Coordenado (UTC). Outros fusos horários não são suportados. + Configure pelo menos 30 minutos entre as execuções. Não há suporte para uma cadência mais rápida. + Especifique o *days-of-week* campo *days-of-month* ou, mas não ambos. Se você especificar um valor ou asterisco (`*`) em um dos campos, deverá usar um ponto de interrogação (`?`) no outro. O asterisco significa “tudo” e o ponto de interrogação significa “qualquer”. Para obter mais exemplos de expressões cron e informações sobre curingas como`?`,, e `*``L`, consulte a [referência de expressões Cron no Guia](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html) do usuário da *Amazon EventBridge *. As expressões Cron CodeCatalyst funcionam exatamente da mesma maneira. EventBridge Para ver exemplos de gatilhos de programação, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). **Ramificações** e **padrão de ramificação** (Optional) Especifique as ramificações em seu repositório de origem que o acionador monitora para saber quando iniciar a execução de um fluxo de trabalho. Você pode usar padrões regex para definir os nomes das ramificações. Por exemplo, use `main.*` para combinar todas as ramificações que começam com `main`. As ramificações a serem especificadas são diferentes dependendo do tipo de gatilho: + Para um gatilho de envio, especifique as ramificações *para* as quais você está enviando, ou seja, as ramificações de *destino*. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando os arquivos na ramificação correspondente. Exemplos: `main.*`, `mainline` + Para um gatilho de solicitação pull, especifique as ramificações *para* as quais você está enviando, ou seja, as ramificações de *destino*. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando o arquivo de definição do fluxo de trabalho e os arquivos de origem na ramificação de **origem** (*não* a ramificação correspondente). Exemplos: `main.*`, `mainline`, `v1\-.*` (corresponde às ramificações que começam com `v1-`) + Para um gatilho de programação, especifique as ramificações que contêm os arquivos que devem ser usados pela sua execução programada. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando o arquivo de definição do fluxo de trabalho e os arquivos de origem na ramificação correspondente. Exemplos: `main.*`, `version\-1\.0` **nota** Se você *não* especificar ramificações, o gatilho monitorará todas as ramificações em seu repositório de origem e iniciará a execução de um fluxo de trabalho usando o arquivo de definição do fluxo de trabalho e os arquivos de origem em: A ramificação *para* a qual você está enviando (para gatilhos de envio). Para obter mais informações, consulte [Exemplo: um simples gatilho de envio de código](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple). A ramificação *da* qual você está extraindo (para gatilhos de solicitação pull). Para obter mais informações, consulte [Exemplo: um simples gatilho de solicitação pull](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple). Todas as ramificações (para gatilhos de programação). Uma execução de fluxo de trabalho será iniciada por ramificação em seu repositório de origem. Para obter mais informações, consulte [Exemplo: um gatilho de programação simples](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple). Para ter mais informações sobre ramificações e gatilhos, consulte [Diretrizes para o uso de gatilhos e ramificações](workflows-add-trigger-considerations.md). Para obter mais exemplos, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). **Arquivos alterados** Esse campo só aparece se você selecionou o tipo de gatilho de **Envio** ou **Solicitação pull**. Especifique os arquivos ou pastas em seu repositório de origem que o acionador monitora para saber quando iniciar a execução de um fluxo de trabalho. Você pode usar expressões regulares para corresponder nomes ou caminhos de arquivos. Para obter exemplos, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar um gatilho (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Adicione uma seção de `Triggers` e propriedades subjacentes usando o exemplo a seguir como guia. Para obter mais informações, consulte o [Triggers](workflow-reference.md#triggers-reference) no [Definição do YAML do fluxo de trabalho](workflow-reference.md). Um gatilho de envio de código pode ter a seguinte aparência: ``` Triggers: - Type: PUSH Branches: - main ``` Um gatilho de solicitação pull pode ter a seguinte aparência: ``` Triggers: - Type: PULLREQUEST Branches: - main.* Events: - OPEN - REVISION - CLOSED ``` Um gatilho de programação pode ter a seguinte aparência: ``` Triggers: - Type: SCHEDULE Branches: - main.* # Run the workflow at 1:15 am (UTC+0) every Friday until the end of 2023 Expression: "15 1 ? * FRI 2022-2023" ``` Para ver mais exemplos de expressões cron que podem ser usadas na propriedade `Expression`, consulte [Expression](workflow-reference.md#workflow.triggers.expression). Para ver mais exemplos de gatilhos de envio, solicitação pull e programação, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Configurar gatilhos somente manuais Você pode limitar um fluxo de trabalho para que ele só possa ser iniciado manualmente pela sua equipe usando o botão **Executar** no CodeCatalyst console. Para configurar essa funcionalidade, remova a seção `Triggers` no arquivo de definição do fluxo de trabalho. A seção `Triggers` é incluída por padrão quando você cria um fluxo de trabalho, mas a seção é opcional e pode ser removida. Use as instruções a seguir para remover a seção `Triggers` no arquivo de definição do fluxo de trabalho para que o fluxo de trabalho só possa ser iniciado manualmente. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). Para ter mais informações sobre a execução de fluxos de trabalho, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). ------ #### [ Visual ] **Como remover a seção “Gatilhos” (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. Selecione a caixa **Origem** no diagrama do fluxo de trabalho. 1. Em **Gatilhos**, selecione o ícone da lixeira para remover a seção `Triggers` do fluxo de trabalho. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como remover a seção “Gatilhos” (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Encontre e remova a seção `Triggers`. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Parada de uma execução de fluxo de trabalho Use o procedimento a seguir para parar a execução de um fluxo de trabalho em andamento. Talvez você queira parar uma execução se ela tiver sido iniciada por acidente. Quando você interrompe a execução de um fluxo de trabalho, CodeCatalyst aguarda a conclusão das ações em andamento antes de marcar a execução como **Parada** no CodeCatalyst console. Todas as ações que não tiveram a chance de começar não serão iniciadas e serão marcadas como **Abandonadas**. **nota** Se uma execução estiver na fila (ou seja, não tiver ações em andamento), a execução será parada imediatamente. Para ter mais informações sobre execuções de fluxos de trabalho, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). **Como interromper uma execução de fluxo de trabalho** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Em **Fluxos de trabalho**, selecione **Execuções** e a execução em andamento na lista. 1. Escolha **Parar**. # Bloquear uma execução de fluxo de trabalho *Portão* é um componente do fluxo de trabalho que pode ser usado para impedir que a execução do fluxo de trabalho continue, a menos que determinadas condições sejam atendidas. Um exemplo de porta é a porta de **aprovação**, na qual os usuários devem enviar uma aprovação no CodeCatalyst console antes que a execução do fluxo de trabalho possa continuar. É possível adicionar portões entre sequências de ações a um fluxo de trabalho ou antes da primeira ação (executada imediatamente após o download da **Origem**). Também será possível adicionar portões após a última ação, se necessário. Para ter mais informações sobre execuções de fluxos de trabalho, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). **Topics** + [ ## Tipos de portões ](#workflows-gates-types) + [ ## Posso configurar um portão para ser executado paralelamente a outra ação? ](#workflows-approval-parallel) + [ ## Posso usar um portão para impedir o início da execução de um fluxo de trabalho? ](#workflows-gates-prevent) + [ ## Limitações de portões ](#workflows-gate-limitations) + [ # Adicionar um portão a um fluxo de trabalho ](workflows-gates-add.md) + [ # Sequenciar portões e ações ](workflows-gates-depends-on.md) + [ # Especificar a versão de um portão ](workflows-gates-version.md) ## Tipos de portões Atualmente, a Amazon CodeCatalyst oferece suporte a um tipo de portão: o portão de **aprovação**. Para obter mais informações, consulte [Solicitar aprovações em execuções de fluxo de trabalho](workflows-approval.md). ## Posso configurar um portão para ser executado paralelamente a outra ação? Não. Os portões só podem ser executados antes ou depois de uma ação. Para obter mais informações, consulte [Sequenciar portões e ações](workflows-gates-depends-on.md). ## Posso usar um portão para impedir o início da execução de um fluxo de trabalho? Sim, com qualificações. Você pode evitar que a execução de um fluxo de trabalho *execute tarefas*, o que é um pouco diferente de impedir que ela seja *iniciada*. Para evitar que um fluxo de trabalho execute tarefas, adicione um portão antes da primeira ação em um fluxo de trabalho. Nesse cenário, a execução de um fluxo de trabalho *será iniciada*, o que significa que ela baixará os arquivos do repositório de origem, mas será impedida de realizar tarefas até que o portão seja desbloqueado. **nota** Os fluxos de trabalho que são iniciados e depois são bloqueados por um portão ainda contam para a cota de *Número máximo de execuções simultâneas de fluxo de trabalho por espaço* e outras cotas. Para garantir que você não exceda as cotas de fluxo de trabalho, pense em usar um gatilho de fluxo de trabalho para iniciar condicionalmente um fluxo de trabalho em vez de usar um portão. Pense também em usar uma regra de aprovação de solicitação pull em vez de um portão. Para ter mais informações sobre cotas, gatilhos e regras de aprovação de solicitação pull, consulte [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md), [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md) e [Gerenciamento de requisitos para mesclar uma solicitação pull com regras de aprovação](source-pull-requests-approval-rules.md). ## Limitações de portões Os portões têm as seguintes limitações: + Portões não podem ser usados com o recurso de compartilhamento de computação. Para ter mais informações sobre esse recurso, consulte [Compartilhamento de computação entre ações](compute-sharing.md). + Portões não podem ser usados em grupos de ação. Para ter mais informações sobre os grupos de ações, consulte [Agrupar ações em grupos de ações](workflows-group-actions.md). # Adicionar um portão a um fluxo de trabalho No Amazon CodeCatalyst, você pode adicionar um portão a um fluxo de trabalho para impedir que ele continue, a menos que determinadas condições sejam atendidas. Use as instruções a seguir para adicionar um portão a um fluxo de trabalho. Para ter mais informações sobre portões, consulte [Bloquear uma execução de fluxo de trabalho](workflows-gates.md). **Como adicionar e configurar um portão** 1. Abra o console do CodeCatalyst em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Selecione **Editar**. 1. Selecione **Visual**. 1. No painel esquerdo, selecione **Portões**. 1. No catálogo de portões, pesquise um portão e escolha o sinal de adição (**\$1**) para adicioná-lo ao seu fluxo de trabalho. 1. Configure o portão. Selecione **Visual** para usar o editor visual ou **YAML** para usar o editor YAML. Para ter instruções detalhadas, consulte: + [Adição de um portão de “aprovação”](workflows-approval-add.md) 1. (Opcional) Selecione **Validar** para garantir que o código YAML seja válido. 1. Selecione **Confirmar** para confirmar suas alterações. # Sequenciar portões e ações No Amazon CodeCatalyst, você pode configurar um portão para ser executado antes ou depois de uma ação de fluxo de trabalho, grupo de ação ou portão. Por exemplo, é possível configurar um portão `Approval` para ser executado antes de uma ação `Deploy`. Nesse caso, a ação `Deploy` *depende* do portão `Approval`. Para configurar dependências entre portões e ações, configure a propriedade **Depende de** do portão ou ação. Para instruções, consulte [Configurar dependências entre ações](workflows-depends-on-set-up.md). As instruções referidas dizem respeito às *ações* do fluxo de trabalho, mas se aplicam igualmente aos portões. Para ter um exemplo de como configurar a propriedade **Depende de** com um portão, consulte [Exemplo: um portão de “aprovação”](workflows-approval-example.md). Para ter mais informações sobre portões, consulte [Bloquear uma execução de fluxo de trabalho](workflows-gates.md). Para ter mais informações sobre ações de fluxos de trabalho, consulte [Configuração de ações de fluxo de trabalho](workflows-actions.md). # Especificar a versão de um portão Por padrão, quando você adiciona um portão a um fluxo de trabalho, o CodeCatalyst adiciona a versão completa ao arquivo de definição do fluxo de trabalho usando o formato: `vmajor.minor.patch` Por exemplo: ``` My-Gate: Identifier: aws/approval@v1 ``` Você pode aumentar a versão para que o fluxo de trabalho use uma versão principal ou secundária específica do portão. Para instruções, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). O tópico referido diz respeito às ações do fluxo de trabalho, mas se aplica igualmente aos portões. Para ter mais informações sobre portões no CodeCatalyst, consulte [Bloquear uma execução de fluxo de trabalho](workflows-gates.md). # Solicitar aprovações em execuções de fluxo de trabalho É possível configurar a execução de um fluxo de trabalho para solicitar uma aprovação antes de continuar. Para fazer isso, adicione um [portão](workflows-gates.md) de **aprovação** ao fluxo de trabalho. Um *portão de aprovação* impede que um fluxo de trabalho continue até que um usuário ou conjunto de usuários envie uma ou mais aprovações no CodeCatalyst console. Depois que todas as aprovações são concedidas, o portão é “desbloqueado” e a execução do fluxo de trabalho pode ser retomada. Use um portão de **aprovação** no fluxo de trabalho para fornecer às equipes de desenvolvimento, de operações e de liderança a chance de revisar suas alterações antes que elas sejam implantadas em um público mais amplo. Para ter mais informações sobre execuções de fluxos de trabalho, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). **Topics** + [ ## Como faço para desbloquear um portão de aprovação? ](#workflows-approval-conditions) + [ ## Quando usar o portão de “Aprovação” ](#workflows-approval-when) + [ ## Quem pode fornecer uma aprovação? ](#workflows-approval-who) + [ ## Como faço para notificar os usuários de que uma aprovação é necessária? ](#workflows-approval-notify-methods) + [ ## Posso usar um portão de “aprovação” para impedir o início da execução de um fluxo de trabalho? ](#workflows-approval-prevent) + [ ## Como as aprovações de fluxo de trabalho funcionam com os modos de execução em fila, substituída e paralela? ](#workflows-approval-run-mode) + [ # Exemplo: um portão de “aprovação” ](workflows-approval-example.md) + [ # Adição de um portão de “aprovação” ](workflows-approval-add.md) + [ # Configuração de notificações de aprovação ](workflows-approval-notify.md) + [ # Aprovação ou rejeição da execução de um fluxo de trabalho ](workflows-approval-approve.md) + [ # Portão de “Aprovação” YAML ](approval-ref.md) ## Como faço para desbloquear um portão de aprovação? Para desbloquear um portão de **aprovação**, *todas* as seguintes condições devem ser atendidas: + **Condição 1**: o número necessário de aprovações deve ser enviado. O número necessário de aprovações é configurável e cada usuário pode enviar uma única aprovação. + **Condição 2**: todas as aprovações devem ser enviadas antes que o portão expire. O portão expira 14 dias após ser ativado. Esse período não é configurável. + **Condição 3**: ninguém deve rejeitar a execução do fluxo de trabalho. Uma única rejeição fará com que a execução do fluxo de trabalho falhe. + **Condição 4**: (aplicada apenas se você estiver usando o modo de execução substituído.) A execução não deve ser substituída por uma execução posterior. Para obter mais informações, consulte [Como as aprovações de fluxo de trabalho funcionam com os modos de execução em fila, substituída e paralela?](#workflows-approval-run-mode). Se alguma das condições não for atendida, CodeCatalyst interrompe o fluxo de trabalho e defina o status de execução como **Falha** (no caso das **Condições 1** a **3**) ou **Substituído** (no caso da **Condição 4**). ## Quando usar o portão de “Aprovação” Normalmente, você usaria um portão de **aprovação** em um fluxo de trabalho que implante aplicações e outros recursos em um servidor de produção ou em qualquer ambiente em que os padrões de qualidade devam ser validados. Ao colocar o portão antes da implantação para produção, você oferece aos revisores a chance de validar sua nova revisão de software antes que ela se torne disponível ao público. ## Quem pode fornecer uma aprovação? Qualquer usuário que seja membro do seu projeto e que tenha o perfil **colaborador** ou **administrador do projeto** pode fornecer uma aprovação. Os usuários com o perfil **administrador do espaço** que pertencem ao espaço do projeto também podem fornecer uma aprovação. **nota** Usuários com o perfil **revisor** não podem fornecer aprovações. ## Como faço para notificar os usuários de que uma aprovação é necessária? Para notificar os usuários de que uma aprovação é necessária, você deve: + CodeCatalyst Envie-lhes uma notificação do Slack. Para obter mais informações, consulte [Configuração de notificações de aprovação](workflows-approval-notify.md). + Acesse a página no CodeCatalyst console em que estão os botões **Aprovar** e **Rejeitar** e cole o URL dessa página em um aplicativo de e-mail ou mensagem endereçado aos aprovadores. Para ter mais informações sobre como acessar essa página, consulte [Aprovação ou rejeição da execução de um fluxo de trabalho](workflows-approval-approve.md). ## Posso usar um portão de “aprovação” para impedir o início da execução de um fluxo de trabalho? Sim, com qualificações. Para obter mais informações, consulte [Posso usar um portão para impedir o início da execução de um fluxo de trabalho?](workflows-gates.md#workflows-gates-prevent). ## Como as aprovações de fluxo de trabalho funcionam com os modos de execução em fila, substituída e paralela? Ao usar o modo de execução em fila, substituída ou paralela, o portão de **aprovação** funciona de forma semelhante às [ações](workflows-actions.md). Sugerimos a leitura das seções [Sobre o modo de execução em fila](workflows-configure-runs.md#workflows-configure-runs-queued), [Sobre o modo de execução substituída](workflows-configure-runs.md#workflows-configure-runs-superseded) e [Sobre o modo de execução paralela](workflows-configure-runs.md#workflows-configure-runs-parallel) para conhecer esses modos de execução. Depois de ter uma compreensão básica deles, retorne a esta seção para descobrir como esses modos de execução funcionam quando o portão de **aprovação** está presente. Quando o portão de **aprovação** está presente, as execuções são processadas da seguinte forma: + Se você estiver usando o [modo de execução em fila](workflows-configure-runs.md#workflows-configure-runs-queued), as execuções ficarão na fila atrás da execução que está aguardando aprovação no portão. Quando esse portão é desbloqueado (ou seja, todas as aprovações foram concedidas), a próxima execução na fila avança até o portão e aguarda as aprovações. Esse processo continua com as execuções em fila sendo processadas pelo portão. one-by-one [Figure 1](#figure-1-workflow-queued-run-mode-ma)ilustra esse processo. + Se você estiver usando o [modo de execução substituída](workflows-configure-runs.md#workflows-configure-runs-superseded), o comportamento será o mesmo que o modo de execução em fila, exceto que, em vez de as execuções se acumularem na fila do portão, as execuções mais recentes substituirão as anteriores. Não há filas, e qualquer execução que esteja aguardando aprovação no portão será cancelada e substituída por uma mais recente. [Figure 2](#figure-2-workflow-superseded-run-mode-ma) ilustra esse processo. + Se você estiver usando o [modo de execução paralela](workflows-configure-runs.md#workflows-configure-runs-parallel), as execuções começarão em paralelo e não formarão filas. Cada execução é processada pelo portão imediatamente, pois não há nenhuma execução à sua frente. [Figure 3](#figure-3-workflow-parallel-run-mode-ma) ilustra esse processo. **Figura 1**: “Modo de execução em fila” e um portão de **aprovação** ![\[Como um portão de “aprovação” funciona com o “modo de execução em fila”\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png) **Figura 2**: “Modo de execução substituída” e um portão de **aprovação** ![\[Como um portão de “aprovação” funciona com o “modo de execução substituída”\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png) **Figura 3**: “Modo de execução paralela” e um portão de **aprovação** ![\[Como um portão de “aprovação” funciona com o “modo de execução paralela”\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png) # Exemplo: um portão de “aprovação” O exemplo a seguir mostra como adicionar um portão de **aprovação** chamado `Approval_01` entre duas ações chamadas `Staging` e `Production`. A ação `Staging` é executada primeiro, o portão `Approval_01` depois e a ação `Production` por último. A ação `Production` só será executada se o portão `Approval_01` estiver desbloqueado. A propriedade `DependsOn` garante que as fases `Staging`, `Approval_01` e `Production` sejam executadas em ordem sequencial. Para ter mais informações sobre o portão de **aprovação**, consulte [Solicitar aprovações em execuções de fluxo de trabalho](workflows-approval.md). ``` Actions: Staging: # Deploy to a staging server Identifier: aws/ecs-deploy@v1 Configuration: ... Approval_01: Identifier: aws/approval@v1 DependsOn: - Staging Configuration: ApprovalsRequired: 2 Production: # Deploy to a production server Identifier: aws/ecs-deploy@v1 DependsOn: - Approval_01 Configuration: ... ``` # Adição de um portão de “aprovação” Para configurar seu fluxo de trabalho para exigir uma aprovação, adicione o portão de **aprovação** ao fluxo de trabalho. Use as instruções a seguir para adicionar um portão de **aprovação** ao seu fluxo de trabalho. Para ter mais informações sobre esse portão, consulte [Solicitar aprovações em execuções de fluxo de trabalho](workflows-approval.md). ------ #### [ Visual ] **Como adicionar um portão de “aprovação” a um fluxo de trabalho (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. No canto superior esquerdo, selecione **Portões**. 1. No catálogo **Portões**, em **Aprovação**, selecione o sinal de adição (**\$1**). 1. Selecione **Entradas** e, no campo **Depende de**, faça o seguinte. Especifique uma ação, um grupo de ação ou um portão que deve ser executado para que esse portão seja executado. Por padrão, quando você adiciona um portão a um fluxo de trabalho, o portão é configurado para depender da última ação no fluxo de trabalho. Se você remover essa propriedade, o portão não dependerá de nada e será executado primeiro, antes de outras ações. **nota** Um portão deve ser configurado para ser executado antes ou depois de uma ação, um grupo de ação ou um portão. Ele não pode ser configurado para ser executado em paralelo com outras ações, grupos de ação e portões. Para ter mais informações sobre a funcionalidade **Depende de**, consulte [Sequenciar portões e ações](workflows-gates-depends-on.md). 1. Escolha a guia **Configuração**. 1. No campo **Nome do portão**, faça o seguinte. Especifique o nome que você deseja dar ao portão. Todos os nomes de portão devem ser exclusivos no fluxo de trabalho. Os nomes de portão são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de portão. 1. (Opcional) No campo **Número de aprovações**, faça o seguinte. Especifique o número mínimo de aprovações necessárias para desbloquear o portão de **aprovação**. O mínimo é `1`. O máximo é `2`. Se for omitido, o padrão será `1`. **nota** Se você quiser omitir a propriedade `ApprovalsRequired`, remova a seção `Configuration` do portão do arquivo de definição do fluxo de trabalho. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar um portão de “aprovação” a um fluxo de trabalho (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Adicione uma seção de `Approval` e propriedades subjacentes usando o exemplo a seguir como guia. Para obter mais informações, consulte o [Portão de “Aprovação” YAML](approval-ref.md) no [Definição do YAML do fluxo de trabalho](workflow-reference.md). ``` Actions: MyApproval_01: Identifier: aws/approval@v1 DependsOn: - PreviousAction Configuration: ApprovalsRequired: 2 ``` Para obter outro exemplo, consulte [Exemplo: um portão de “aprovação”](workflows-approval-example.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Configuração de notificações de aprovação Você pode fazer com que o CodeCatalyst envie uma notificação para um canal do Slack informando aos usuários que a execução de um fluxo de trabalho exige aprovação. Os usuários veem a notificação e clicam no link dentro dela. O link os leva a uma página de aprovações do CodeCatalyst, onde eles podem aprovar ou rejeitar o fluxo de trabalho. Você também pode configurar notificações para informar aos usuários que um fluxo de trabalho foi aprovado, rejeitado ou que a solicitação de aprovação expirou. Use as instruções a seguir para configurar notificações do Slack. **Antes de começar** Certifique-se de ter adicionado um portão de **aprovação** ao seu fluxo de trabalho. Para obter mais informações, consulte [Adição de um portão de “aprovação”](workflows-approval-add.md). **Para enviar notificações de aprovação do fluxo de trabalho para um canal do Slack** 1. Configure o CodeCatalyst com o Slack. Para obter mais informações, consulte [Conceitos básicos das notificações do Slack](getting-started-notifications.md). 1. No projeto CodeCatalyst que contém o fluxo de trabalho que requer aprovação, ative as notificações, se elas ainda não estiverem ativadas. Como ativar notificações: 1. Navegue até seu projeto e, no painel de navegação, selecione **Configurações do projeto**. 1. Na parte superior, selecione **Notificações**. 1. Em **Eventos de notificação**, selecione **Editar notificações**. 1. Ative a **Aprovação do fluxo de trabalho pendente** e selecione um canal do Slack para o qual o CodeCatalyst enviará a notificação. 1. (Opcional) Ative notificações adicionais para alertar as pessoas sobre aprovações aprovadas, rejeitadas e expiradas. Você pode ativar a **Execução do fluxo de trabalho aprovada**, **Execução fluxo de trabalho rejeitada**, **Aprovação do fluxo de trabalho substituída** e **Tempo limite da aprovação do fluxo de trabalho**. Ao lado de cada notificação, selecione o canal do Slack para o qual o CodeCatalyst enviará a notificação. 1. Escolha **Salvar**. # Aprovação ou rejeição da execução de um fluxo de trabalho As execuções de fluxo de trabalho que incluam o portão de **aprovação** precisarão ser aprovadas ou rejeitadas. Os usuários podem fornecer sua aprovação ou rejeição em: + o CodeCatalyst console + link fornecido por um membro da equipe + notificação automática do Slack Depois que um usuário fornece sua aprovação ou rejeição, essa decisão não pode ser desfeita. **nota** Somente alguns usuários podem aprovar ou rejeitar a execução de um fluxo de trabalho. Para obter mais informações, consulte [Quem pode fornecer uma aprovação?](workflows-approval.md#workflows-approval-who). **Antes de começar** Certifique-se de ter adicionado um portão de **aprovação** ao seu fluxo de trabalho. Para obter mais informações, consulte [Adição de um portão de “aprovação”](workflows-approval-add.md). **Para aprovar ou rejeitar um fluxo de trabalho, execute a partir do console CodeCatalyst** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. No diagrama do fluxo de trabalho, selecione a caixa que representa o portão de **aprovação**. Um painel lateral é exibido. **nota** Neste ponto, você poderá enviar o URL desta página para outros aprovadores, se desejar. 1. Em **Revisar decisão**, selecione **Aprovar** ou **Rejeitar**. 1. (Opcional) Em **Comentário – opcional**, insira um comentário indicando por que você aprovou ou rejeitou a execução do fluxo de trabalho. 1. Selecione **Enviar**. **Para aprovar ou rejeitar a execução de um fluxo de trabalho a partir de um link fornecido por um membro da equipe** 1. Selecione o link enviado a você pelo membro da sua equipe. (Você pode fazer com que seu membro da equipe leia o procedimento anterior para obter o link.) 1. Faça login em CodeCatalyst, se solicitado. Você será redirecionado para a página de aprovação de execução de fluxo de trabalho. 1. Em **Revisar decisão**, selecione **Aprovar** ou **Rejeitar**. 1. (Opcional) Em **Comentário – opcional**, insira um comentário indicando por que você aprovou ou rejeitou a execução do fluxo de trabalho. 1. Selecione **Enviar**. **Para aprovar ou rejeitar a execução de um fluxo de trabalho a partir de uma notificação automática do Slack** 1. Certifique-se de que as notificações do Slack estejam configuradas. Consulte [Configuração de notificações de aprovação](workflows-approval-notify.md). 1. No Slack, no canal para o qual a notificação de aprovação foi enviada, selecione o link na notificação de aprovação. 1. Faça login em CodeCatalyst, se solicitado. Você será redirecionado para a página de execução de fluxo de trabalho. 1. No diagrama do fluxo de trabalho, selecione o portão de aprovação. 1. Em **Revisar decisão**, selecione **Aprovar** ou **Rejeitar**. 1. (Opcional) Em **Comentário – opcional**, insira um comentário indicando por que você aprovou ou rejeitou a execução do fluxo de trabalho. 1. Selecione **Enviar**. # Portão de “Aprovação” YAML Confira a seguir a definição YAML do portão de **Aprovação**. Para saber como usar esse portão, consulte [Solicitar aprovações em execuções de fluxo de trabalho](workflows-approval.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The 'Approval' gate definition starts here. Approval: Identifier: aws/approval@v1 DependsOn: - another-action Configuration: ApprovalsRequired: number ``` ## Approval (Obrigatório) Especifique o nome que você deseja dar ao portão. Todos os nomes de portão devem ser exclusivos no fluxo de trabalho. Os nomes de portão são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de portão. Padrão: `Approval_nn`. Interface de usuário correspondente: guia Configuração/**Nome do portão** ## Identifier (*Approval*/**Identifier**) (Obrigatório) Identifica o portão. O portão de **Aprovação** comporta a versão `1.0.0`. Não altere essa propriedade, a menos que você queira encurtar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Padrão: `aws/approval@v1`. Interface de usuário correspondente: rótulo do diagrama de fluxo de trabalho/Approval\$1nn/**aws/approval@v1** ## DependsOn (*Approval*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado para que esse portão seja executado. Por padrão, quando você adiciona um portão a um fluxo de trabalho, o portão é configurado para depender da última ação no fluxo de trabalho. Se você remover essa propriedade, o portão não dependerá de nada e será executado primeiro, antes de outras ações. **nota** Um portão deve ser configurado para ser executado antes ou depois de uma ação, um grupo de ação ou um portão. Ele não pode ser configurado para ser executado em paralelo com outras ações, grupos de ação e portões. Para ter mais informações sobre a funcionalidade **Depende de**, consulte [Sequenciar portões e ações](workflows-gates-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de** ## Configuration (*Approval*/**Configuration**) (Optional) Uma seção na qual você pode definir as propriedades de configuração do portão. Interface de usuário correspondente: guia **Configuração** ## ApprovalsRequired (*Approval*/Configuration/**ApprovalsRequired**) (Optional) Especifique o número mínimo de aprovações necessárias para desbloquear o portão de **Aprovação**. O mínimo é `1`. O máximo é `2`. Se for omitido, o padrão será `1`. **nota** Se você quiser omitir a propriedade `ApprovalsRequired`, remova a seção `Configuration` do portão do arquivo de definição do fluxo de trabalho. Interface de usuário correspondente: guia Configuração/**Número de aprovações** # Configurar o comportamento de enfileiramento das execuções Por padrão, no Amazon CodeCatalyst, quando várias execuções do fluxo de trabalho ocorrem simultaneamente, o CodeCatalyst as coloca em fila e as processa uma a uma, na ordem em que foram iniciadas. Esse comportamento padrão pode ser alterado especificando um *modo de execução*. Existem alguns modos de execução: + (Padrão) Modo de execução em fila: os processos do CodeCatalyst são executados um por um. + Modo de execução substituída: os processos do CodeCatalyst são executados um por um, com execuções mais recentes substituindo as mais antigas. + Modo de execução paralela: os processos do CodeCatalyst são executados paralelamente. Para ter mais informações sobre execuções de fluxos de trabalho, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). **Topics** + [ ## Sobre o modo de execução em fila ](#workflows-configure-runs-queued) + [ ## Sobre o modo de execução substituída ](#workflows-configure-runs-superseded) + [ ## Sobre o modo de execução paralela ](#workflows-configure-runs-parallel) + [ ## Configurar o modo de execução ](#workflows-configure-runs-configure) ## Sobre o modo de execução em fila No *modo de execução em fila*, as execuções ocorrem em série, com as execuções em espera formando uma fila. As filas se formam nos pontos de entrada para ações e grupos de ações, para que você possa ter *várias filas no mesmo fluxo de trabalho* (consulte [Figure 1](#figure-1-workflow-queued-run-mode)). Quando uma execução em fila aciona uma ação, ela é bloqueada e nenhuma outra execução pode ser realizada. Quando a execução termina e sai da ação, ela fica desbloqueada e pronta para a próxima execução. [Figure 1](#figure-1-workflow-queued-run-mode) ilustra um fluxo de trabalho configurado no modo de execução em fila. Mostra: + Sete execuções percorrendo o fluxo de trabalho. + Duas filas: uma fora da entrada da fonte de entrada (**Repo:main**) e outra fora da entrada da ação **BuildTestActionGroup**. + Dois blocos bloqueados: a origem da entrada (**Repo:main**) e **BuildTestActionGroup**. Veja o que ocorrerá quando o processamento das execuções do fluxo de trabalho for concluído: + Quando o **Run-4d444** terminar de clonar o repositório de origem, ele sairá da origem da entrada e entrará na fila atrás de **Run-3c333**. Depois, **Run-5e555** entrará na origem da entrada. + Quando **Run-1a111** terminar de compilar e testar, ele sairá da ação **BuildTestActionGroup** e acionará a ação **DeployAction**. Depois, o **Run-2b222** acionará a ação **BuildTestActionGroup**. **Figura 1**: um fluxo de trabalho configurado em “modo de execução em fila” ![\[Um fluxo de trabalho configurado em “modo de execução em fila”\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png) Use o modo de execução em fila se: + **Você deseja manter um relacionamento um para um entre recursos e execuções: esses recursos podem ser agrupados quando o modo de substituição é utilizado**. Por exemplo, quando você mescla o recurso 1 na confirmação 1, a execução 1 é iniciada, e quando você mescla o recurso 2 na confirmação 2, a execução 2 é iniciada e assim por diante. Se você usar o modo de substituição em vez do modo em fila, os recursos (e as confirmações) serão agrupados na execução que substituirá as outras. + **Você deseja evitar condições de corrida e problemas inesperados que possam ocorrer no uso do modo paralelo**. Por exemplo, se dois desenvolvedores de software, Wang e Saanvi, iniciarem a execução do fluxo de trabalho aproximadamente ao mesmo tempo para implantação em um cluster do Amazon ECS, a execução de Wang poderá iniciar os testes de integração no cluster, enquanto a execução de Saanvi implantará um novo código de aplicação no cluster, fazendo com que os testes de Wang falhem ou testem o código errado. Como outro exemplo, é possível ter um destino sem um mecanismo de bloqueio. Nesse caso, as duas execuções podem substituir as alterações uma da outra de maneiras inesperadas. + **Você deseja limitar a carga** nos recursos computacionais que o CodeCatalyst usa para processar as execuções. Por exemplo, se você tiver três ações no fluxo de trabalho, poderá ter no máximo três execuções ao mesmo tempo. A imposição de um limite no número de execuções que podem ocorrer simultaneamente torna o throughput de execução mais previsível. + **Você deseja restringir o número de solicitações feitas a serviços de terceiros** pelo fluxo de trabalho. Por exemplo, o fluxo de trabalho pode ter uma ação de criação que inclua instruções para extrair uma imagem do Docker Hub. [O Docker Hub limita o número de solicitações pull](https://www.docker.com/increase-rate-limits) que você pode fazer a determinado número por hora por conta, e você será bloqueado se ultrapassar o limite. Usar o modo de execução em fila para diminuir o throughput de execução terá o efeito de gerar menos solicitações para o Docker Hub por hora, limitando assim o potencial de bloqueios e gerando falhas de criação e de execução. **Tamanho máximo da fila**: 50 Notas sobre **o tamanho máximo da fila**: + O tamanho máximo da fila refere-se ao número máximo de execuções permitidas em *todas as filas* no fluxo de trabalho. + Se uma fila tiver mais de 50 execuções, o CodeCatalyst descartará a 51ª execução e as subsequentes. **Comportamento com falha**: Se uma execução deixar de responder enquanto estiver sendo processada por uma ação, as execuções atrás dela serão mantidas na fila até que a ação expire. As ações expiram após uma hora. Se uma execução falhar dentro de uma ação, a primeira execução em fila após ela poderá continuar. ## Sobre o modo de execução substituída O *modo de execução substituída* é o mesmo que o *modo de execução em fila*, exceto que: + Se uma execução em fila alcançar outra, a execução posterior substituirá a execução anterior, e a execução anterior será cancelada e marcada como “substituída”. + Como resultado do comportamento descrito no primeiro item, uma fila só pode incluir uma execução quando o modo de execução substituída é usado. Usando o fluxo de trabalho em [Figure 1](#figure-1-workflow-queued-run-mode) como guia, a aplicação do modo de execução substituída a esse fluxo de trabalho ocasionaria o seguinte: + **Run-7g777** substituiria as outras duas execuções na fila e seria a única execução restante na **Fila 1**. **Run-6f666** e **Run-5e555** seriam canceladas. + **Run-3c333** substituiria **Run-2b222** e seria a única execução restante na **Fila 2**. **Run-2b222** seria cancelada. Se desejar, use o modo de execução substituída: + melhor throughput do que no modo em fila + ainda menos solicitações em serviços de terceiros do que no modo em fila; isso será vantajoso se o serviço de terceiros tiver limites de taxa, como o Docker Hub. ## Sobre o modo de execução paralela No *modo de execução paralela*, as execuções são independentes umas das outras e não esperam que outras execuções sejam concluídas antes de começar. Não há filas e o throughput da execução é limitado apenas pela rapidez com que as ações dentro do fluxo de trabalho são concluídas. Use o modo de execução paralela em ambientes de desenvolvimento em que cada usuário tem a própria ramificação de recursos e implanta em destinos que não são compartilhados por outros usuários. **Importante** Se você tiver um destino compartilhado em que vários usuários possam implantar, como uma função do Lambda em um ambiente de produção, não use o modo paralelo, pois podem ocorrer condições de corrida. Uma *condição de corrida* ocorre quando execuções paralelas do fluxo de trabalho tentam alterar um recurso compartilhado ao mesmo tempo, gerando resultados imprevisíveis. **Número máximo de execuções paralelas**: mil por espaço do CodeCatalyst ## Configurar o modo de execução É possível definir o modo de execução como em fila, substituída ou paralela. O padrão é em fila. Quando você altera o modo de execução de em fila ou substituída para paralela, o CodeCatalyst cancela as execuções que estão na fila e permite que as execuções processadas atualmente por uma ação terminem antes de cancelá-las. Quando você altera o modo de execução de paralela para em fila ou substituída, o CodeCatalyst permite que todas as execuções paralelas em execução no momento sejam concluídas. Todas as execuções que você iniciar depois de alterar o modo de execução para em fila ou substituída usarão o novo modo. ------ #### [ Visual ] **Como alterar o modo de execução usando o editor visual** 1. Abra o console do CodeCatalyst em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. No canto superior direito, selecione **Propriedades do fluxo de trabalho**. 1. Expanda **Avançado** e, em **Modo de execução**, selecione uma das seguintes opções: 1. **Em fila**: consulte [Sobre o modo de execução em fila](#workflows-configure-runs-queued) 1. **Substituída**: consulte [Sobre o modo de execução substituída](#workflows-configure-runs-superseded) 1. **Paralela**: consulte [Sobre o modo de execução paralela](#workflows-configure-runs-parallel) 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como alterar o modo de execução usando o editor YAML** 1. Abra o console do CodeCatalyst em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Adicione a propriedade `RunMode`: ``` Name: Workflow_6d39 SchemaVersion: "1.0" RunMode: QUEUED|SUPERSEDED|PARALLEL ``` Para ter mais informações, consulte a descrição da propriedade `RunMode` na seção [Propriedades de nível superior](workflow-reference.md#workflow.top.level) de [Definição do YAML do fluxo de trabalho](workflow-reference.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Armazenar arquivos em cache entre execuções de fluxo de trabalho Quando o armazenamento de arquivos em cache está ativado, as ações de compilação e teste salvam os arquivos em disco em um cache e os restauram desse cache em execuções subsequentes do fluxo de trabalho. O armazenamento em cache reduz a latência causada pela criação ou download de dependências que não foram alteradas entre as execuções. CodeCatalyst também suporta caches alternativos, que podem ser usados para restaurar caches parciais contendo algumas das dependências necessárias. Isso ajuda a reduzir os impactos de latência de uma perda de cache. **nota** O armazenamento em cache de arquivos só está disponível com as ações de CodeCatalyst [criação](build-workflow-actions.md) e [teste](test-workflow-actions.md) da Amazon e somente quando elas estão configuradas para usar o tipo de **EC2**[computação.](workflows-working-compute.md#compute.types) **Topics** + [ ## Sobre o armazenamento de arquivos em cache ](#workflows-caching.files) + [ ## Criar um cache ](#workflows-caching.fallback) + [ ## Restrições de armazenamento de arquivos em cache ](#workflows-caching.constraints) ## Sobre o armazenamento de arquivos em cache O armazenamento de arquivos em cache permite que você organize os dados em vários caches, cada um referido na propriedade `FileCaching`. Cada cache salva um diretório especificado por determinado caminho. O diretório especificado será restaurado em futuras execuções do fluxo de trabalho. Veja a seguir um exemplo de trecho YAML para armazenamento em cache com vários caches chamados e `cacheKey1` e `cacheKey2`. ``` Actions: BuildMyNpmApp: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: npm install - Run: npm run test Caching: FileCaching: cacheKey1: Path: file1.txt RestoreKeys: - restoreKey1 cacheKey2: Path: /root/repository RestoreKeys: - restoreKey2 - restoreKey3 ``` **nota** CodeCatalyst usa cache multicamada, que consiste em um cache local e um cache remoto. Quando frotas provisionadas ou máquinas sob demanda encontram uma perda de cache em um cache local, as dependências são restauradas a partir de um cache remoto. Como resultado, algumas ações podem apresentar latência ao baixar um cache remoto. CodeCatalyst aplica restrições de acesso ao cache para garantir que uma ação em um fluxo de trabalho não possa modificar os caches de um fluxo de trabalho diferente. Isso protege cada fluxo de trabalho de outros que podem enviar dados incorretos que afetem compilações ou implantações. As restrições são aplicadas com escopos de cache que isolam os caches de cada fluxo de trabalho e emparelhamento de ramificações. Por exemplo, `workflow-A` na ramificação `feature-A` tem um cache de arquivo diferente de `workflow-A` na ramificação `feature-B` irmã. As falhas de cache ocorrem quando um fluxo de trabalho procura um cache de arquivo especificado e não consegue encontrá-lo. Isso pode ocorrer por vários motivos, como quando uma ramificação é criada ou quando um novo cache é referido e ainda não foi criado. Também pode ocorrer quando um cache expira, o que, por padrão, ocorre 14 dias após o último uso. Para mitigar as falhas de cache e aumentar a taxa de acessos ao cache, CodeCatalyst oferece suporte a caches alternativos. Os caches de fallback oferecem uma oportunidade de restaurar caches parciais, que podem ser uma versão mais antiga de um cache. Um cache é restaurado pesquisando primeiro por uma correspondência em `FileCaching` pelo nome da propriedade e, se não for encontrado, `RestoreKeys` será avaliado. Se houver uma falha de cache tanto no nome da propriedade quanto em todas as opções de `RestoreKeys`, o fluxo de trabalho continuará sendo executado, pois o armazenamento em cache é o melhor esforço e não é garantido. ## Criar um cache Use as instruções a seguir para adicionar um cache ao fluxo de trabalho. ------ #### [ Visual ] **Como adicionar um cache usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação onde deseja adicionar o cache. 1. Escolher **configuração**. 1. Em **Cache de arquivos – opcional**, selecione **Adicionar cache** e insira as informações nos campos, da seguinte forma: **Chave** Especifique o nome da propriedade de cache principal. Os nomes de propriedade de cache devem ser exclusivos no fluxo de trabalho. Cada ação pode ter até cinco entradas em `FileCaching`. **Path** Especifique o caminho associado ao cache. **Chaves de restauração – opcional** Especifique a chave de restauração a ser usada como fallback quando a propriedade do cache principal não puder ser encontrada. Os nomes de chave de restauração devem ser exclusivos no fluxo de trabalho. Cada cache pode ter até cinco entradas em `RestoreKeys`. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como adicionar um cache usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma ação de fluxo de trabalho, adicione um código semelhante ao seguinte: ``` action-name: Configuration: Steps: ... Caching: FileCaching: key-name: Path: file-path # # Specify any additional fallback caches # RestoreKeys: # - restore-key ``` 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ ## Restrições de armazenamento de arquivos em cache Veja a seguir as restrições para o nome da propriedade e `RestoreKeys`: + Os nomes devem ser exclusivos no fluxo de trabalho. + Os nomes são limitados a caracteres alfanuméricos (A-Z, a-z, 0-9), hifens (-) e sublinhados (\$1). + Os nomes podem ter até 180 caracteres. + Cada ação pode ter até cinco caches em `FileCaching`. + Cada cache pode ter até cinco entradas em `RestoreKeys`. Veja a seguir as restrições para caminhos: + Asteriscos (\$1) não são permitidos. + Os caminhos podem ter até 255 caracteres. # Visualização do status e detalhes de execução do fluxo de trabalho Na Amazon CodeCatalyst, você pode visualizar o status e os detalhes de uma única execução de fluxo de trabalho ou de várias execuções ao mesmo tempo. Para ver uma lista de possíveis estados de execução, consulte [Estados de execução do fluxo de trabalho](workflows-view-run-status.md). **nota** Você também pode visualizar o status do fluxo de trabalho, que é diferente do status de *execução*. Para obter mais informações, consulte [Visualização do status de um fluxo de trabalho](workflows-view-status.md). Para ter mais informações sobre execuções de fluxos de trabalho, consulte [Executar um fluxo de trabalho](workflows-working-runs.md). **Topics** + [ ## Visualização do status e detalhes de uma única execução ](#workflows-view-run-single) + [ ## Visualizar o status e detalhes de todas as execuções em seu projeto ](#workflows-view-run-all) + [ ## Visualizar o status e os detalhes de todas as execuções de um fluxo de trabalho específico ](#workflows-view-run-wf) + [ ## Visualização de execuções de um fluxo de trabalho no diagrama do fluxo de trabalho ](#workflows-view-run-wf-diagram) ## Visualização do status e detalhes de uma única execução Talvez você queira visualizar o status e os detalhes de uma única execução de fluxo de trabalho para conferir se ela foi bem-sucedida, para ver em que momento foi concluída ou para ver quem ou o que a iniciou. **Como visualizar o status e os detalhes de uma única execução** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Abaixo do nome do fluxo de trabalho, selecione **Execuções**. 1. Em **Histórico de execução**, na coluna **ID da execução**, escolha uma execução. Por exemplo, .`Run-95a4d` 1. Abaixo do nome da execução, faça o seguinte: + **Visual** para ver um diagrama do fluxo de trabalho mostrando as ações e o status da execução do fluxo de trabalho (consulte [Estados de execução do fluxo de trabalho](workflows-view-run-status.md)). Essa visualização também mostra o repositório de origem e a ramificação usados durante a execução. No diagrama do fluxo de trabalho, selecione uma ação para ver detalhes, como logs, relatórios e saídas geradas pela ação durante a execução. As informações exibidas dependem do tipo de ação selecionado. Para ter mais informações sobre como visualizar logs de compilação ou implantação, consulte [Visualização dos resultados de uma ação de criação](build-view-results.md) ou [Visualização dos logs de implantação](deploy-deployment-logs.md). + **YAML** para ver o arquivo de definição do fluxo de trabalho usado para a execução. + **Artefatos** para ver os artefatos produzidos pela execução do fluxo de trabalho. Para obter mais informações sobre artefatos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). + **Relatórios** para ver os relatórios de teste e outros tipos de relatórios produzidos pela execução do fluxo de trabalho. Para obter mais informações sobre os relatórios, consulte [Tipos de relatório de qualidade](test-workflow-actions.md#test-reporting). + **Variáveis** para ver as variáveis de saída produzidas pela execução do fluxo de trabalho. Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **nota** Se o fluxo de trabalho principal da execução foi excluído, uma mensagem indicando esse fato será exibida na parte superior da página de detalhes da execução. ## Visualizar o status e detalhes de todas as execuções em seu projeto Talvez você queira visualizar o status e detalhes de todas as execuções de fluxo de trabalho em seu projeto, entender quanta atividade de fluxo de trabalho está acontecendo em seu projeto e aprender sobre a integridade geral de seus fluxos de trabalho. **Para visualizar o status e detalhes de todas as execuções em seu projeto** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Em **Fluxos de trabalho**, selecione **Execuções.** Todas as execuções, para todos os fluxos de trabalho, em todas as ramificações, em todos os repositórios do seu projeto, são exibidas. A página inclui as seguintes colunas: + **ID de execução** – Identificador exclusivo da execução. Selecione o link do ID de execução para visualizar informações detalhadas sobre a execução. + **Status** – O status de processamento da execução do fluxo de trabalho. Para ter mais informações sobre os status de execução, consulte [Estados de execução do fluxo de trabalho](workflows-view-run-status.md). + **Gatilho**: a pessoa, a confirmação e a solicitação pull (PR) ou a programação que iniciou a execução do fluxo de trabalho. Para obter mais informações, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + **Fluxo de trabalho** – O nome do fluxo de trabalho para o qual a execução foi iniciada e o repositório de origem e a ramificação em que o arquivo de definição do fluxo de trabalho reside. Talvez seja necessário expandir a largura da coluna para ver essas informações. **nota** Se essa coluna estiver definida como **Não disponível**, geralmente é porque o fluxo de trabalho associado foi excluído ou movido. + **Hora de início** – Hora em que a execução do fluxo de trabalho foi iniciada. + **Duração** – Quanto tempo a execução do fluxo de trabalho levou para ser processada. Durações muito longas ou muito curtas podem indicar problemas. + **Hora de término** – Hora em que a execução do fluxo de trabalho foi finalizada. ## Visualizar o status e os detalhes de todas as execuções de um fluxo de trabalho específico Talvez você queira visualizar o status e os detalhes de todas as execuções associadas a um fluxo de trabalho específico para ver se alguma execução está criando gargalos no fluxo de trabalho ou para ver quais execuções estão atualmente em andamento ou foram concluídas. **Para visualizar o status e detalhes de todas as execuções de um fluxo de trabalho específico** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Abaixo do nome do fluxo de trabalho, selecione **Execuções**. As execuções associadas ao fluxo de trabalho selecionado são exibidas. A página é dividida em duas seções: + **Execuções ativas** – Exibe as execuções que estão em andamento. Essas execuções estarão em um dos seguintes estados: **Em andamento**. + **Histórico de execuções** – Exibe as execuções que foram concluídas (ou seja, que não estão em andamento). Para ter mais informações sobre os status de execução, consulte [Estados de execução do fluxo de trabalho](workflows-view-run-status.md). ## Visualização de execuções de um fluxo de trabalho no diagrama do fluxo de trabalho Você pode visualizar o status de todas as execuções de um fluxo de trabalho conforme elas progridem juntas no fluxo de trabalho. As execuções são exibidas no diagrama do fluxo de trabalho (em vez de em uma exibição em lista). Isso fornece uma representação visual de quais execuções estão sendo processadas por quais ações e quais execuções estão aguardando em uma fila. **Como visualizar o status de várias execuções conforme elas progridem juntas em um fluxo de trabalho** **nota** Esse procedimento será aplicado apenas se o fluxo de trabalho estiver usando o modo de execução em fila ou de substituição. Para obter mais informações, consulte [Configurar o comportamento de enfileiramento das execuções](workflows-configure-runs.md). 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. **nota** Verifique se você está vendo uma página de fluxo de trabalho e não uma página de execução. 1. Selecione a guia **Estado mais recente** no canto superior esquerdo. Um diagrama do fluxo de trabalho é exibido. 1. Revise o diagrama do fluxo de trabalho. O diagrama mostra todas as execuções que estão em andamento no fluxo de trabalho e as execuções mais recentes que foram concluídas. Mais especificamente: + As execuções exibidas na parte superior, antes de **Origens**, estão na fila aguardando o início. + As execuções exibidas entre as ações são colocadas em fila e aguardam para serem processadas pela próxima ação. + As execuções que aparecem em uma ação 1. estão atualmente sendo processadas pela ação, 2. terminaram de ser processadas pela ação ou 3. não foram processadas pela ação (geralmente porque uma ação anterior falhou). # Configuração de ações de fluxo de trabalho Uma *ação* é o principal componente de um fluxo de trabalho e define uma unidade lógica de trabalho, ou tarefa, a ser realizada durante a execução de um fluxo de trabalho. Normalmente, um fluxo de trabalho inclui várias ações que são executadas de modo sequencial ou paralelo, dependendo de como você as configurou. **Topics** + [ ## Tipos de ação ](#workflows-actions-types) + [ # Adição de uma ação a um fluxo de trabalho ](workflows-add-action.md) + [ # Remover uma ação de um fluxo de trabalho ](workflows-delete-action.md) + [ # Desenvolver uma ação personalizada ](workflows-custom-action.md) + [ # Agrupar ações em grupos de ações ](workflows-group-actions.md) + [ # Sequenciar ações ](workflows-depends-on.md) + [ # Compartilhar artefatos e arquivos entre ações ](workflows-working-artifacts.md) + [ # Especificação da versão da ação a ser usada ](workflows-action-versions.md) + [ # Lista das versões de ação disponíveis ](workflows-action-versions-determine.md) + [ # Visualizar o código-fonte de uma ação ](workflows-view-source.md) + [ # Integração com GitHub ações ](integrations-github-actions.md) ## Tipos de ação Em um CodeCatalyst fluxo de trabalho da Amazon, você pode usar os seguintes tipos de ações. **Topics** + [ ### CodeCatalyst ações ](#workflows-actions-types-cc) + [ ### CodeCatalyst Ações do Labs ](#workflows-actions-types-cc-labs) + [ ### GitHub Ações ](#workflows-actions-types-github) + [ ### Ações de terceiros ](#workflows-actions-types-3p) ### CodeCatalyst ações Uma *CodeCatalyst ação* é uma ação criada, mantida e totalmente apoiada pela equipe de CodeCatalyst desenvolvimento. Existem CodeCatalyst ações para criar, testar e implantar aplicativos, bem como para realizar tarefas diversas, como invocar uma função. AWS Lambda As seguintes CodeCatalyst ações estão disponíveis: + **Compilar** Essa ação cria seus artefatos e executa seus testes de unidade em um contêiner do Docker. Para obter mais informações, consulte [Adição da ação de criação](build-add-action.md). + **Teste** Essa ação executa testes de integração e sistema em relação à aplicação ou a artefatos. Para obter mais informações, consulte [Adição da ação de teste](test-add-action.md). + **Publicação do Amazon S3** Essa ação copia os artefatos da aplicação para um bucket do Amazon S3. Para obter mais informações, consulte [Publicação de arquivos no Amazon S3 com um fluxo de trabalho](s3-pub-action.md). + **AWS CDK bootstrap** Essa ação provisiona os recursos AWS CDK necessários para implantar seu aplicativo CDK. Para obter mais informações, consulte [Inicializando um AWS CDK aplicativo com um fluxo de trabalho](cdk-boot-action.md). + **AWS CDK implantar** Essa ação sintetiza e implanta um aplicativo. AWS Cloud Development Kit (AWS CDK) Para obter mais informações, consulte [Implantando um AWS CDK aplicativo com um fluxo de trabalho](cdk-dep-action.md). + **AWS Lambda invocar** Essa ação invoca uma AWS Lambda função. Para obter mais informações, consulte [Invocar uma função do Lambda usando um fluxo de trabalho](lam-invoke-action.md). + **GitHub Ações** Essa ação é uma *CodeCatalyst*ação que permite que você execute GitHub ações em um CodeCatalyst fluxo de trabalho. Para obter mais informações, consulte [Invocar uma função do Lambda usando um fluxo de trabalho](lam-invoke-action.md). + **Implante a CloudFormation pilha** Essa ação implanta CloudFormation pilhas. Para obter mais informações, consulte [Implantação de uma pilha CloudFormation](deploy-action-cfn.md). + **Implantar no Amazon ECS** Essa ação registra uma definição de tarefa do Amazon ECS e a implanta em um serviço do Amazon ECS. Para obter mais informações, consulte [Implantação no Amazon ECS com um fluxo de trabalho](deploy-action-ecs.md). + **Implantar no cluster do Kubernetes** Essa ação implanta uma aplicação em um cluster do Kubernetes. Para obter mais informações, consulte [Implantar no Amazon EKS com um fluxo de trabalho](deploy-action-eks.md). + **Renderizar definição de tarefa do Amazon ECS** Essa ação insere um URI de imagem de contêiner em um arquivo JSON de definição de tarefa do Amazon ECS, criando um novo arquivo de definição de tarefa. Para obter mais informações, consulte [Modificação de uma definição de tarefa do Amazon ECS](render-ecs-action.md). A documentação CodeCatalyst das ações está disponível neste guia e no readme de cada ação. Para obter informações sobre as CodeCatalyst ações disponíveis e como adicioná-las a um fluxo de trabalho, consulte[Adição de uma ação a um fluxo de trabalho](workflows-add-action.md). ### CodeCatalyst Ações do Labs Uma *ação do CodeCatalyst Labs* é uma ação que faz parte do Amazon CodeCatalyst Labs, um campo de testes para aplicações experimentais. CodeCatalyst As ações do Labs foram desenvolvidas para mostrar as integrações com AWS os serviços. As seguintes ações do CodeCatalyst Labs estão disponíveis: + **Implemente AWS Amplify na hospedagem** Esta ação implanta uma aplicação no Amplify Hosting. + **Implemente em AWS App Runner** Essa ação implanta a imagem mais recente em um repositório de imagens de origem no App Runner. + **Implemente na Amazon CloudFront e no Amazon S3** Essa ação implanta um aplicativo no Amazon S3. CloudFront + **Implemente com AWS SAM** Essa ação implanta a aplicação sem servidor com AWS Serverless Application Model (AWS SAM). + **Invalidar o Amazon Cache CloudFront ** Essa ação invalida um CloudFront cache para um determinado conjunto de caminhos. + **Webhook de saída** Essa ação permite que os usuários enviem mensagens dentro de um fluxo de trabalho para um servidor web arbitrário usando uma solicitação HTTPS. + **Publicar em AWS CodeArtifact** Essa ação publica pacotes em um CodeArtifact repositório. + **Publicar no Amazon SNS** Essa ação permite que os usuários se integrem ao Amazon SNS criando um tópico, publicando em um tópico ou assinando um tópico. + **Enviar no Amazon ECR** Essa ação compila e publica uma imagem do Docker em um repositório do Amazon Elastic Container Registry (Amazon ECR). + **Digitalize com a Amazon CodeGuru Security** Essa ação cria um arquivo zip de um caminho de código configurado e usa a CodeGuru Segurança para executar uma varredura de código. + **Terraform Community Edition** Essa ação executa a Terraform Community Edition `plan` e as operações `apply`. A documentação das ações do CodeCatalyst Labs está disponível no readme de cada ação. Para obter informações sobre como adicionar uma ação do CodeCatalyst Labs a um fluxo de trabalho e visualizar seu readme, consulte[Adição de uma ação a um fluxo de trabalho](workflows-add-action.md). ### GitHub Ações Uma *GitHub ação* é muito parecida com uma [CodeCatalyst ação](#workflows-actions-types-cc), exceto pelo fato de ter sido desenvolvida para uso com GitHub fluxos de trabalho. Para obter detalhes sobre GitHub ações, consulte a documentação de [GitHub ações](https://docs.github.com/en/actions). Você pode usar GitHub ações junto com CodeCatalyst ações nativas em um CodeCatalyst fluxo de trabalho. Para sua conveniência, o CodeCatalyst console fornece acesso a várias GitHub ações populares. Você também pode usar qualquer GitHub Ação listada no [GitHub Marketplace](https://github.com/marketplace/actions) (sujeita a algumas limitações). A documentação GitHub das ações está disponível no readme de cada ação. Para obter mais informações, consulte [Integração com GitHub ações](integrations-github-actions.md). ### Ações de terceiros Uma *ação de terceiros* é uma ação de autoria de um fornecedor terceirizado e disponibilizada no console. CodeCatalyst Exemplos de ações de terceiros incluem as ações **Mend SCA** e **SonarCloud Scan**, de autoria de Mend e Sonar, respectivamente. A documentação das ações de terceiros está disponível no readme de cada ação. Documentação adicional também pode ser fornecida pelo fornecedor terceirizado. Para ter informações sobre como adicionar uma ação de terceiro a um fluxo de trabalho e visualizar seu readme, consulte [Adição de uma ação a um fluxo de trabalho](workflows-add-action.md). # Adição de uma ação a um fluxo de trabalho Use as instruções a seguir para adicionar uma ação a um fluxo de trabalho e depois configurá-lo. **Para adicionar e configurar uma ação** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. No canto superior esquerdo, selecione **\$1 Ações** para exibir o catálogo de **Ações**. 1. Na lista suspensa, realize uma das seguintes ações. + Escolha **Amazon CodeCatalyst** para visualizar [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) ou ações [de terceiros](workflows-actions.md#workflows-actions-types-3p). + CodeCatalyst as ações têm um AWS rótulo **por**. + CodeCatalyst As ações do Labs têm um rótulo **by CodeCatalyst Labs**. + As ações de terceiros têm um *vendor* rótulo “**by**”, onde *vendor* está o nome do fornecedor terceirizado. + Escolha **GitHub**ver uma [lista organizada de GitHub ações](integrations-github-action-add-curated.md). 1. No catálogo de ações, procure uma ação e siga um dos seguintes procedimentos: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao seu fluxo de trabalho. + Selecione o nome da ação para visualizar seu readme. 1. Configure a ação. Selecione **Visual** para usar o editor visual ou **YAML** para usar o editor YAML. Para ter instruções detalhadas, consulte os seguintes links: Para obter instruções sobre como adicionar [CodeCatalystações](workflows-actions.md#workflows-actions-types-cc), consulte: + [Adição da ação de criação](build-add-action.md) + [Adição da ação de teste](test-add-action.md) + [Adição da ação “Implantar no Amazon ECS”](deploy-action-ecs-adding.md) + [Adição da ação “Implantar no cluster do Kubernetes”](deploy-action-eks-adding.md) + [Adicionando a ação “Deploy CloudFormation stack”](deploy-action-cfn-adding.md) + [Adicionando a ação 'AWS CDK implantar'](cdk-dep-action-add.md) + [Adicionando a ação 'AWS CDK bootstrap'](cdk-boot-action-add.md) + [Adicionar a ação “Publicação no Amazon S3”](s3-pub-action-add.md) + [Adicionando a ação 'AWS Lambda invocar'](lam-invoke-action-add.md) + [Adicionar a ação “Renderizar definição de tarefa do Amazon ECS”](render-ecs-action-add.md) Para obter instruções sobre como adicionar [ações do CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs), consulte: + O readme da ação. Você pode encontrar o readme selecionando o nome da ação no catálogo de ações. Para obter instruções sobre como adicionar [GitHub ações](workflows-actions.md#workflows-actions-types-github), consulte: + [Integração com GitHub ações](integrations-github-actions.md) Para ter instruções sobre como adicionar [ações de terceiros](workflows-actions.md#workflows-actions-types-3p), consulte: + O readme da ação. Você pode encontrar o readme selecionando o nome da ação no catálogo de ações. 1. (Opcional) Selecione **Validar** para garantir que o código YAML seja válido. 1. Selecione **Confirmar** para confirmar suas alterações. # Remover uma ação de um fluxo de trabalho Use as instruções a seguir para remover uma ação de um fluxo de trabalho. ------ #### [ Visual ] **Como remover uma ação usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, na ação que você deseja remover, selecione o ícone de reticências (![\[Ellipsis.\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/images/flows/elipsis.png)) e escolha **Remover**. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como remover uma ação usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Encontre a seção do YAML que contém a ação que você deseja remover. Selecione a seção e pressione a tecla “delete” no teclado. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Desenvolver uma ação personalizada Você pode desenvolver uma ação personalizada para usar em seus fluxos de trabalho usando o CodeCatalyst Action Development Kit (ADK). Em seguida, você pode publicar a ação no catálogo de CodeCatalyst ações, para que outros CodeCatalyst usuários possam visualizá-la e usá-la em seus fluxos de trabalho. **Como desenvolver, testar e publicar uma ação (tarefas de alto nível)** 1. Instale as ferramentas e os pacotes necessários para desenvolver uma ação. 1. Crie um CodeCatalyst repositório para armazenar seu código de ação. 1. Inicialize a ação. Isso estabelece os arquivos de origem exigidos pela ação, inclusive um arquivo de definição de ação (`action.yml`) que você pode atualizar com o próprio código. 1. Inicialize o código de ação para ter as ferramentas e as bibliotecas necessárias para compilar, testar e lançar o projeto de ação. 1. Crie a ação no seu computador local e envie as alterações para o seu CodeCatalyst repositório. 1. Teste a ação com testes de unidade localmente e execute o fluxo de trabalho gerado pelo ADK no. CodeCatalyst 1. Publique a ação no catálogo de CodeCatalyst ações escolhendo o botão **Publicar** no CodeCatalyst console. Para obter etapas detalhadas, consulte o [Guia do desenvolvedor do Amazon CodeCatalyst Action Development Kit](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html). # Agrupar ações em grupos de ações Um *grupo de ações* contém uma ou mais ações. O agrupamento de ações em grupos ajuda a manter o fluxo de trabalho organizado e também permite configurar dependências entre grupos diferentes. **nota** Não é possível aninhar grupos de ações em outros grupos de ações ou ações. **Topics** + [ ## Definir um grupo de ações ](#workflows-define-action-group) + [ # Exemplo: definir dois grupos de ações ](workflows-group-actions-example.md) ## Definir um grupo de ações Use as instruções a seguir para definir um grupo de CodeCatalyst ação. ------ #### [ Visual ] *Não disponível. Escolha YAML para visualizar as instruções YAML.* ------ #### [ YAML ] **Para definir um grupo** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em `Actions`, adicione um código semelhante ao seguinte: ``` Actions: action-group-name: Actions: action-1: Identifier: aws/build@v1 Configuration: ... action-2: Identifier: aws/build@v1 Configuration: ... ``` Para obter outro exemplo, consulte [Exemplo: definir dois grupos de ações](workflows-group-actions-example.md). Para ter mais informações, consulte a descrição da propriedade `action-group-name` em [Ações](workflow-reference.md#actions-reference) de [Definição do YAML do fluxo de trabalho](workflow-reference.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Exemplo: definir dois grupos de ações O exemplo a seguir mostra como definir dois grupos de CodeCatalyst ação da Amazon: `BuildAndTest` `Deploy` e. O grupo `BuildAndTest` inclui duas ações (`Build` e `Test`), e o grupo `Deploy` também inclui duas ações (`DeployCloudFormationStack` e `DeployToECS`). ``` Actions: BuildAndTest: # Action group 1 Actions: Build: Identifier: aws/build@v1 Configuration: ... Test: Identifier: aws/managed-test@v1 Configuration: Deploy: #Action group 2 Actions: DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 Configuration: ... DeployToECS: Identifier: aws/ecs-deploy@v1 Configuration: ... ``` # Sequenciar ações Por padrão, quando você adiciona ações a um fluxo de trabalho, elas são adicionadas lado a lado ao [editor visual](workflow.md#workflow.editors). Isso significa que as ações serão executadas paralelamente quando você iniciar a execução de um fluxo de trabalho. Se você quiser que as ações sejam executadas em ordem sequencial (e apareçam verticalmente no editor visual), configure dependências entre elas. Por exemplo, você pode configurar uma ação `Test` para depender da ação `Build` para que a ação de teste seja executada após a ação de criação. É possível configurar dependências entre ações e grupos de ações. Você também pode configurar one-to-many dependências para que uma ação dependa de várias outras para ser iniciada. Consulte as diretrizes em [Configurar dependências entre ações](workflows-depends-on-set-up.md) para garantir que sua configuração de dependência esteja em conformidade com a sintaxe YAML do fluxo de trabalho. **Topics** + [ # Exemplos de como configurar dependências entre ações ](workflows-depends-on-examples.md) + [ # Configurar dependências entre ações ](workflows-depends-on-set-up.md) # Exemplos de como configurar dependências entre ações Os exemplos a seguir mostram como configurar dependências entre ações e grupos no arquivo de definição do fluxo de trabalho. **Topics** + [ ## Exemplo: configurar uma dependência simples ](#workflows-depends-on-example-simple) + [ ## Exemplo: configurar um grupo de ações para depender de uma ação ](#workflows-depends-on-example-action-groups-actions) + [ ## Exemplo: configurar um grupo de ações para depender de outro grupo de ações. ](#workflows-depends-on-example-two-action-groups) + [ ## Exemplo: configurar um grupo de ações para depender de várias ações. ](#workflows-depends-on-example-advanced) ## Exemplo: configurar uma dependência simples O exemplo a seguir mostra como configurar uma ação `Test` para depender da ação `Build` usando a propriedade `DependsOn`. ``` Actions: Build: Identifier: aws/build@v1 Configuration: ... Test: DependsOn: - Build Identifier: aws/managed-test@v1 Configuration: ... ``` ## Exemplo: configurar um grupo de ações para depender de uma ação O exemplo a seguir mostra como configurar uma ação `DeployGroup` para depender da ação `FirstAction`. Observe que a ação e o grupo de ações estão no mesmo nível. ``` Actions: FirstAction: #An action outside an action group Identifier: aws/github-actions-runner@v1 Configuration: ... DeployGroup: #An action group containing two actions DependsOn: - FirstAction Actions: DeployAction1: ... DeployAction2: ... ``` ## Exemplo: configurar um grupo de ações para depender de outro grupo de ações. O exemplo a seguir mostra como configurar um grupo de ações `DeployGroup` para depender do grupo de ações `BuildAndTestGroup`. Observe que os grupos de ações estão no mesmo nível. ``` Actions: BuildAndTestGroup: # Action group 1 Actions: BuildAction: ... TestAction: ... DeployGroup: #Action group 2 DependsOn: - BuildAndTestGroup Actions: DeployAction1: ... DeployAction2: ... ``` ## Exemplo: configurar um grupo de ações para depender de várias ações. O exemplo a seguir mostra como configurar um grupo de ações `DeployGroup` para depender da ação `FirstAction`, da ação `SecondAction` e do grupo de ações `BuildAndTestGroup`. Observe que `DeployGroup` está no mesmo nível de `FirstAction`, `SecondAction` e `BuildAndTestGroup`. ``` Actions: FirstAction: #An action outside an action group ... SecondAction: #Another action ... BuildAndTestGroup: #Action group 1 Actions: Build: ... Test: ... DeployGroup: #Action group 2 DependsOn: - FirstAction - SecondAction - BuildAndTestGroup Actions: DeployAction1: ... DeployAction2: ... ``` # Configurar dependências entre ações Use as instruções a seguir para configurar dependências entre ações em um fluxo de trabalho. Ao configurar dependências, siga estas diretrizes: + Se uma ação estiver dentro de um grupo, ela só pode depender de outras ações dentro do mesmo grupo. + As ações e os grupos de ações podem depender de outras ações e grupos de ações *no mesmo nível* na hierarquia YAML, mas *não* em um nível diferente. ------ #### [ Visual ] **Como configurar dependências usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação que dependerá de outra ação. 1. Escolha a guia **Entradas**. 1. Em **Depende de – opcional**, faça o seguinte: Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como configurar dependências usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma ação que dependerá de outra, adicione um código semelhante ao seguinte: ``` action-name: DependsOn: - action-1 ``` Para obter mais exemplos, consulte [Exemplos de como configurar dependências entre ações](workflows-depends-on-examples.md). Para conhecer as diretrizes gerais, consulte [Configurar dependências entre ações](#workflows-depends-on-set-up). Para ter mais informações, consulte a descrição da propriedade `DependsOn` em [Definição do YAML do fluxo de trabalho](workflow-reference.md) para a ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Compartilhar artefatos e arquivos entre ações *Artefato* é a saída de uma ação de fluxo de trabalho e geralmente consiste em uma pasta ou um arquivameto de arquivos. Os artefatos são importantes porque permitem que você compartilhe arquivos e informações entre as ações. Por exemplo, você pode ter uma ação de criação que *gera* um arquivo `sam-template.yml`, mas deseja que uma ação de implantação a *use*. Nesse cenário, você usaria um artefato para permitir que a ação de criação compartilhasse o arquivo `sam-template.yml` com a ação de implantação. O código pode ser semelhante a este: ``` Actions: BuildAction: Identifier: aws/build@v1 Steps: - Run: sam package --output-template-file sam-template.yml Outputs: Artifacts: - Name: MYARTIFACT Files: - sam-template.yml DeployAction: Identifier: aws/cfn-deploy@v1 Inputs: Artifacts: - MYARTIFACT Configuration: template: sam-template.yml ``` No código anterior, a ação de criação (`BuildAction`) gera um arquivo `sam-template.yml` e o adiciona a um artefato de saída chamado `MYARTIFACT`. Uma ação de implantação subsequente (`DeployAction`) especifica `MYARTIFACT` como uma entrada, dando acesso ao arquivo `sam-template.yml`. **Topics** + [ ## Posso compartilhar artefatos sem especificá-los como saídas e entradas? ](#workflows-working-artifacts-share) + [ ## Posso compartilhar artefatos entre fluxos de trabalho? ](#workflows-working-artifacts-share-wf) + [ # Exemplos de artefatos ](workflows-working-artifacts-ex.md) + [ # Definir um artefato de saída ](workflows-working-artifacts-output.md) + [ # Definir um artefato de entrada ](workflows-working-artifacts-refer.md) + [ # Referência de arquivos em um artefato ](workflows-working-artifacts-refer-files.md) + [ # Baixar artefatos ](workflows-download-workflow-outputs.md) ## Posso compartilhar artefatos sem especificá-los como saídas e entradas? Sim, você pode compartilhar artefatos entre ações sem especificá-los nas seções `Outputs` e `Inputs` do código de YAML de suas ações. Para fazer isso, você deve ativar o compartilhamento de computação. Para ter mais informações sobre o compartilhamento de computação e como especificar artefatos quando ele está ativado, consulte [Compartilhamento de computação entre ações](compute-sharing.md). **nota** Embora o recurso de compartilhamento de computação permita que você simplifique o código YAML do seu fluxo de trabalho eliminando a necessidade das seções `Outputs` e `Inputs`, o recurso tem limitações que você deve conhecer antes de ativá-lo. Para ter informações sobre essas limitações, consulte [Considerações sobre compartilhamento de computação](compute-sharing.md#compare-compute-sharing). ## Posso compartilhar artefatos entre fluxos de trabalho? Não, você não pode compartilhar artefatos entre fluxos de trabalho diferentes. No entanto, pode compartilhar artefatos entre ações dentro do mesmo fluxo de trabalho. # Exemplos de artefatos Os exemplos a seguir mostram como gerar, inserir e referenciar artefatos no arquivo de definição de CodeCatalyst fluxo de trabalho da Amazon. **Topics** + [ ## Exemplo: geração de um artefato ](#workflows-working-artifacts-ex-basic) + [ ## Exemplo: inserir um artefato gerado por outra ação ](#workflows-working-artifacts-ex-ref) + [ ## Exemplo: referência de arquivos em vários artefatos ](#workflows-working-artifacts-ex-ref-file) + [ ## Exemplo: referência de um arquivo em um único artefato ](#workflows-working-artifacts-ex-ref-file-one) + [ ## Exemplo: referenciar um arquivo em um artefato quando um está presente WorkflowSource ](#workflows-working-artifacts-ex-ref-file-wf-source) + [ ## Exemplo: referência a um arquivo em um artefato quando um grupo de ações está presente ](#workflows-working-artifacts-ex-groups) ## Exemplo: geração de um artefato O exemplo a seguir mostra como gerar um artefato que inclui dois arquivos .jar. ``` Actions: Build: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ARTIFACT1 Files: - build-output/file1.jar - build-output/file2.jar ``` ## Exemplo: inserir um artefato gerado por outra ação O exemplo a seguir mostra como gerar um artefato chamado `ARTIFACT4` em `BuildActionA`, e inseri-lo em `BuildActionB`. ``` Actions: BuildActionA: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ARTIFACT4 Files: - build-output/file1.jar - build-output/file2.jar BuildActionB: Identifier: aws/build@v1 Inputs: Artifacts: - ARTIFACT4 Configuration: ``` ## Exemplo: referência de arquivos em vários artefatos O exemplo a seguir mostra como gerar dois artefatos chamados `ART5` e `ART6` em `BuildActionC` e, depois, referenciar dois arquivos chamados `file5.txt` (no artefato `ART5`) e `file6.txt` (no artefato `ART6`) em `BuildActionD` (em `Steps`). **nota** Para ter mais informações sobre como referenciar arquivos, consulte [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). **nota** Embora o exemplo mostre o prefixo `$CATALYST_SOURCE_DIR_ART5` que está sendo usado, você pode omiti-lo. Isso ocorre porque `ART5` é a *entrada primária*. Para saber mais sobre a entrada primária, consulte [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). ``` Actions: BuildActionC: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART5 Files: - build-output/file5.txt - Name: ART6 Files: - build-output/file6.txt BuildActionD: Identifier: aws/build@v1 Inputs: Artifacts: - ART5 - ART6 Configuration: Steps: - run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt - run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt ``` ## Exemplo: referência de um arquivo em um único artefato O exemplo a seguir mostra como gerar um artefato chamado `ART7` em `BuildActionE` e, depois, referenciar `file7.txt` (no artefato `ART7`) em `BuildActionF` (em `Steps`). Observe como a referência não exige o `$CATALYST_SOURCE_DIR_` *artifact-name* prefixo na frente do `build-output` diretório, como acontecia em[Exemplo: referência de arquivos em vários artefatos](#workflows-working-artifacts-ex-ref-file). Isso ocorre porque há somente um item especificado em `Inputs`. **nota** Para ter mais informações sobre como referenciar arquivos, consulte [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). ``` Actions: BuildActionE: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART7 Files: - build-output/file7.txt BuildActionF: Identifier: aws/build@v1 Inputs: Artifacts: - ART7 Configuration: Steps: - run: cd build-output && cat file7.txt ``` ## Exemplo: referenciar um arquivo em um artefato quando um está presente WorkflowSource O exemplo a seguir mostra como gerar um artefato chamado `ART8` em `BuildActionG` e, depois, referenciar `file8.txt` (no artefato `ART8`) em `BuildActionH` (em `Steps`). Observe como a referência exige o `$CATALYST_SOURCE_DIR_` *artifact-name* prefixo, como aconteceu em[Exemplo: referência de arquivos em vários artefatos](#workflows-working-artifacts-ex-ref-file). Isso ocorre porque há vários itens especificados em `Inputs` (uma origem e um artefato), então você precisa do prefixo para indicar onde procurar o arquivo. **nota** Para ter mais informações sobre como referenciar arquivos, consulte [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). ``` Actions: BuildActionG: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART8 Files: - build-output/file8.txt BuildActionH: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Artifacts: - ART8 Configuration: Steps: - run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt ``` ## Exemplo: referência a um arquivo em um artefato quando um grupo de ações está presente O exemplo a seguir mostra como gerar um artefato chamado `ART9` em `ActionGroup1`, `ActionI`, e referenciar `file9.txt` (no artefato `ART9`) em `ActionJ`. Para ter mais informações sobre como referenciar arquivos, consulte [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). ``` Actions: ActionGroup1: Actions: ActionI: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART9 Files: - build-output/file9.yml ActionJ: Identifier: aws/cfn-deploy@v1 Inputs: Sources: - WorkflowSource Artifacts: - ART9 Configuration: template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml ``` # Definir um artefato de saída Use as instruções a seguir para definir um artefato que você deseja que uma CodeCatalyst ação da Amazon produza. Esse artefato então fica disponível para uso de outras ações. **nota** Nem todas as ações são compatíveis com artefatos de saída. Para determinar se sua ação é compatível, siga as instruções do editor visual a seguir e veja se a ação inclui um botão de **Artefatos de saída** na guia **Saídas**. Se ela incluir, significa que os artefatos de saída são compatíveis. ------ #### [ Visual ] **Para definir um artefato de saída usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação que produzirá o artefato. 1. Escolha a guia **Outputs**. 1. Em **Artefatos**, selecione **Adicionar artefato**. 1. Selecione **Adicionar artefato** e insira as informações nos campos, da seguinte maneira. **Nome do artefato de criação** Especifique o nome de um artefato gerado pela ação. Os nomes de artefato devem ser exclusivos em um fluxo de trabalho e estão limitados a caracteres alfanuméricos (a-z, A-Z, 0-9) e sublinhados (\$1). Espaços, hifens (-) e outros caracteres especiais não são permitidos. Não é possível usar aspas para habilitar espaços, hifens e outros caracteres especiais em nomes de artefato de saída. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **Arquivos produzidos por criação** Especifique os arquivos CodeCatalyst incluídos no artefato que é gerado pela ação. Esses arquivos são gerados pela ação do fluxo de trabalho quando ela é executada e também estão disponíveis no repositório de origem. Os caminhos de arquivo podem residir em um repositório de origem ou em um artefato de uma ação anterior e são relativos ao repositório de origem ou à raiz do artefato. É possível usar padrões glob para especificar caminhos. Exemplos: + Para especificar um único arquivo que esteja na raiz do local de compilação ou do local do repositório de origem, use `my-file.jar`. + Para especificar um único arquivo em um subdiretório, use `directory/my-file.jar` ou `directory/subdirectory/my-file.jar`. + Para especificar todos os arquivos, use `"**/*"`. O padrão glob `**` indica que corresponde a qualquer número de subdiretórios. + Para especificar todos os arquivos e diretórios em um diretório chamado `directory`, use `"directory/**/*"`. O padrão glob `**` indica que corresponde a qualquer número de subdiretórios. + Para especificar todos os arquivos em um diretório chamado `directory`, mas não em nenhum de seus subdiretórios, use `"directory/*"`. **nota** Se o caminho do arquivo incluir um ou mais asteriscos (`*`) ou outro caractere especial, coloque o caminho entre aspas duplas (`""`). Para ter mais informações sobre caracteres especiais, consulte [Diretrizes e convenções de sintaxe](workflow-reference.md#workflow.terms.syntax.conv). Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **nota** Talvez seja necessário adicionar um prefixo ao caminho do arquivo para indicar em qual artefato ou origem encontrá-lo. Para obter mais informações, consulte [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md) e [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como definir um artefato de saída usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma ação de fluxo de trabalho, adicione um código semelhante ao seguinte: ``` action-name: Outputs: Artifacts: - Name: artifact-name Files: - file-path-1 - file-path-2 ``` Para obter mais exemplos, consulte [Exemplos de artefatos](workflows-working-artifacts-ex.md). Para ter mais informações, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md) para sua ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Definir um artefato de entrada Se você quiser usar um artefato gerado por outra CodeCatalyst ação da Amazon, você deve especificá-lo como uma entrada para a ação atual. Talvez você possa especificar vários artefatos como entrada – isso depende da ação. Para ter mais informações, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md) para sua ação. **nota** Você não pode referenciar artefatos de outros fluxos de trabalho. Use as instruções a seguir para especificar um artefato de outra ação como entrada para a ação atual. **Pré-requisito** Antes de começar, certifique-se de ter gerado o artefato da outra ação. Para obter mais informações, consulte [Definir um artefato de saída](workflows-working-artifacts-output.md). A saída do artefato o torna disponível para uso de outras ações. ------ #### [ Visual ] **Para especificar um artefato como entrada para uma ação (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação onde deseja especificar um artefato como entrada. 1. Selecione **Entradas**. 1. Em **Artefatos – opcional**, faça o seguinte: Especifique artefatos de ações anteriores que você deseja fornecer como entrada para essa ação. Esses artefatos já devem estar definidos como artefatos de saída em ações anteriores. Se você não especificar nenhum artefato de entrada, deverá especificar pelo menos um repositório de origem em `action-name/Inputs/Sources`. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **nota** Se a lista suspensa **Artefatos – opcional** não estiver disponível (editor visual) ou se você receber erros ao validar o YAML (editor YAML), talvez seja porque a ação permite apenas uma entrada. Nesse caso, tente remover a entrada de origem. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como especificar um artefato como entrada para uma ação (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Na ação em que você deseja especificar o artefato como entrada, adicione um código semelhante ao seguinte: ``` action-name: Inputs: Artifacts: - artifact-name ``` Para obter mais exemplos, consulte [Exemplos de artefatos](workflows-working-artifacts-ex.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Referência de arquivos em um artefato Se você tem um arquivo que reside em um artefato e precisa se referir a esse arquivo em uma de suas ações de CodeCatalyst fluxo de trabalho da Amazon, conclua o procedimento a seguir. **nota** Consulte também [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md). ------ #### [ Visual ] *Não disponível. Escolha YAML para visualizar as instruções YAML.* ------ #### [ YAML ] **Para referenciar arquivos em um artefato (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Na ação em que você deseja fazer referência a um arquivo, adicione um código semelhante ao seguinte: ``` Actions: My-action: Inputs: Sources: - WorkflowSource Artifacts: - artifact-name Configuration: template: artifact-path/path/to/file.yml ``` No código anterior, substitua: + *artifact-name*com o nome do artefato. + *artifact-path*com um valor da tabela a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html) Para obter exemplos, consulte [Exemplos de artefatos](workflows-working-artifacts-ex.md). **nota** Você pode omitir *artifact-path* e apenas especificar o caminho do arquivo em relação ao diretório raiz do artefato se: A ação em que você está incluindo a referência inclui apenas um item abaixo de `Inputs` (por exemplo, inclui um artefato de entrada e nenhuma origem). O arquivo que você deseja referenciar reside na entrada primária. A *entrada primária* é `WorkflowSource`, ou o primeiro artefato de entrada listado, se não houver `WorkflowSource`. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Baixar artefatos Você pode baixar e inspecionar artefatos gerados por suas ações de fluxo de trabalho do Amazon CodeCatalyst para fins de solução de problemas. Há dois tipos de artefato que podem ser baixados: + **Artefatos de origem**: um artefato que contém um snapshot do conteúdo do repositório de origem tal como ele existia quando a execução foi iniciada. + **Artefatos do fluxo de trabalho**: um artefato definido na propriedade `Outputs` do arquivo de configuração do fluxo de trabalho. **Como baixar artefatos gerados pelo fluxo de trabalho** 1. Abra o console do CodeCatalyst em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Abaixo do nome do fluxo de trabalho, selecione **Execuções**. 1. Em **Histórico de execução**, na coluna **ID da execução**, escolha uma execução. Por exemplo, `Run-95a4d`. 1. Abaixo do nome da execução, selecione **Artefatos**. 1. Ao lado de um artefato, selecione **Baixar**. Um arquivo é baixado. Seu nome de arquivo consiste em sete caracteres aleatórios. 1. Extraia o arquivo usando um utilitário de extração de arquivos de sua escolha. # Especificação da versão da ação a ser usada Por padrão, quando você adiciona uma ação a um fluxo de trabalho, a Amazon CodeCatalyst adiciona a versão completa ao arquivo de definição do fluxo de trabalho usando o formato: `vmajor.minor.patch` Por exemplo: ``` My-Build-Action: Identifier: aws/build@v1.0.0 ``` Você pode encurtar a versão completa na propriedade `Identifier` para que o fluxo de trabalho sempre use a versão secundária ou de patch mais recente da ação. Por exemplo, se você especificar: ``` My-CloudFormation-Action: Identifier: aws/cfn-deploy@v1.0 ``` ... e a versão mais recente do patch for `1.0.4`, então a ação usará `1.0.4`. Se uma versão posterior for lançada, digamos `1.0.5`, a ação usará `1.0.5`. Se uma versão secundária for lançada, digamos `1.1.0`, a ação continuará usando `1.0.5`. Para receber instruções detalhadas sobre a especificação de versões, consulte um dos seguintes tópicos. Use as instruções a seguir para indicar qual versão de uma ação você deseja que seu fluxo de trabalho use. Especifique a versão principal ou secundária mais recente ou uma versão de patch específica. Recomendamos o uso da versão secundária ou de patch mais recente de uma ação. ------ #### [ Visual ] *Não disponível. Escolha YAML para visualizar as instruções YAML.* ------ #### [ YAML ] **Para configurar um fluxo de trabalho para usar a versão mais recente de uma ação ou uma versão de patch específica** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Encontre a ação cuja versão você deseja editar. 1. Encontre a propriedade `Identifier` da ação e defina a versão como uma das seguintes: + action-identifier @v *major* — Use essa sintaxe para que o fluxo de trabalho use uma versão principal específica e permita que as versões secundárias e de patch mais recentes sejam escolhidas automaticamente. + identificador de ação @v. *major* *minor*— Use essa sintaxe para que o fluxo de trabalho use uma versão secundária específica e permita que a versão mais recente do patch seja escolhida automaticamente. + identificador de ação @v. *major* *minor*. *patch* — Use essa sintaxe para que o fluxo de trabalho use uma versão de patch específica. **nota** Se não tiver certeza de qual versão está disponível, consulte [Lista das versões de ação disponíveis](workflows-action-versions-determine.md). **nota** Não é possível omitir a versão principal. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Lista das versões de ação disponíveis Use as instruções a seguir para determinar quais versões de uma ação estão disponíveis para você usar em um fluxo de trabalho. ------ #### [ Visual ] **Para determinar quais versões de ação estão disponíveis** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. Encontre a ação cujas versões você deseja visualizar: 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome de qualquer fluxo de trabalho ou crie um. Para ter informações sobre a criação de um fluxo de trabalho, consulte [Criação de um fluxo de trabalho](workflows-create-workflow.md). 1. Escolha **Editar**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. Na lista suspensa, escolha **Amazon CodeCatalyst** para visualizar ações CodeCatalyst, CodeCatalyst Labs e de terceiros, ou escolha **GitHub**visualizar ações selecionadas GitHub. 1. Pesquise uma ação e selecione seu nome. Não selecione o sinal de mais (**\$1**). Os detalhes sobre a ação são exibidos. 1. Na caixa de diálogo de detalhes da ação, no canto superior direito, selecione a lista suspensa **Versões** para ver uma lista das versões disponíveis da ação. ------ #### [ YAML ] *Não disponível. Selecione “visual” para visualizar as instruções do editor visual.* ------ # Visualizar o código-fonte de uma ação Visualize o código-fonte de uma ação para garantir que ela não contenha código arriscado, vulnerabilidades de segurança ou outros defeitos. Use as instruções a seguir para visualizar o código-fonte de uma ação [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), do [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) ou [de terceiros](workflows-actions.md#workflows-actions-types-3p). **nota** Para ver o código-fonte de uma [GitHubação](workflows-actions.md#workflows-actions-types-github), acesse a página da ação no [GitHub Marketplace](https://github.com/marketplace/actions). A página inclui um link para o repositório da ação, onde você pode encontrar o código-fonte da ação. **nota** Você não pode visualizar o código-fonte das seguintes CodeCatalyst ações: [compilar](build-workflow-actions.md), [testar](test-workflow-actions.md), [GitHub Ações](integrations-github-action-add.md). **nota** AWS não suporta nem garante o código de ação de GitHub ações ou ações de terceiros. **Como visualizar o código-fonte de uma ação** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. Encontre a ação cujo código você deseja visualizar: 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome de qualquer fluxo de trabalho ou crie um. Para ter informações sobre a criação de um fluxo de trabalho, consulte [Criação de um fluxo de trabalho](workflows-create-workflow.md). 1. Escolha **Editar**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. Na lista suspensa, escolha **Amazon CodeCatalyst** para visualizar CodeCatalyst, CodeCatalyst Labs e ações de terceiros. 1. Pesquise uma ação e selecione seu nome. Não selecione o sinal de mais (**\$1**). Os detalhes sobre a ação são exibidos. 1. Na caixa de diálogo de detalhes da ação, na parte inferior, selecione **Download**. Uma página é exibida com o bucket do Amazon S3 em que o código-fonte da ação está localizado. Para ter informações sobre o Amazon S3, consulte [O que é o Amazon S3?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) no *Guia do usuário do Amazon Simple Storage Service*. 1. Inspecione o código para garantir que ele atenda às suas expectativas de qualidade e segurança. # Integração com GitHub ações Uma *GitHub ação* é muito parecida com uma [CodeCatalyst ação](workflows-actions.md#workflows-actions-types-cc), exceto pelo fato de ter sido desenvolvida para uso com GitHub fluxos de trabalho. Para obter detalhes sobre GitHub ações, consulte a documentação de [GitHub ações](https://docs.github.com/en/actions). Você pode usar GitHub ações junto com CodeCatalyst ações nativas em um CodeCatalyst fluxo de trabalho. Há duas maneiras de adicionar uma GitHub ação a um CodeCatalyst fluxo de trabalho: + Você pode selecionar a GitHub Ação em uma lista organizada no CodeCatalyst console. Várias GitHub ações populares estão disponíveis. Para obter mais informações, consulte [Adicionando uma ação com curadoria GitHub](integrations-github-action-add-curated.md). + Se a GitHub Ação que você deseja usar não estiver disponível no CodeCatalyst console, você poderá adicioná-la usando uma ação **GitHub Ações**. Uma ação de ***GitHub ações*** é uma *CodeCatalyst ação* que envolve uma GitHub ação e a torna compatível com CodeCatalyst fluxos de trabalho. Aqui está um exemplo de uma ação de **GitHub ações** envolvendo a ação [ GitHubSuper-Linter](https://github.com/marketplace/actions/super-linter): ``` Actions: GitHubAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: "true" DEFAULT_BRANCH: main ``` No código anterior, a ação CodeCatalyst **GitHub Actions** (identificada por`aws/github-actions-runner@v1`) envolve a ação Super-Linter (identificada por`github/super-linter@v4`), fazendo com que ela funcione em um fluxo de trabalho. CodeCatalyst Para obter mais informações, consulte [Adicionando a GitHub ação 'Ações'](integrations-github-action-add.md). Todas as GitHub ações, curadas ou não, devem ser agrupadas dentro de uma ação **GitHub Actions** (`aws/github-actions-runner@v1`), conforme mostrado no exemplo anterior. O invólucro é necessário para a ação funcionar bem. **Topics** + [ ## Como as GitHub ações são diferentes das CodeCatalyst ações? ](#integrations-github-actions-how-different) + [ ## GitHub As ações podem interagir com outras CodeCatalyst ações no fluxo de trabalho? ](#integrations-github-actions-interactions.title) + [ ## Quais GitHub ações posso usar? ](#integrations-github-actions-supported) + [ ## GitHub Limitações das ações em CodeCatalyst ](#integrations-github-actions-limitations) + [ ## Como adiciono uma GitHub ação (etapas de alto nível)? ](#integrations-github-actions-how-to) + [ ## A GitHub ação é executada GitHub? ](#integrations-github-actions-where-it-runs) + [ ## Também posso usar GitHub fluxos de trabalho? ](#integrations-github-actions-workflows-support.title) + [ ## Imagem de tempo de execução usada pela GitHub ação 'Ações' ](#integrations-github-actions-runtime) + [ # Tutorial: código Lint usando uma GitHub ação ](integrations-github-action-tutorial.md) + [ # Adicionando a GitHub ação 'Ações' ](integrations-github-action-add.md) + [ # Adicionando uma ação com curadoria GitHub ](integrations-github-action-add-curated.md) + [ # Exportação dos parâmetros de saída do GitHub ](integrations-github-action-export.md) + [ # Referenciando parâmetros GitHub de saída ](integrations-github-action-referencing.md) + [ # GitHub Ação 'Ações' YAML ](github-action-ref.md) ## Como as GitHub ações são diferentes das CodeCatalyst ações? GitHub As ações usadas em um CodeCatalyst fluxo de trabalho não têm o mesmo nível de acesso e integração com AWS CodeCatalyst recursos (como [ambientes](deploy-environments.md) e [problemas](issues.md)) que CodeCatalyst as ações. ## GitHub As ações podem interagir com outras CodeCatalyst ações no fluxo de trabalho? Sim. Por exemplo, GitHub as ações podem usar variáveis produzidas por outras CodeCatalyst ações como entrada e também podem compartilhar parâmetros de saída e artefatos com CodeCatalyst ações. Para obter mais informações, consulte [Exportação dos parâmetros de saída do GitHub](integrations-github-action-export.md) e [Referenciando parâmetros GitHub de saída](integrations-github-action-referencing.md). ## Quais GitHub ações posso usar? Você pode usar qualquer GitHub ação disponível no CodeCatalyst console e qualquer GitHub ação disponível no [GitHubMarketplace](https://github.com/marketplace/actions). Se você decidir usar uma GitHub Ação do Marketplace, tenha em mente as seguintes [limitações](#integrations-github-actions-limitations). ## GitHub Limitações das ações em CodeCatalyst + GitHub As ações não podem ser usadas com o tipo de [computação CodeCatalyst Lambda](workflows-working-compute.md#compute.types). + GitHub As ações são executadas na imagem Docker do ambiente de execução de [novembro de 2022](build-images.md#build.previous-image), que inclui ferramentas mais antigas. Para ter mais informações sobre a imagem e as ferramentas, consulte [Especificação de imagens de ambiente de runtime](build-images.md). + GitHub Ações que dependem internamente do [`github`contexto](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context) ou em que recursos GitHub específicos de referência não funcionarão. CodeCatalyst Por exemplo, as ações a seguir não funcionarão em CodeCatalyst: + Ações que tentam adicionar, alterar ou atualizar GitHub recursos. Os exemplos incluem ações que atualizam pull requests ou criam problemas no GitHub. + Quase todas as ações estão listadas em [https://github.com/actions.](https://github.com/actions) + GitHub As ações que são [ações de contêiner do Docker](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions) funcionarão, mas devem ser executadas pelo usuário padrão do Docker (root). Não execute a ação como usuário 1001. (No momento em que este artigo foi escrito, o usuário 1001 trabalhava no GitHub, mas não no CodeCatalyst.) Para obter mais informações, consulte o tópico [USUÁRIO](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user) em [Suporte do Dockerfile para GitHub ações](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions). Para obter uma lista das GitHub ações disponíveis por meio do CodeCatalyst console, consulte[Adicionando uma ação com curadoria GitHub](integrations-github-action-add-curated.md). ## Como adiciono uma GitHub ação (etapas de alto nível)? As etapas de alto nível para adicionar uma GitHub ação a um CodeCatalyst fluxo de trabalho são as seguintes: 1. No seu CodeCatalyst projeto, você **cria um fluxo de trabalho**. No fluxo de trabalho, você define como criar, testar e implantar a aplicação. Para obter mais informações, consulte [Conceitos básicos de fluxos de trabalho](workflows-getting-started.md). 1. No fluxo de trabalho, você **adiciona uma GitHub ação com curadoria** ou **adiciona a ação GitHub Ações**. 1. Realize uma das seguintes ações: + Se você optar por adicionar uma ação selecionada, configure-a. Para obter mais informações, consulte [Adicionando uma ação com curadoria GitHub](integrations-github-action-add-curated.md). + Se você optar por adicionar uma ação não curada, na ação **GitHubAções**, **cole o código YAML da GitHub Ação**. Você pode encontrar esse código na página de detalhes da GitHub Ação escolhida no [GitHubMarketplace](https://github.com/marketplace/actions). Provavelmente, você precisará modificar um pouco o código para que ele funcione CodeCatalyst. Para obter mais informações, consulte [Adicionando a GitHub ação 'Ações'](integrations-github-action-add.md). 1. (Opcional) No fluxo de trabalho, **adicione outras ações**, como as ações de criação e teste. Para obter mais informações, consulte [Compilação, teste e implantação com fluxos de trabalhoCompilação, teste e implantação com fluxos de trabalho](workflow.md). 1. Você **inicia o fluxo de trabalho** manual ou automaticamente por meio de um gatilho. O fluxo de trabalho executa a GitHub Ação e quaisquer outras ações no fluxo de trabalho. Para obter mais informações, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md). Para saber detalhes das etapas, consulte: + [Adicionando uma ação com curadoria GitHub](integrations-github-action-add-curated.md). + [Adicionando a GitHub ação 'Ações'](integrations-github-action-add.md). ## A GitHub ação é executada GitHub? Não. A GitHub ação é executada em CodeCatalyst, usando a [imagem CodeCatalyst do ambiente de tempo de execução](workflows-working-compute.md). ## Também posso usar GitHub fluxos de trabalho? Não. ## Imagem de tempo de execução usada pela GitHub ação 'Ações' A ação CodeCatalyst **GitHub Ações** é executada em uma [imagem de novembro de 2022](build-images.md#build.previous-image). Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). # Tutorial: código Lint usando uma GitHub ação Neste tutorial, você adiciona a [ GitHub ação Super-Linter](https://github.com/marketplace/actions/super-linter) a um fluxo de trabalho da Amazon CodeCatalyst . A ação Super-Linter inspeciona o código, encontra áreas em que o código tem erros, problemas de formatação e construções suspeitas e, em seguida, envia os resultados para o console). CodeCatalyst Depois de adicionar o linter ao fluxo de trabalho, você executa o fluxo de trabalho para aplicar o código lint a uma aplicação Node.js de exemplo (`app.js`). Depois, você corrige os problemas relatados e executa o fluxo de trabalho novamente para ver se as correções funcionaram. **dica** Pense em usar o Super-Linter para aplicar o código lint a arquivos YAML, como [modelos do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html). **Topics** + [ ## Pré-requisitos ](#integrations-github-action-tutorial-prereqs) + [ ## Etapa 1: criar um repositório de origem ](#integrations-github-action-tutorial-create-source-repo) + [ ## Etapa 2: adicionar um arquivo app.js ](#integrations-github-action-tutorial-add-appjs) + [ ## Etapa 3: criar um fluxo de trabalho que execute a ação Super-Linter ](#integrations-github-action-tutorial-create-workflow) + [ ## Etapa 4: corrigir problemas encontrados pelo Super-Linter ](#integrations-github-action-tutorial-fix-probs) + [ ## Limpeza ](#integrations-github-action-tutorial-cleanup) ## Pré-requisitos Antes de começar, você precisa de: + Um CodeCatalyst **espaço** com um conectado Conta da AWS. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). + Um projeto vazio em seu CodeCatalyst espaço chamado`codecatalyst-linter-project`. Selecione a opção **Começar do zero** para criar esse projeto. ``` ``` Para obter mais informações, consulte [Criando um projeto vazio na Amazon CodeCatalyst](projects-create.md#projects-create-empty). ## Etapa 1: criar um repositório de origem Nesta etapa, você cria um repositório de origem no CodeCatalyst. Você usará esse repositório para armazenar o arquivo de origem da aplicação de exemplo, `app.js`, para este tutorial. Para ter mais informações sobre repositórios de origem, consulte [Criar um repositório de origem](source-repositories-create.md). **Como criar um repositório de origem** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Navegue até o projeto, `codecatalyst-linter-project`. 1. No painel de navegação, selecione **Código** e, em seguida, selecione **Repositórios de origem**. 1. Escolha **Adicionar repositório** e selecione **Criar repositório**. 1. Em **Nome do repositório**, insira: ``` codecatalyst-linter-source-repository ``` 1. Escolha **Criar**. ## Etapa 2: adicionar um arquivo app.js Nesta etapa, você vai adicionar um arquivo `app.js` ao repositório de origem. O `app.js` contém um código de função que contém alguns erros que o linter encontrará. **Para adicionar o arquivo app.js** 1. No CodeCatalyst console, escolha seu projeto,`codecatalyst-linter-project`. 1. No painel de navegação, selecione **Código** e, depois, selecione **Repositórios de origem**. 1. Na lista de repositórios de origem, escolha o seu repositório, `codecatalyst-linter-source-repository`. 1. Em **Arquivos**, selecione **Criar arquivo**. 1. Na caixa de texto, insira o código a seguir: ``` // const axios = require('axios') // const url = 'http://checkip.amazonaws.com/'; let response; /** * * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format * @param {Object} event - API Gateway Lambda Proxy Input Format * * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html * @param {Object} context * * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html * @returns {Object} object - API Gateway Lambda Proxy Output Format * */ exports.lambdaHandler = async (event, context) => { try { // const ret = await axios(url); response = { statusCode: 200, 'body': JSON.stringify({ message: 'hello world' // location: ret.data.trim() }) } } catch (err) { console.log(err) return err } return response } ``` 1. Em **Nome do arquivo**, insira `app.js`. Mantenha as outras opções padrão. 1. Selecione **Confirmar**. Agora você criou um chamado `app.js`. ## Etapa 3: criar um fluxo de trabalho que execute a ação Super-Linter Nesta etapa, você vai criar um fluxo de trabalho que executa a ação Super-Linter ao enviar código para o repositório de origem. O fluxo de trabalho consiste nos seguintes componentes, que você define em um arquivo YAML: + **Um gatilho** – Esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + **Uma ação “GitHub Ações”** — No gatilho, a ação **GitHub Ações** executa a ação Super-Linter, que por sua vez inspeciona todos os arquivos em seu repositório de origem. Se o linter encontrar um problema, a ação do fluxo de trabalho falhará. **Para criar um fluxo de trabalho que execute a ação Super-Linter** 1. No CodeCatalyst console, escolha seu projeto,`codecatalyst-linter-project`. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho**. 1. Em **Repositório de origem**, selecione `codecatalyst-linter-source-repository`. 1. Em **Ramificação**, selecione `main`. 1. Escolha **Criar**. 1. Exclua o código de amostra YAML. 1. Adicione o seguinte YAML: ``` Name: codecatalyst-linter-workflow SchemaVersion: "1.0" Triggers: - Type: PUSH Branches: - main Actions: SuperLinterAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: github-action-code ``` No código anterior, *github-action-code* substitua pelo código de ação Super-Linter, conforme instruído nas etapas a seguir deste procedimento. 1. Acesse a [página Super-Linter](https://github.com/marketplace/actions/super-linter) no Marketplace GitHub . 1. Em `steps:` (minúsculas), localize o código e cole-o no CodeCatalyst fluxo de trabalho em `Steps:` (maiúsculas). Ajuste o código de GitHub ação para se adequar aos CodeCatalyst padrões, conforme mostrado no código a seguir. Seu CodeCatalyst fluxo de trabalho agora tem a seguinte aparência: ``` Name: codecatalyst-linter-workflow SchemaVersion: "1.0" Triggers: - Type: PUSH Branches: - main Actions: SuperLinterAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: "true" DEFAULT_BRANCH: main ``` 1. (Opcional) Selecione **Validar** para garantir que o código YAML seja válido antes de confirmar. 1. Selecione **Confirmar**, insira uma **Mensagem de confirmação**, escolha seu **repositório** do `codecatalyst-linter-source-repository` e selecione **Confirmar** novamente. Agora você criou um fluxo de trabalho. A execução de um fluxo de trabalho é iniciada automaticamente devido ao gatilho definido na parte superior do fluxo de trabalho. **Para visualizar a execução do fluxo de trabalho em andamento** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Escolha o fluxo de trabalho que você acabou de criar: `codecatalyst-linter-workflow`. 1. No diagrama do fluxo de trabalho, escolha **SuperLinterAction**. 1. Aguarde a falha da ação. Essa falha é esperada porque o linter encontrou problemas no código. 1. Deixe o CodeCatalyst console aberto e vá para[Etapa 4: corrigir problemas encontrados pelo Super-Linter](#integrations-github-action-tutorial-fix-probs). ## Etapa 4: corrigir problemas encontrados pelo Super-Linter O Super-Linter deve ter encontrado problemas no código `app.js`, bem como no arquivo `README.md` incluído no seu repositório de origem. **Para corrigir os problemas encontrados pelo linter** 1. No CodeCatalyst console, escolha a guia **Logs** e, em seguida, escolha **Lint Code Base**. Os logs gerados pela ação Super-Linter são exibidos. 1. Nos logs do Super-Linter, role para baixo até a linha 90, onde você encontra o início dos problemas. Eles são semelhantes a: ``` /github/workspace/hello-world/app.js:3:13: Extra semicolon. /github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed. /github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found. /github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4. /github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found. ``` 1. Corrija `app.js` e `README.md` no repositório de origem e confirme as alterações. **dica** Para corrigir o `README.md`, adicione `markdown` ao bloco de código, assim: ``` ```markdown Setup examples: ... ``` ``` Suas alterações iniciam outro fluxo de trabalho executado automaticamente. Aguarde a conclusão do fluxo de trabalho. Se você corrigiu todos os problemas, o fluxo de trabalho deverá ser bem-sucedido. ## Limpeza Faça uma limpeza CodeCatalyst para remover vestígios deste tutorial do seu ambiente. **Para limpar CodeCatalyst** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Exclua `codecatalyst-linter-source-repository`. 1. Exclua `codecatalyst-linter-workflow`. Neste tutorial, você aprendeu como adicionar a GitHub ação Super-Linter a um CodeCatalyst fluxo de trabalho para codificar alguns códigos. # Adicionando a GitHub ação 'Ações' Uma ação de ***GitHub ações*** é uma *CodeCatalyst ação* que envolve uma GitHub ação e a torna compatível com CodeCatalyst fluxos de trabalho. Para obter mais informações, consulte [Integração com GitHub ações](integrations-github-actions.md). Para adicionar a ação **GitHub Ações** a um fluxo de trabalho, siga estas etapas. **dica** Para obter um tutorial que mostra como usar a ação **GitHub Ações**, consulte[Tutorial: código Lint usando uma GitHub ação](integrations-github-action-tutorial.md). ------ #### [ Visual ] **Para adicionar a GitHub ação 'Ações' usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. Na lista suspensa, escolha. **GitHub** 1. Pesquise a ação **GitHub Ações** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Escolha **GitHub Ações**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [GitHub Ação 'Ações' YAML](github-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar a GitHub ação 'Ações' usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. Na lista suspensa, escolha. **GitHub** 1. Pesquise a ação **GitHub Ações** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Escolha **GitHub Ações**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [GitHub Ação 'Ações' YAML](github-action-ref.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ ## Definição da GitHub ação “Ações” A ação **GitHub Ações** é definida como um conjunto de propriedades YAML dentro do seu arquivo de definição de fluxo de trabalho. Para ter mais informações sobre essas propriedades, consulte [GitHub Ação 'Ações' YAML](github-action-ref.md) em [Definição do YAML do fluxo de trabalho](workflow-reference.md). # Adicionando uma ação com curadoria GitHub Uma * GitHub ação com curadoria* é uma GitHub ação que é disponibilizada no CodeCatalyst console e serve como um exemplo de como usar uma GitHub ação dentro de um CodeCatalyst fluxo de trabalho. GitHub As ações selecionadas são agrupadas na [ação de **GitHub ações CodeCatalyst**](integrations-github-action-add.md) de autoria, identificada pelo identificador. `aws/github-actions-runner@v1` Por exemplo, aqui está a aparência da GitHub Ação, [TruffleHog OSS](https://github.com/marketplace/actions/trufflehog-oss), com curadoria: ``` Actions: TruffleHogOSS_e8: Identifier: aws/github-actions-runner@v1 Inputs: Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Configuration: Steps: - uses: trufflesecurity/trufflehog@v3.16.0 with: path: ' ' # Required; description: Repository path base: ' ' # Required; description: Start scanning from here (usually main branch). head: ' ' # Optional; description: Scan commits until here (usually dev branch). extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli. ``` No código anterior, a ação CodeCatalyst **GitHub Ações** (identificada por`aws/github-actions-runner@v1`) envolve a ação TruffleHog OSS (identificada por`trufflesecurity/trufflehog@v3.16.0`), fazendo com que ela funcione em um CodeCatalyst fluxo de trabalho. Para configurar essa ação, você substituiria as strings vazias em `with:` por seus próprios valores. Por exemplo: ``` Actions: TruffleHogOSS_e8: Identifier: aws/github-actions-runner@v1 Inputs: Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Configuration: Steps: - uses: trufflesecurity/trufflehog@v3.16.0 with: path: ./ base: main # Required; description: Start scanning from here (usually main branch). head: HEAD # Optional; description: Scan commits until here (usually dev branch). extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli. ``` Para adicionar uma GitHub ação organizada a um fluxo de trabalho, use o procedimento a seguir. Para obter informações gerais sobre o uso de GitHub ações em um CodeCatalyst fluxo de trabalho, consulte[Integração com GitHub ações](integrations-github-actions.md). **nota** Se você não vê sua GitHub Ação na lista de ações selecionadas, você ainda pode adicioná-la ao seu fluxo de trabalho usando a ação **GitHub Ações**. Para obter mais informações, consulte [Adicionando a GitHub ação 'Ações'](integrations-github-action-add.md). ------ #### [ Visual ] **Para adicionar uma GitHub ação com curadoria usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. Na lista suspensa, escolha. **GitHub** 1. Procure ou pesquise uma GitHub ação e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Escolha o nome da GitHub ação. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas**, **Configuração** e **Saídas**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [GitHub Ação 'Ações' YAML](github-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) disponível para a ação **GitHubAções**, conforme aparece nos editores YAML e visual. Para obter informações sobre as opções de configuração disponíveis para a GitHub Ação selecionada, consulte sua documentação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar uma GitHub ação com curadoria usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. Na lista suspensa, escolha. **GitHub** 1. Procure ou pesquise uma GitHub ação e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Escolha o nome da GitHub ação. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível para a ação **GitHub Ações** é fornecida no[GitHub Ação 'Ações' YAML](github-action-ref.md). Para obter informações sobre as opções de configuração disponíveis para a GitHub Ação selecionada, consulte sua documentação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Exportação dos parâmetros de saída do GitHub Você pode usar os [parâmetros de saída do GitHub](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter) nos fluxos de trabalho do CodeCatalyst. **nota** Outra palavra para *parâmetro de saída* é *variável*. Como o GitHub usa o termo *parâmetro de saída* na documentação, também usaremos esse termo. Use as instruções a seguir para exportar um parâmetro de saída do GitHub de uma ação do GitHub para que ele fique disponível para uso por outras ações do fluxo de trabalho do CodeCatalyst. **Para exportar um parâmetro de saída do GitHub** 1. Abra um fluxo de trabalho e selecione **Editar**. Para obter mais informações, consulte [Criação de um fluxo de trabalho](workflows-create-workflow.md). 1. Na ação **GitHub Actions** que gera o parâmetro de saída que você deseja exportar, adicione uma seção c`Outputs` om uma propriedade `Variables` subjacente semelhante a esta: ``` Actions: MyGitHubAction: Identifier: aws/github-actions-runner@v1 Outputs: Variables: - 'step-id_output-name' ``` Substitua: + *step-id* pelo valor da propriedade `id:` na seção `steps` da ação do GitHub. + *output-name* pelo nome do parâmetro de saída do GitHub. **Exemplo** O exemplo a seguir mostra como exportar um parâmetro de saída do GitHub chamado `SELECTEDCOLOR`. ``` Actions: MyGitHubAction: Identifier: aws/github-actions-runner@v1 Outputs: Variables: - 'random-color-generator_SELECTEDCOLOR' Configuration: Steps: - name: Set selected color run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT id: random-color-generator ``` # Referenciando parâmetros GitHub de saída Use as instruções a seguir para referenciar um parâmetro GitHub de saída. **Para referenciar um parâmetro GitHub de saída** 1. Siga as etapas em [Exportação dos parâmetros de saída do GitHub](integrations-github-action-export.md). O parâmetro GitHub de saída agora está disponível para uso em outras ações. 1. Observe o valor `Variables` do parâmetro de saída. Inclui um sublinhado (\$1). 1. Consulte o parâmetro de saída usando a seguinte sintaxe: ``` ${action-name.output-name} ``` Substitua: + *action-name*com o nome da CodeCatalyst **GitHub ação** que produz o parâmetro de saída (não use o `name` ou da GitHub ação`id`). + *output-name*com o `Variables` valor do parâmetro de saída que você anotou anteriormente. **Exemplo** ``` BuildActionB: Identifier: aws/build@v1 Configuration: Steps: - Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR} ``` **Exemplo com contexto** O exemplo a seguir mostra como definir uma variável `SELECTEDCOLOR` em `GitHubActionA`, exibi-la e, depois, referenciá-la em `BuildActionB`. ``` Actions: GitHubActionA: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Set selected color run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT id: random-color-generator Outputs: Variables: - 'random-color-generator_SELECTEDCOLOR' BuildActionB: Identifier: aws/build@v1 Configuration: Steps: - Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR} ``` # GitHub Ação 'Ações' YAML A seguir está a definição YAML da ação **GitHubAções**. Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). Escolha uma propriedade YAML no código a seguir para ver uma descrição dela. **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. action-name: Identifier: aws/github-actions-runner@v1 DependsOn: - dependent-action-name-1 Compute: Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Inputs: Sources: - source-name-1 - source-name-2 Artifacts: - artifact-name Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Outputs: Artifacts: - Name: output-artifact-1 Files: - github-output/artifact-1.jar - "github-output/build*" - Name: output-artifact-2 Files: - github-output/artifact-2.1.jar - github-output/artifact-2.2.jar Variables: - variable-name-1 - variable-name-2 AutoDiscoverReports: Enabled: true | false ReportNamePrefix: AutoDiscovered IncludePaths: - "**/*" ExcludePaths: - node_modules/cdk/junit.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL Number: whole-number Reports: report-name-1: Format: format IncludePaths: - "*.xml" ExcludePaths: - report2.xml - report3.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL Number: whole-number Configuration Steps: - github-actions-code ``` ## action-name (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. UI correspondente: guia Configuração/ *action-name* ## Identifier (*action-name*/**Identifier**) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Use `aws/github-actions-runner@v1` para **GitHubações** de ações. UI correspondente: diagrama de fluxo de trabalho//*action-name***aws/ @v1 label github-actions-runner** ## DependsOn (*action-name*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*action-name*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Fleet (*action-name*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. Interface de usuário correspondente: guia Configuração/**Frota de computação - opcional** ## Timeout (*action-name*/**Timeout**) (Optional) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Environment (*action-name*/**Environment**) (Optional) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*action-name*/Environment/**Name**) (Obrigatório se [Environment](#github.environment) for incluído) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*action-name*/Environment/**Connections**) (Optional) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). UI correspondente: a configuração tab/Environment/What está pronta*my-environment*? **/menu de três pontos/ Mudar função** ## Name (*action-name*/Environment/Connections/**Name**) (Obrigatório se [Connections](#github.environment.connections) for incluído) Especifique o nome da conexão da conta. UI correspondente: a configuração tab/Environment/What está pronta*my-environment*? **/menu de três pontos/ Mudar função** ## Role (*action-name*/Environment/Connections/**Role**) (Obrigatório se [Connections](#github.environment.connections) for incluído) Especifique o nome do perfil do IAM que essa ação usa para acessar e operar em serviços da AWS , como o Amazon S3 e o Amazon ECR. Esse perfil deve ser adicionado à conexão da Conta da AWS no espaço. Para adicionar um perfil do IAM a uma conexão de conta, consulte [Adicionar perfis do IAM às conexões da conta](ipa-connect-account-addroles.md). Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas a seguir. **nota** É possível usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação. Para obter mais informações sobre essa função, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. **Atenção** Limite as permissões às exigidas pela **GitHub ação** Ação. Usar um perfil com permissões mais amplas pode representar um risco de segurança. UI correspondente: a configuração tab/Environment/What está pronta*my-environment*? **/menu de três pontos/ Mudar função** ## Inputs (*action-name*/**Inputs**) (Optional) A seção `Inputs` define os dados de que uma ação precisa durante a execução de um fluxo de trabalho. **nota** São permitidas no máximo quatro entradas (uma fonte e três artefatos) por **GitHub ação de Ações**. As variáveis não são contadas nesse total. Se você precisar consultar arquivos que residem em entradas diferentes (digamos, uma origem e um artefato), a entrada de origem será a entrada primária e o artefato será a entrada secundária. As referências a arquivos em entradas secundárias usam um prefixo especial para diferirem das primárias. Para obter detalhes, consulte [Exemplo: referência de arquivos em vários artefatos](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file). Interface de usuário correspondente: guia **Entradas** ## Sources (*action-name*/Inputs/**Sources**) (Optional) Especifique os rótulos que representam os repositórios de origem que serão necessários para a ação. Atualmente, o único rótulo compatível é `WorkflowSource`, que representa o repositório de origem em que o arquivo de definição de fluxo de trabalho está armazenado. Se você omitir uma origem, deverá especificar pelo menos um artefato de entrada em `action-name/Inputs/Artifacts`. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*action-name*/Inputs/**Artifacts**) (Optional) Especifique artefatos de ações anteriores que você deseja fornecer como entrada para essa ação. Esses artefatos já devem estar definidos como artefatos de saída em ações anteriores. Se você não especificar nenhum artefato de entrada, deverá especificar pelo menos um repositório de origem em `action-name/Inputs/Sources`. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **nota** Se a lista suspensa **Artefatos – opcional** não estiver disponível (editor visual) ou se você receber erros ao validar o YAML (editor YAML), talvez seja porque a ação permite apenas uma entrada. Nesse caso, tente remover a entrada de origem. Interface de usuário correspondente: guia Entradas/**Artefatos - opcional** ## Variables - input (*action-name*/Inputs/**Variables**) (Optional) Especifique uma sequência de name/value pares que defina as variáveis de entrada que você deseja disponibilizar para a ação. Os nomes de variável são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de variável. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Interface de usuário correspondente: guia Entradas/**Variáveis - opcional** ## Outputs (*action-name*/**Outputs**) (Optional) Define os dados que são gerados pela ação durante a execução de um fluxo de trabalho. Interface de usuário correspondente: guia **Saídas** ## Artifacts - output (*action-name*/Outputs/**Artifacts**) (Optional) Especifique o nome de um artefato gerado pela ação. Os nomes de artefato devem ser exclusivos em um fluxo de trabalho e estão limitados a caracteres alfanuméricos (a-z, A-Z, 0-9) e sublinhados (\$1). Espaços, hifens (-) e outros caracteres especiais não são permitidos. Não é possível usar aspas para habilitar espaços, hifens e outros caracteres especiais em nomes de artefato de saída. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Saídas/**Artefatos** ## Name (*action-name*/Outputs/Artifacts/**Name**) (Obrigatório se [Artifacts - output](#github.outputs.artifacts) for incluído) Especifique o nome de um artefato gerado pela ação. Os nomes de artefato devem ser exclusivos em um fluxo de trabalho e estão limitados a caracteres alfanuméricos (a-z, A-Z, 0-9) e sublinhados (\$1). Espaços, hifens (-) e outros caracteres especiais não são permitidos. Não é possível usar aspas para habilitar espaços, hifens e outros caracteres especiais em nomes de artefato de saída. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **UI correspondente: artefato de tab/Artifacts/Add saída/Nome do artefato de construção** ## Files (*action-name*/Outputs/Artifacts/**Files**) (Obrigatório se [Artifacts - output](#github.outputs.artifacts) for incluído) Especifique os arquivos CodeCatalyst incluídos no artefato que é gerado pela ação. Esses arquivos são gerados pela ação do fluxo de trabalho quando ela é executada e também estão disponíveis no repositório de origem. Os caminhos de arquivo podem residir em um repositório de origem ou em um artefato de uma ação anterior e são relativos ao repositório de origem ou à raiz do artefato. É possível usar padrões glob para especificar caminhos. Exemplos: + Para especificar um único arquivo que esteja na raiz do local de compilação ou do local do repositório de origem, use `my-file.jar`. + Para especificar um único arquivo em um subdiretório, use `directory/my-file.jar` ou `directory/subdirectory/my-file.jar`. + Para especificar todos os arquivos, use `"**/*"`. O padrão glob `**` indica que corresponde a qualquer número de subdiretórios. + Para especificar todos os arquivos e diretórios em um diretório chamado `directory`, use `"directory/**/*"`. O padrão glob `**` indica que corresponde a qualquer número de subdiretórios. + Para especificar todos os arquivos em um diretório chamado `directory`, mas não em nenhum de seus subdiretórios, use `"directory/*"`. **nota** Se o caminho do arquivo incluir um ou mais asteriscos (`*`) ou outro caractere especial, coloque o caminho entre aspas duplas (`""`). Para ter mais informações sobre caracteres especiais, consulte [Diretrizes e convenções de sintaxe](workflow-reference.md#workflow.terms.syntax.conv). Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). **nota** Talvez seja necessário adicionar um prefixo ao caminho do arquivo para indicar em qual artefato ou origem encontrá-lo. Para obter mais informações, consulte [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md) e [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). **UI correspondente: produz tab/Artifacts/Add artefatos/arquivos produzidos pela compilação** ## Variables - output (*action-name*/Outputs/**Variables**) (Optional) Especifique as variáveis que você deseja que a ação exporte para que estejam disponíveis para uso em ações subsequentes. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Interface de usuário correspondente: guia Saídas/Variáveis/**Adicionar variável** ## variable-name-1 (nome da *action-name* /Outputs/Variables **variável-1**) (Optional) Especifique o nome de uma variável a ser exportada pela ação. Essa variável já deve estar definida na seção `Inputs` ou `Steps` da mesma ação. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **UI correspondente: tab/Variables/Add Variável de saída/nome** ## AutoDiscoverReports (*action-name*/Outputs/**AutoDiscoverReports**) (Optional) Define a configuração do recurso de descoberta automática. Quando você ativa a descoberta automática, CodeCatalyst pesquisa todos os dados `Inputs` passados para a ação, bem como todos os arquivos gerados pela própria ação, procurando relatórios de teste, cobertura de código e análise de composição de software (SCA). Para cada relatório encontrado, ele é CodeCatalyst transformado em um CodeCatalyst relatório. Um *CodeCatalyst relatório* é um relatório totalmente integrado ao CodeCatalyst serviço e que pode ser visualizado e manipulado por meio do CodeCatalyst console. **nota** Por padrão, o recurso de descoberta automática inspeciona todos os arquivos. É possível limitar quais arquivos são inspecionados usando as propriedades [IncludePaths](#github.reports.includepaths) ou [ExcludePaths](#github.reports.excludepaths). Interface de usuário correspondente: *nenhuma* ## Enabled (*action-name*/Outputs/AutoDiscoverReports/**Enabled**) (Optional) Habilite ou desabilite o recurso de descoberta automática. Os valores válidos são `true` ou `false`. Se `Enabled` for omitido, o padrão será `true`. Interface de usuário correspondente: guia Saídas/Relatórios/**Relatórios de descoberta automática** ## ReportNamePrefix (*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**) (Obrigatório se [AutoDiscoverReports](#github.outputs.autodiscover) estiver incluído e habilitado) Especifique um prefixo que seja CodeCatalyst anexado a todos os relatórios encontrados para nomear seus relatórios associados. CodeCatalyst Por exemplo, se você especificar um prefixo de`AutoDiscovered`, e CodeCatalyst descobrir automaticamente dois relatórios de teste, `TestSuiteOne.xml` e`TestSuiteTwo.xml`, os CodeCatalyst relatórios associados serão nomeados e. `AutoDiscoveredTestSuiteOne` `AutoDiscoveredTestSuiteTwo` **UI correspondente: saídas tab/Reports/Automatically descobrem relatórios/prefixo do relatório** ## IncludePaths (*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**) Ou (*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**) (Obrigatório se [AutoDiscoverReports](#github.outputs.autodiscover) estiver incluído e habilitado ou se [Reports](#github.configuration.reports) estiver incluído) Especifique os arquivos e os caminhos de arquivo CodeCatalyst incluídos na pesquisa de relatórios brutos. Por exemplo, se você especificar`"/test/report/*"`, CodeCatalyst pesquisa toda a [imagem de compilação](build-images.md) usada pela ação procurando o `/test/report/*` diretório. Quando encontra esse diretório CodeCatalyst , procura relatórios nesse diretório. **nota** Se o caminho do arquivo incluir um ou mais asteriscos (`*`) ou outros caracteres especiais, coloque o caminho entre aspas duplas (`""`). Para ter mais informações sobre caracteres especiais, consulte [Diretrizes e convenções de sintaxe](workflow-reference.md#workflow.terms.syntax.conv). Se essa propriedade for omitida, o padrão será `"**/*"`, o que significa que a pesquisa inclui todos os arquivos em todos os caminhos. **nota** Em relatórios configurados manualmente, `IncludePaths` deverá ser um padrão global que corresponda a um único arquivo. Interface de usuário correspondente: + **Caminhos de saída'/ tab/Reports/Automatically discover reports/'Include/exclude Caminhos de inclusão'** + **As saídas tab/Reports/Manually configuram relatórios/ /'incluir/excluir caminhos'*report-name-1*/Incluir caminhos** ## ExcludePaths (*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**) Ou (*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**) (Optional) Especifique os arquivos e os caminhos de arquivo que são CodeCatalyst excluídos ao pesquisar relatórios brutos. Por exemplo, se você especificar`"/test/my-reports/**/*"`, não CodeCatalyst procurará arquivos no `/test/my-reports/` diretório. Para ignorar todos os arquivos em um diretório, use o padrão de glob `**/*`. **nota** Se o caminho do arquivo incluir um ou mais asteriscos (`*`) ou outros caracteres especiais, coloque o caminho entre aspas duplas (`""`). Para ter mais informações sobre caracteres especiais, consulte [Diretrizes e convenções de sintaxe](workflow-reference.md#workflow.terms.syntax.conv). Interface de usuário correspondente: + **Caminhos de tab/Reports/Automatically discover reports/'Include/exclude saída'/ Excluir caminhos** + **As saídas tab/Reports/Manually configuram relatórios/ /'Include/Excluir caminhos'*report-name-1*/Excluir caminhos** ## SuccessCriteria (*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**) Ou (*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**) (Optional) Especifique os critérios de sucesso para os relatórios de teste, cobertura de código, análise de composição de software (SCA) e análise estática (SA). Para obter mais informações, consulte [Configuração de critérios de sucesso para relatórios](test-config-action.md#test.success-criteria). Interface de usuário correspondente: + **Resultados: tab/Reports/Automatically descubra relatórios/critérios de sucesso** + **Saídas tab/Reports/Manually configuram relatórios//Critérios de sucesso *report-name-1*** ## PassRate (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**) (Optional) Especifique a porcentagem de testes em um relatório de teste que devem ser aprovados para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de taxa de aprovação são aplicados somente aos relatórios de teste. Para ter mais informações sobre os relatórios de teste, consulte [Relatórios de teste](test-workflow-actions.md#test-reports). Interface de usuário correspondente: + tab/Reports/Automatically discover reports/Success**Critérios de saídas/Taxa de aprovação** + **Saídas tab/Reports/Manually configuram relatórios/ /Critérios de *report-name-1* sucesso/ Taxa de aprovação** ## LineCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**) (Optional) Especifique a porcentagem de linhas em um relatório de cobertura de código que devem ser cobertas para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de cobertura de linha são aplicados somente aos relatórios de cobertura de código. Para ter mais informações sobre relatórios de cobertura de código, consulte [Relatórios de cobertura de código](test-workflow-actions.md#test-code-coverage-reports). Interface de usuário correspondente: + tab/Reports/Automatically discover reports/Success**Critérios de saídas/Cobertura de linha** + **As saídas tab/Reports/Manually configuram relatórios/ /Critérios de *report-name-1* sucesso/ Cobertura de linha** ## BranchCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**) (Optional) Especifique a porcentagem de filiais em um relatório de cobertura de código que devem ser cobertas para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de cobertura de ramificações são aplicados somente aos relatórios de cobertura de código. Para ter mais informações sobre relatórios de cobertura de código, consulte [Relatórios de cobertura de código](test-workflow-actions.md#test-code-coverage-reports). Interface de usuário correspondente: + tab/Reports/Automatically discover reports/Success**Critérios de saídas/Cobertura da filial** + **As saídas tab/Reports/Manually configuram relatórios/ /Critérios de *report-name-1* sucesso/ Cobertura de filiais** ## Vulnerabilities (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**) Ou (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**) (Optional) Especifique o número máximo e a gravidade das vulnerabilidades permitidas no relatório SCA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar vulnerabilidades, é necessário especificar: + A gravidade mínima das vulnerabilidades que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Por exemplo, se você escolher `HIGH`, as vulnerabilidades `HIGH` e `CRITICAL` serão contabilizadas. + O número máximo de vulnerabilidades da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros. Os critérios de vulnerabilidade são aplicados somente aos relatórios de SCA. Para ter mais informações sobre os relatórios de SCA, consulte [Relatórios de análise de composição de software](test-workflow-actions.md#test-sca-reports). Para especificar a gravidade mínima, use a propriedade `Severity`. Para especificar o número máximo de vulnerabilidades, use a propriedade `Number`. Para ter mais informações sobre os relatórios de SCA, consulte [Tipos de relatório de qualidade](test-workflow-actions.md#test-reporting). Interface de usuário correspondente: + tab/Reports/Automatically discover reports/Success**Critérios de saídas/vulnerabilidades** + **As saídas tab/Reports/Manually configuram relatórios/ /Critérios de sucesso/ *report-name-1* Vulnerabilidades** ## Reports (*action-name*/Outputs/**Reports** ) (Optional) Uma seção que especifica a configuração dos relatórios de teste. Interface de usuário correspondente: guia Saídas/**Relatórios** ## report-name-1 (nome do *action-name* /Outputs/Reports/ **relatório-1)** (Obrigatório se [Reports](#github.configuration.reports) for incluído) O nome que você deseja dar ao CodeCatalyst relatório que será gerado a partir de seus relatórios brutos. **UI correspondente: saídas tab/Reports/Manually configuram relatórios/nome do relatório** ## Format (*action-name*/Outputs/Reports/*report-name-1*/**Format**) (Obrigatório se [Reports](#github.configuration.reports) for incluído) Especifique o formato de arquivo utilizado para os relatórios. Veja a seguir os valores possíveis. + Para relatórios de teste: + Para Cucumber JSON, especifique **Cucumber** (editor visual) ou `CUCUMBERJSON` (editor YAML). + Para JUnit XML, especifique **JUnit**(editor visual) ou `JUNITXML` (editor YAML). + Para NUnit XML, especifique **NUnit**(editor visual) ou `NUNITXML` (editor YAML). + Para NUnit 3 XML, especifique **NUnit3**(editor visual) ou `NUNIT3XML` (editor YAML). + Para Visual Studio TRX, especifique **Visual Studio TRX** (editor visual) ou `VISUALSTUDIOTRX` (editor YAML). + Para TestNG XML, especifique **TestNG** (editor visual) ou `TESTNGXML` (editor YAML). + Para relatórios de cobertura de código: + Para Clover XML, especifique **Clover** (editor visual) ou `CLOVERXML` (editor YAML). + Para Cobertura XML, especifique **Cobertura** (editor visual) ou `COBERTURAXML` (editor YAML). + Para JaCoCo XML, especifique **JaCoCo**(editor visual) ou `JACOCOXML` (editor YAML). + Para SimpleCov JSON gerado por [simplecov, não [simplecov-json](https://github.com/vicentllongo/simplecov-json)](https://github.com/simplecov-ruby/simplecov), especifique Simplecov (editor visual) ou (**editor YAML**). `SIMPLECOV` + Para relatórios de análise de composição de software (SCA): + Para SARIF, especifique **SARIF** (editor visual) ou `SARIFSCA` (editor YAML). **UI correspondente: tab/Reports/Manually configure reports/Add relatório de saídas*report-name-1*//**Tipo de relatório e formato do relatório**** ## Configuration (*action-name*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## Steps (*action-name*/Configuration/**Steps**) (Obrigatório) Especifique seu código de GitHub ação conforme ele aparece na página de detalhes da ação no [GitHub Marketplace](https://github.com/marketplace). Adicione o código seguindo estas diretrizes: 1. Cole o código da `steps:` seção GitHub Ação na `Steps:` seção do CodeCatalyst fluxo de trabalho. O código começa com um traço (-) e tem uma aparência semelhante ao exemplo a seguir. GitHub código para colar: ``` - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: false DEFAULT_BRANCH: master GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` 1. Revise o código que você acabou de colar e modifique-o conforme necessário para que esteja em conformidade com os CodeCatalyst padrões. Por exemplo, com o bloco de código anterior, você pode remover o código e adicioná-lo em **negrito**. *red italics* CodeCatalyst fluxo de trabalho yaml: ``` Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: false DEFAULT_BRANCH: mastermain GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` 1. Para obter código adicional incluído na GitHub Ação, mas que não existe dentro da `steps:` seção, adicione-o ao CodeCatalyst fluxo de trabalho usando o código CodeCatalyst -equivalent. Você pode revisar o [Definição do YAML do fluxo de trabalho](workflow-reference.md) para ter uma ideia de como você pode portar seu GitHub código para CodeCatalyst o. As etapas detalhadas da migração estão fora do escopo deste guia. Aqui está um exemplo de como especificar caminhos de arquivo em uma ação de **GitHub ações**: ``` Steps: - name: Lint Code Base uses: github/super-linter@v4 ... - run: cd /sources/WorkflowSource/MyFolder/ && cat file.txt - run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/ && cat file2.txt ``` Para ter mais informações sobre como especificar caminhos de arquivo, consulte [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md) e [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). UI correspondente: guia de **GitHub configuração/ações YAML** # Configuração de imagens de computação e runtime Em um CodeCatalyst fluxo de trabalho, você pode especificar a imagem do ambiente de computação e tempo de execução CodeCatalyst usada para executar ações do fluxo de trabalho. *Computação* se refere ao mecanismo de computação (CPU, memória e sistema operacional) gerenciado e mantido por CodeCatalyst para executar ações de fluxo de trabalho. **nota** Se a computação for definida como uma propriedade do fluxo de trabalho, ela não poderá ser definida como uma propriedade de nenhuma ação nesse fluxo de trabalho. Da mesma forma, se computação for definida como uma propriedade de qualquer ação, ela não poderá ser definida no fluxo de trabalho. Uma *imagem do ambiente de tempo de execução* é um contêiner do Docker dentro do qual são CodeCatalyst executadas ações de fluxo de trabalho. O contêiner do Docker é executado na plataforma de computação escolhida e inclui um sistema operacional e ferramentas extras que uma ação de fluxo de trabalho pode precisar, como o AWS CLI Node.js e .tar. **Topics** + [ ## Tipos de computação ](#compute.types) + [ ## Frotas de computação ](#compute.fleets) + [ ## Propriedades da frota sob demanda ](#compute.on-demand) + [ ## Propriedades da frota provisionada ](#compute.provisioned-fleets) + [ # Criar uma frota provisionada ](projects-create-compute-resource.md) + [ # Edição de uma frota provisionada ](edit-compute-resource.md) + [ # Exclusão de uma frota provisionada ](delete-compute-resource.md) + [ # Atribuir uma frota ou computação a uma ação ](workflows-assign-compute-resource.md) + [ # Compartilhamento de computação entre ações ](compute-sharing.md) + [ # Especificação de imagens de ambiente de runtime ](build-images.md) ## Tipos de computação CodeCatalyst oferece os seguintes tipos de computação: + Amazon EC2 + AWS Lambda O Amazon EC2 oferece flexibilidade otimizada durante as execuções de ações e o Lambda oferece velocidades otimizadas de inicialização de ações. O Lambda é compatível com execuções de ações de fluxo de trabalho mais rápidas devido a uma menor latência de inicialização. O Lambda permite executar fluxos de trabalho básicos que podem criar, testar e implantar aplicações com tecnologia sem servidor com runtimes comuns. Esses runtimes incluem Node.js, Python, Java, .NET e Go. No entanto, há alguns casos de uso não compatíveis com o Lambda e, se eles afetarem você, use o tipo de computação do Amazon EC2: + O Lambda não é compatível com imagens de ambiente de runtime de um registro especificado. + O Lambda não é compatível com ferramentas que exijam permissões de raiz. Para ferramentas como `yum` ou `rpm`, use o tipo de computação do Amazon EC2 ou outras ferramentas que não exijam permissões de raiz. + O Lambda não é compatível com compilações ou execuções do Docker. As seguintes ações que usam imagens do Docker não são suportadas: Deploy AWS CloudFormation stack, Deploy to Amazon ECS, Amazon S3 publish, AWS CDK bootstrap, AWS CDK deploy, invoke e Actions. AWS Lambda GitHub GitHub As ações baseadas em Docker que estão sendo executadas na ação CodeCatalyst GitHub Actions também não são compatíveis com a computação Lambda. É possível usar alternativas que não exijam permissões de raiz, como o Podman. + O Lambda não é compatível com a gravação em arquivos externos a `/tmp`. Ao configurar suas ações de fluxo de trabalho, você pode reconfigurar suas ferramentas para instalação ou gravação de `/tmp`. Se você tiver uma ação de criação que instale `npm`, configure-a para instalar em `/tmp`. + O Lambda não é compatível com runtimes de mais de 15 minutos. ## Frotas de computação CodeCatalyst oferece as seguintes frotas de computação: + Frotas sob demanda + Frotas provisionadas Com frotas sob demanda, quando uma ação de fluxo de trabalho é iniciada, o fluxo de trabalho provisiona os recursos necessários. As máquinas são destruídas quando a ação termina. Você só paga pelo número de minutos em que executar suas ações. As frotas sob demanda são totalmente gerenciadas e incluem recursos de escalabilidade automática para lidar com picos de demanda. CodeCatalyst também oferece frotas provisionadas que contêm máquinas alimentadas pelo Amazon EC2 que são mantidas pela. CodeCatalyst Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Com frotas provisionadas, suas máquinas estão sempre funcionando e incorrerão em custos enquanto forem provisionadas. Para criar, atualizar ou excluir uma frota, você deve ter o perfil de **administrador do espaço** ou o perfil de **administrador do projeto**. ## Propriedades da frota sob demanda CodeCatalyst fornece as seguintes frotas sob demanda: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/workflows-working-compute.html) **nota** As especificações para frotas sob demanda variam de acordo com seu nível de faturamento. Para obter mais informações, consulte [Preço](https://codecatalyst.aws/explore/pricing). Se nenhuma frota for selecionada, CodeCatalyst usa`Linux.x86-64.Large`. ## Propriedades da frota provisionada Uma frota provisionada contém as seguintes propriedades: **Sistema operacional** O sistema operacional Os seguintes sistemas operacionais estão disponíveis: + Amazon Linux 2 + Windows Server 2022 **nota** As frotas do Windows são compatíveis somente na ação de criação. Outras ações atualmente não são compatíveis com o Windows. **Arquitetura** A arquitetura do processador. As seguintes arquiteturas estão disponíveis: + x86\$164 + Arm64 **Tipo de máquina** O tipo de máquina para cada instância. Os seguintes tipos de máquina estão disponíveis: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codecatalyst/latest/userguide/workflows-working-compute.html) **Capacidade** O número inicial de máquinas alocadas para a frota, que define o número de ações que podem ser executadas paralelamente. **Modo de escalabilidade** Define o comportamento quando o número de ações excede a capacidade da frota. **Provisionamento da capacidade adicional sob demanda** Máquinas adicionais são configuradas sob demanda, o que aumenta a escala verticalmente de forma automática em resposta à execução de novas ações e, depois, reduz a escala verticalmente para a capacidade básica ao finalizar as ações. Isso pode gerar custos adicionais, já que você paga por minuto por cada máquina em funcionamento. **Esperar até que a capacidade adicional da frota esteja disponível** As execuções de ação são colocadas em uma fila até que uma máquina esteja disponível. Isso limita os custos adicionais porque nenhuma máquina adicional é alocada. # Criar uma frota provisionada Use as instruções a seguir para criar uma frota provisionada. **nota** As frotas provisionadas serão desativadas após 2 semanas de inatividade. Se usadas novamente, elas serão reativadas automaticamente, mas essa reativação pode causar uma latência. **Como criar uma frota provisionada** 1. No painel de navegação, selecione **CI/CD** e **Computação**. 1. Selecione **Criar frota provisionada**. 1. No campo de texto **Nome da frota provisionada**, insira um nome para a frota. 1. No menu suspenso **Sistema operacional**, escolha o sistema operacional. 1. No menu suspenso **Tipo de máquina**, escolha o tipo de máquina. 1. No campo de texto **Capacidade**, insira o número máximo de máquinas na frota. 1. No menu suspenso **Modo de escalabilidade**, escolha o comportamento de sobreposição desejado. Consulte mais informações sobre esses campos em [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). 1. Escolha **Criar**. Depois de criar a frota provisionada, você está pronto para atribuí-la a uma ação. Para obter mais informações, consulte [Atribuir uma frota ou computação a uma ação](workflows-assign-compute-resource.md). # Edição de uma frota provisionada Use as instruções a seguir para editar uma frota provisionada. **nota** As frotas provisionadas serão desativadas após 2 semanas de inatividade. Se usadas novamente, elas serão reativadas automaticamente, mas essa reativação pode causar uma latência. **Para editar uma frota provisionada** 1. No painel de navegação, selecione **CI/CD** e **Computação**. 1. Na lista **Frota provisionada**, selecione a frota que você quer editar. 1. Escolha **Editar**. 1. No campo de texto **Capacidade**, insira o número máximo de máquinas na frota. 1. No menu suspenso **Modo de escalabilidade**, escolha o comportamento de sobreposição desejado. Consulte mais informações sobre esses campos em [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). 1. Escolha **Salvar**. # Exclusão de uma frota provisionada Use as instruções a seguir para excluir uma frota provisionada. **Para excluir uma frota provisionada** **Atenção** Antes de excluir uma frota provisionada, remova-a de todas as ações excluindo a propriedade `Fleet` do código YAML da ação. Qualquer ação que continue referenciando uma frota provisionada depois que ela for excluída falhará na próxima vez em que a ação for executada. 1. No painel de navegação, selecione **CI/CD** e **Computação**. 1. Na lista **Frota provisionada**, selecione a frota que você quer excluir. 1. Escolha **Excluir**. 1. Insira **delete** para confirmar a exclusão. 1. Escolha **Excluir**. # Atribuir uma frota ou computação a uma ação Por padrão, as ações de fluxo de trabalho usam a frota `Linux.x86-64.Large` sob demanda com um tipo de computação do Amazon EC2. Para usar uma frota provisionada ou uma frota sob demanda diferente, como `Linux.x86-64.2XLarge`, siga estas instruções. ------ #### [ Visual ] **Antes de começar** + Se quiser atribuir uma frota provisionada, primeiro será necessário criá-la. Para obter mais informações, consulte [Criar uma frota provisionada](projects-create-compute-resource.md). **Como atribuir uma frota provisionada ou um tipo de frota diferente a uma ação** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, escolha a ação à qual você deseja atribuir a frota provisionada ou o novo tipo de frota. 1. Escolha a guia **Configuração**. 1. Em **Frota de computação**, faça o seguinte: Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Antes de começar** + Se quiser atribuir uma frota provisionada, primeiro será necessário criá-la. Para obter mais informações, consulte [Criar uma frota provisionada](projects-create-compute-resource.md). **Como atribuir uma frota provisionada ou um tipo de frota diferente a uma ação** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Encontre a ação à qual você deseja atribuir a frota provisionada ou o novo tipo de frota. 1. Na ação, adicione uma propriedade `Compute` e defina `Fleet` com o nome da frota ou o tipo de frota sob demanda. Para ter mais informações, consulte a descrição da propriedade `Fleet` em [Ações de criação e de teste YAML](build-action-ref.md) para a ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Compartilhamento de computação entre ações Por padrão, as ações em um fluxo de trabalho são executadas em instâncias separadas em uma [frota](workflows-working-compute.md#compute.fleets). Esse comportamento fornece ações com isolamento e previsibilidade sobre o estado das entradas. O comportamento padrão requer configuração explícita para compartilhar contexto, como arquivos e variáveis, entre as ações. O compartilhamento de computação é um recurso que permite executar todas as ações em um fluxo de trabalho na mesma instância. Usar o compartilhamento de computação pode proporcionar runtimes de fluxo de trabalho mais rápidos, pois menos tempo é gasto no provisionamento de instâncias. Você também pode compartilhar arquivos (artefatos) entre ações sem configuração adicional do fluxo de trabalho. Quando um fluxo de trabalho é executado usando o compartilhamento de computação, uma instância na frota padrão ou especificada é reservada durante todas as ações nesse fluxo de trabalho. Quando a execução do fluxo de trabalho é concluída, a reserva da instância é liberada. **Topics** + [ ## Execução de várias ações em computação compartilhada ](#how-to-compute-share) + [ ## Considerações sobre compartilhamento de computação ](#compare-compute-sharing) + [ ## Ativação do compartilhamento de computação ](#compute-sharing-steps) + [ ## Exemplos ](#compute-sharing-examples) ## Execução de várias ações em computação compartilhada Você pode usar o atributo `Compute` no YAML de definição no nível do fluxo de trabalho para especificar as propriedades de compartilhamento de frota e computação das ações. Também é possível configurar propriedades de computação usando o editor visual no CodeCatalyst. Para especificar uma frota, defina o nome de uma frota existente, defina o tipo de computação como **EC2** e ative o compartilhamento de computação. **nota** Só haverá suporte para o compartilhamento de computação se o tipo de computação estiver definido como **EC2**. Ele não é compatível com o sistema operacional Windows Server 2022. Para ter informações sobre frotas, tipos e propriedades de computação, consulte [Configuração de imagens de computação e runtime](workflows-working-compute.md). **nota** Se você estiver no nível Gratuito e especificar a frota `Linux.x86-64.XLarge` ou `Linux.x86-64.2XLarge` manualmente no YAML de definição de fluxo de trabalho, a ação ainda será executada na frota padrão (`Linux.x86-64.Large`). Para ter mais informações sobre disponibilidade e preços de computação, consulte a [tabela com as opções de níveis](https://codecatalyst.aws/explore/pricing). Quando o compartilhamento de computação está ativado, a pasta que contém a origem do fluxo de trabalho é copiada automaticamente entre as ações. Você não precisa configurar artefatos de saída e referenciá-los como artefatos de entrada em uma definição de fluxo de trabalho (arquivo YAML). Como autor do fluxo de trabalho, você precisa conectar variáveis de ambiente usando entradas e saídas, da mesma forma que faria sem usar o compartilhamento de computação. Se você quiser compartilhar pastas entre ações fora da origem do fluxo de trabalho, considere o armazenamento em cache de arquivos. Para obter mais informações, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md) e [Armazenar arquivos em cache entre execuções de fluxo de trabalho](workflows-caching.md). O repositório de origem em que seu arquivo de definição de fluxo de trabalho reside é identificado pelo rótulo `WorkflowSource`. Ao usar o compartilhamento de computação, a origem do fluxo de trabalho é baixada na primeira ação que faz referência a ela e disponibilizada automaticamente para uso em ações subsequentes na execução do fluxo de trabalho. Todas as alterações feitas na pasta que contém a origem do fluxo de trabalho por meio de uma ação, como adicionar, modificar ou remover arquivos, também são visíveis nas ações subsequentes do fluxo de trabalho. Você pode referenciar arquivos que residem na pasta de origem do fluxo de trabalho em qualquer ação do fluxo de trabalho, da mesma forma que poderia fazer sem usar o compartilhamento de computação. Para obter mais informações, consulte [Fazer referência a arquivos do repositório de origem](workflows-sources-reference-files.md). **nota** Os fluxos de trabalho de compartilhamento de computação precisam especificar uma sequência estrita de ações, para que ações paralelas não possam ser definidas. Embora os artefatos de saída possam ser configurados em qualquer ação na sequência, não há suporte para os artefatos de entrada. ## Considerações sobre compartilhamento de computação Você pode executar fluxos de trabalho com compartilhamento de computação para acelerar as execuções de fluxo de trabalho e compartilhar o contexto entre as ações em um fluxo de trabalho que usa a mesma instância. Considere o seguinte para determinar se o uso do compartilhamento de computação é apropriado para seu cenário: | | Compartilhamento de computação | Sem compartilhamento de computação | | --- | --- | --- | | Tipo de computação | Amazon EC2 | Amazon EC2, AWS Lambda | | Provisionamento de instância | Ações executadas na mesma instância | As ações são executadas em instâncias separadas | | Sistema operacional | Amazon Linux 2 | Amazon Linux 2, Windows Server 2022 (somente ação de criação) | | Referência a arquivos | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` | | Estrutura Workflow | As ações só podem ser executadas em sequência | As ações podem ser executadas paralelamente | | Acesso a dados em todas as ações do fluxo de trabalho | Acessar a origem de fluxo de trabalho armazenada em cache (`WorkflowSource`) | Acessar saídas de artefatos compartilhados (requer configuração adicional) | ## Ativação do compartilhamento de computação Use as instruções a seguir para ativar o compartilhamento de computação para um fluxo de trabalho. ------ #### [ Visual ] **Para ativar o compartilhamento de computação usando o editor visual** 1. Abra o console do CodeCatalyst em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. Selecione **Propriedades do fluxo de trabalho**. 1. No menu suspenso **Tipo de computação**, selecione **EC2**. 1. (Opcional) No menu suspenso **Frota de computação - opcional**, escolha uma frota que você deseja usar para executar ações de fluxo de trabalho. Você pode escolher uma frota sob demanda ou criar e escolher uma frota provisionada. Para ter mais informações, consulte [Criar uma frota provisionada](projects-create-compute-resource.md) e [Atribuir uma frota ou computação a uma ação](workflows-assign-compute-resource.md) 1. Alterne o botão para ativar o compartilhamento de computação e fazer com que as ações no fluxo de trabalho sejam executadas na mesma frota. 1. (Opcional) Escolha o modo de execução do fluxo de trabalho. Para obter mais informações, consulte [Configurar o comportamento de enfileiramento das execuções](workflows-configure-runs.md). 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para ativar o compartilhamento de computação usando o editor YAML** 1. Abra o console do CodeCatalyst em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Ative o compartilhamento de computação definindo o campo `SharedInstance` como `TRUE` e `Type` como `EC2`. Defina `Fleet` como uma frota de computação que você deseja usar para executar ações de fluxo de trabalho. Você pode escolher uma frota sob demanda ou criar e escolher uma frota provisionada. Para ter mais informações, consulte [Criar uma frota provisionada](projects-create-compute-resource.md) e [Atribuir uma frota ou computação a uma ação](workflows-assign-compute-resource.md) Em um YAML de fluxo de trabalho, adicione um código semelhante ao seguinte: ``` Name: MyWorkflow SchemaVersion: "1.0" Compute: # Define compute configuration. Type: EC2 Fleet: MyFleet # Optionally, choose an on-demand or provisioned fleet. SharedInstance: true # Turn on compute sharing. Default is False. Actions: BuildFirst: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: ... ... ``` 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ ## Exemplos **Topics** + [ ### Exemplo: Amazon S3 Publish ](#compute-share-s3) ### Exemplo: Amazon S3 Publish Os exemplos de fluxo de trabalho a seguir mostram como realizar a ação do Amazon S3 Publish de duas maneiras: primeiro usando artefatos de entrada e, depois, usando o compartilhamento de computação. Com o compartilhamento de computação, os artefatos de entrada não são necessários, pois você pode acessar a `WorkflowSource` armazenada em cache. Além disso, o artefato de saída na ação de criação não é mais necessário. A ação do S3 Publish está configurada para usar a propriedade `DependsOn` explícita para manter ações sequenciais; a ação de criação deve ser executada para que a ação do S3 Publish seja executada. + Sem o compartilhamento de computação, você precisa usar artefatos de entrada e compartilhar as saídas com ações subsequentes: ``` Name: S3PublishUsingInputArtifact SchemaVersion: "1.0" Actions: Build: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ArtifactToPublish Files: [output.zip] Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: ./build.sh # Build script that generates output.zip PublishToS3: Identifier: aws/s3-publish@v1 Inputs: Artifacts: - ArtifactToPublish Environment: Connections: - Role: codecatalyst-deployment-role Name: dev-deployment-role Name: dev-connection Configuration: SourcePath: output.zip DestinationBucketName: amzn-s3-demo-bucket ``` + Ao usar o compartilhamento de computação definindo `SharedInstance` como `TRUE`, você pode executar várias ações na mesma instância e compartilhar artefatos especificando uma única origem de fluxo de trabalho. Os artefatos de entrada não são obrigatórios e não podem ser especificados: ``` Name: S3PublishUsingComputeSharing SchemaVersion: "1.0" Compute: Type: EC2 Fleet: dev-fleet SharedInstance: TRUE Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: ./build.sh # Build script that generates output.zip PublishToS3: Identifier: aws/s3-publish@v1 DependsOn: - Build Environment: Connections: - Role: codecatalyst-deployment-role Name: dev-deployment-role Name: dev-connection Configuration: SourcePath: output.zip DestinationBucketName: amzn-s3-demo-bucket ``` # Especificação de imagens de ambiente de runtime Uma *imagem do ambiente de tempo de execução* é um contêiner do Docker no qual são CodeCatalyst executadas ações de fluxo de trabalho. O contêiner do Docker é executado na plataforma de computação escolhida e inclui um sistema operacional e ferramentas extras que uma ação de fluxo de trabalho pode precisar, como o AWS CLI Node.js e .tar. Por padrão, as ações do fluxo de trabalho serão executadas em uma das [imagens ativas](#build-curated-images) fornecidas e mantidas pela CodeCatalyst. Somente ações de criação e teste oferecem suporte a imagens personalizadas. Para obter mais informações, consulte [Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação](#build-images-specify). **Topics** + [ ## Imagens ativas ](#build-curated-images) + [ ## E se uma imagem ativa não incluir as ferramentas de que preciso? ](#build-images-more-tools) + [ ## Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação ](#build-images-specify) + [ ## Exemplos ](#workflows-working-custom-image-ex) ## Imagens ativas *Imagens ativas são imagens* do ambiente de execução que são totalmente suportadas CodeCatalyst e incluem ferramentas pré-instaladas. Atualmente, existem dois conjuntos de imagens ativas: um lançado em março de 2024 e outro lançado em novembro de 2022. O uso da imagem de março de 2024 ou novembro de 2022 depende da ação: + As ações de criação e teste adicionadas a um fluxo de trabalho em ou após 26 de março de 2024 incluirão uma seção `Container` na definição de YAML que especifica explicitamente uma [imagem de março de 2024](#build.default-image). Se desejar, você pode remover a seção `Container` para voltar à [imagem de novembro de 2022](#build.previous-image). + As ações de criação e teste que foram adicionadas a um fluxo de trabalho antes de 26 de março de 2024 *não* incluirão uma seção `Container` na definição de YAML e, consequentemente, usarão uma [imagem de novembro de 2022](#build.previous-image). É possível manter a imagem de novembro de 2022 ou atualizá-la. Para atualizar a imagem, abra a ação no editor visual, selecione a guia **Configuração** e selecione a imagem de março de 2024 na lista suspensa **Imagem do Docker do ambiente de runtime**. Essa seleção adicionará uma seção `Container` à definição de YAML da ação que é preenchida com a imagem apropriada de março de 2024. + Todas as outras ações usarão uma [imagem de novembro de 2022](#build.previous-image) ou uma [imagem de março de 2024](#build.default-image). Para ter mais informações, consulte a documentação da ação. **Topics** + [ ### Imagens de março de 2024 ](#build.default-image) + [ ### Imagens de novembro de 2022 ](#build.previous-image) ### Imagens de março de 2024 As imagens de março de 2024 são as imagens mais recentes fornecidas por CodeCatalyst. Há uma imagem de março de 2024 por combinação computacional. type/fleet A tabela a seguir mostra as ferramentas instaladas em cada imagem de março de 2024. **Ferramentas de imagem de março de 2024** | Ferramenta | CodeCatalyst Amazon EC2 para Linux x86\$164 - `CodeCatalystLinux_x86_64:2024_03` | CodeCatalyst Lambda para Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2024_03` | CodeCatalyst Amazon EC2 para Linux Arm64 - `CodeCatalystLinux_Arm64:2024_03` | CodeCatalyst Lambda para Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2024_03` | | --- | --- | --- | --- | --- | | AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 | | AWS CLI do Copilot | 1.32.1 | 1.32.1 | 1.32.1 | 1.32.1 | | Docker | 24.0.9 | N/D | 24.0.9 | N/D | | Docker Compose | 2.23.3 | N/D | 2.23.3 | N/D | | Git | 2.43.0 | 2.43.0 | 2.43.0 | 2.43.0 | | Go | 1.21.5 | 1.21.5 | 1.21.5 | 1.21.5 | | Gradle | 8.5 | 8.5 | 8.5 | 8.5 | | Java | Corretto17 | Corretto17 | Corretto17 | Corretto17 | | Maven | 3.9.6 | 3.9.6 | 3.9.6 | 3.9.6 | | Node.js | 18.19.0 | 18.19.0 | 18.19.0 | 18.19.0 | | npm | 10.2.3 | 10.2.3 | 10.2.3 | 10.2.3 | | Python | 3.9.18 | 3.9.18 | 3.9.18 | 3.9.18 | | Python3 | 3.11.6 | 3.11.6 | 3.11.6 | 3.11.6 | | pip | 22.3.1 | 22.3.1 | 22.3.1 | 22.3.1 | | .NET | 8.0.100 | 8.0.100 | 8.0.100 | 8.0.100 | ### Imagens de novembro de 2022 Há uma imagem de novembro de 2022 por type/fleet combinação computacional. Também há uma imagem do Windows de novembro de 2022 disponível com a ação de criação, caso você tenha configurado uma [frota provisionada](workflows-working-compute.md#compute.fleets). A tabela a seguir mostra as ferramentas instaladas em cada imagem de novembro de 2022. **Ferramentas de imagem de novembro de 2022** | Ferramenta | CodeCatalyst Amazon EC2 para Linux x86\$164 - `CodeCatalystLinux_x86_64:2022_11` | CodeCatalyst Lambda para Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2022_11` | CodeCatalyst Amazon EC2 para Linux Arm64 - `CodeCatalystLinux_Arm64:2022_11` | CodeCatalyst Lambda para Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2022_11` | CodeCatalyst Amazon EC2 para Windows x86\$164 - `CodeCatalystWindows_x86_64:2022_11` | | --- | --- | --- | --- | --- | --- | | AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 | 2.13.19 | | AWS CLI do Copilot | 0.6.0 | 0.6.0 | N/D | N/D | 1.30.1 | | Docker | 23.01 | N/D | 23.0.1 | N/D | N/D | | Docker Compose | 2.16.0 | N/D | 2.16.0 | N/D | N/D | | Git | 2.40.0 | 2.40.0 | 2.39.2 | 2.39.2 | 2.42.0 | | Go | 1.20.2 | 1.20.2 | 1.20.1 | 1.20.1 | 1,19 | | Gradle | 8.0.2 | 8.0.2 | 8.0.1 | 8.0.1 | 8.3 | | Java | Corretto17 | Corretto17 | Corretto17 | Corretto17 | Corretto17 | | Maven | 3.9.4 | 3.9.4 | 3.9.0 | 3.9.0 | 3.9.4 | | Node.js | 16.20.2 | 16.20.2 | 16.19.1 | 16.14.2 | 16.20.0 | | npm | 8.19.4 | 8.19.4 | 8.19.3 | 8.5.0 | 8.19.4 | | Python | 3.9.15 | 2.7.18 | 3.11.2 | 2.7.18 | 3.9.13 | | Python3 | N/D | 3.9.15 | N/D | 3.11.2 | N/D | | pip | 22.2.2 | 22.2.2 | 23.0.1 | 23.0.1 | 22.0.4 | | .NET | 6.0.407 | 6.0.407 | 6.0.406 | 6.0.406 | 6.0.414 | ## E se uma imagem ativa não incluir as ferramentas de que preciso? Se nenhuma das [imagens ativas](#build-curated-images) fornecidas pelo CodeCatalyst incluir as ferramentas necessárias, você tem algumas opções: + Você pode fornecer uma imagem do Docker de ambiente de runtime personalizada que inclua as ferramentas necessárias. Para obter mais informações, consulte [Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação](#build-images-specify). **nota** Se você quiser fornecer uma imagem do Docker de ambiente de runtime personalizada, a imagem personalizada deverá ter o Git instalado nela. + Você pode fazer com que a ação de criação ou teste do fluxo de trabalho instale as ferramentas necessárias. Por exemplo, você pode incluir as seguintes instruções na seção `Steps` do código YAML da ação de criação ou teste: ``` Configuration: Steps: - Run: ./setup-script ``` A *setup-script* instrução então executaria o seguinte script para instalar o gerenciador de pacotes Node (npm): ``` #!/usr/bin/env bash echo "Setting up environment" touch ~/.bashrc curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash source ~/.bashrc nvm install v16.1.0 source ~/.bashrc ``` Para ter mais informações sobre o YAML da ação de criação, consulte [Ações de criação e de teste YAML](build-action-ref.md). ## Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação Se você não quiser usar uma [imagem ativa](#build-curated-images) fornecida pela CodeCatalyst, você pode fornecer uma imagem Docker de ambiente de tempo de execução personalizada. Se você quiser fornecer uma imagem personalizada, ela deverá ter o Git instalado. A imagem pode residir no Docker Hub, no Amazon Elastic Container Registry ou em qualquer repositório público. Para saber como criar uma imagem do Docker personalizada, consulte [Criar contêineres em uma aplicação](https://docs.docker.com/get-started/02_our_app/) na documentação do Docker. Use as instruções a seguir para atribuir a imagem do Docker de ambiente de runtime personalizada a uma ação. Depois de especificar uma imagem, CodeCatalyst implante-a na sua plataforma de computação quando a ação começar. **nota** **As ações a seguir não oferecem suporte a imagens personalizadas do Docker do ambiente de tempo de execução: **Deploy CloudFormation stack**, **Deploy to ECS** e **GitHub Actions. As** imagens do Docker do ambiente de tempo de execução personalizado também não oferecem suporte ao tipo de computação Lambda.** ------ #### [ Visual ] **Para atribuir uma imagem do Docker de ambiente de runtime personalizada usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, escolha a ação que usará a imagem do Docker de ambiente de runtime personalizada. 1. Escolha a guia **Configuração**. 1. Na parte inferior, preencha os seguintes campos. **Imagem do Docker de ambiente de runtime - opcional** Especifique o registro em que a imagem está armazenada. Os valores válidos são: + `CODECATALYST` (editor YAML) A imagem é armazenada no CodeCatalyst registro. + **Docker Hub** (editor visual) ou `DockerHub` (editor YAML) A imagem é armazenada no registro de imagens do Docker Hub. + **Outro registro** (editor visual) ou `Other` (editor YAML) A imagem é armazenada em um registro de imagem personalizado. Qualquer registro disponível publicamente pode ser usado. + **Amazon Elastic Container Registry** (editor visual) ou `ECR` (editor YAML) A imagem é armazenada em um repositório de imagens do Amazon Elastic Container Registry. Para usar uma imagem em um repositório do Amazon ECR, essa ação precisa acessar o Amazon ECR. Para habilitar esse acesso, é necessário criar um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que inclua as permissões e a política de confiança personalizada a seguir. (Se desejar, você poderá modificar um perfil existente para incluir as permissões e a política.) O perfil do IAM deve incluir as seguintes permissões na política: + `ecr:BatchCheckLayerAvailability` + `ecr:BatchGetImage` + `ecr:GetAuthorizationToken` + `ecr:GetDownloadUrlForLayer` O perfil do IAM deve incluir a seguinte política de confiança personalizada: Para ter mais informações sobre como criar perfis do IAM, consulte [Criar um perfil usando políticas de confiança personalizadas (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) no *Guia do usuário do IAM*. Depois que você criar o perfil, deverá atribuí-lo à ação por meio de um ambiente. Para obter mais informações, consulte [Associação de um ambiente a uma ação](deploy-environments-add-app-to-environment.md). **URL da imagem do ECR**, **imagem do Docker Hub** ou **URL da imagem** Especifique um dos seguintes: + Se você estiver usando um registro `CODECATALYST`, defina a imagem como uma das seguintes [imagens ativas](#build-curated-images): + `CodeCatalystLinux_x86_64:2024_03` + `CodeCatalystLinux_x86_64:2022_11` + `CodeCatalystLinux_Arm64:2024_03` + `CodeCatalystLinux_Arm64:2022_11` + `CodeCatalystLinuxLambda_x86_64:2024_03` + `CodeCatalystLinuxLambda_x86_64:2022_11` + `CodeCatalystLinuxLambda_Arm64:2024_03` + `CodeCatalystLinuxLambda_Arm64:2022_11` + `CodeCatalystWindows_x86_64:2022_11` + Se você estiver usando um registro do Docker Hub, defina a imagem como o nome da imagem do Docker Hub e a tag opcional. Exemplo: `postgres:latest` + Se estiver usando um registro do Amazon ECR, defina a imagem como o URI do registro do Amazon ECR. Exemplo: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo` + Se estiver usando um registro personalizado, defina a imagem como o valor esperado pelo registro personalizado. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para atribuir uma imagem do Docker de ambiente de runtime personalizada usando o editor YAML** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Encontre a ação à qual você quer atribuir uma imagem do Docker do ambiente de runtime. 1. Na ação, adicione uma seção `Container` e as propriedades subjacentes `Registry` e `Image`. Para ter mais informações, consulte a descrição das propriedades `Container`, `Registry` e `Image` da [Ações](workflow-reference.md#actions-reference) para sua ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ ## Exemplos Os exemplos a seguir mostram como atribuir uma imagem do Docker de ambiente de runtime personalizada a uma ação no arquivo de definição do fluxo de trabalho. **Topics** + [ ### Exemplo: uso de uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o Amazon ECR ](#workflows-working-custom-image-ex-ecr-node18) + [ ### Exemplo: uso de uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o Docker Hub ](#workflows-working-custom-image-ex-docker-node18) ### Exemplo: uso de uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o Amazon ECR O exemplo a seguir mostra como usar uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o [Amazon ECR](https://gallery.ecr.aws/amazonlinux/amazonlinux). ``` Configuration: Container: Registry: ECR Image: public.ecr.aws/amazonlinux/amazonlinux:2023 ``` ### Exemplo: uso de uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o Docker Hub O exemplo a seguir mostra como usar uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o [Docker Hub](https://hub.docker.com/_/node). ``` Configuration: Container: Registry: DockerHub Image: node:18.18.2 ``` # Conectar repositórios de origem aos fluxos de trabalho *Origem*, também chamada de *origem de entrada*, é um repositório de origem ao qual uma [ação de fluxo de trabalho](workflows-actions.md) se conecta para receber os arquivos necessários com o objetivo de realizar as operações. Por exemplo, uma ação de fluxo de trabalho pode se conectar a um repositório de origem para receber arquivos de origem a aplicação com o objetivo de criar uma aplicação. CodeCatalyst os fluxos de trabalho oferecem suporte às seguintes fontes: + CodeCatalyst repositórios de origem — Para obter mais informações, consulte[Armazene e colabore no código com repositórios de origem no CodeCatalystArmazenamento e colaboração no código com repositórios de origem](source.md). + GitHub repositórios, repositórios Bitbucket e repositórios de GitLab projetos — Para obter mais informações, consulte. [Adicione funcionalidade a projetos com extensões no CodeCatalystAdicionar funcionalidade a projetos com extensões](extensions.md) **Topics** + [ # Especificar o repositório de origem de um arquivo de fluxo de trabalho ](workflows-sources-specify-workflow-def.md) + [ # Especificar o repositório de origem da ação do fluxo de trabalho ](workflows-sources-specify-action.md) + [ # Fazer referência a arquivos do repositório de origem ](workflows-sources-reference-files.md) + [ # variáveis BranchName '' e CommitId '' ](workflows-sources-variables.md) # Especificar o repositório de origem de um arquivo de fluxo de trabalho Use as instruções a seguir para especificar o repositório de CodeCatalyst origem em que você deseja armazenar seu arquivo de definição de fluxo de trabalho. Se você preferir especificar um GitHub repositório, repositório Bitbucket ou repositório de GitLab projeto, consulte em vez disso. [Adicione funcionalidade a projetos com extensões no CodeCatalystAdicionar funcionalidade a projetos com extensões](extensions.md) O repositório de origem em que seu arquivo de definição de fluxo de trabalho reside é identificado pelo rótulo `WorkflowSource`. **nota** Especifique o repositório de origem em que seu arquivo de definição de fluxo de trabalho reside ao confirmar seu arquivo de definição de fluxo de trabalho pela primeira vez. Depois dessa confirmação, o repositório e o arquivo de definição do fluxo de trabalho são vinculados permanentemente. A única maneira de alterar o repositório após a confirmação inicial é recriar o fluxo de trabalho em um repositório diferente. **Como especificar o repositório de origem que armazenará o arquivo de definição do fluxo de trabalho** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho** para criar o fluxo de trabalho. Para obter mais informações, consulte [Criação de um fluxo de trabalho](workflows-create-workflow.md). Durante o processo de criação do fluxo de trabalho, você pode especificar o CodeCatalyst repositório, a ramificação e a pasta em que deseja armazenar o arquivo de definição do fluxo de trabalho. # Especificar o repositório de origem da ação do fluxo de trabalho Use as instruções a seguir para especificar um repositório de origem a ser usado com uma ação de fluxo de trabalho. Na startup, a ação empacota os arquivos no repositório de origem configurado em um artefato, faz download do artefato na [imagem do Docker do ambiente de runtime](build-images.md) em que a ação está sendo executada e, depois, conclui seu processamento usando os arquivos baixados. **nota** Atualmente, em uma ação de fluxo de trabalho, você só pode especificar um repositório de origem, que é o repositório de origem em que o arquivo de definição do fluxo de trabalho reside (no diretório `.codecatalyst/workflows/` ou em um de seus subdiretórios). Esse repositório de origem é representado pelo rótulo `WorkflowSource`. ------ #### [ Visual ] **Como especificar o repositório de origem que uma ação usará (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação onde deseja especificar a origem. 1. Selecione **Entradas**. 1. Em **Origens – opcional**, faça o seguinte: Especifique os rótulos que representam os repositórios de origem que serão necessários para a ação. Atualmente, o único rótulo compatível é `WorkflowSource`, que representa o repositório de origem em que o arquivo de definição de fluxo de trabalho está armazenado. Se você omitir uma origem, deverá especificar pelo menos um artefato de entrada em `action-name/Inputs/Artifacts`. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como especificar o repositório de origem que uma ação usará (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma ação, adicione um código semelhante ao seguinte: ``` action-name: Inputs: Sources: - WorkflowSource ``` Para ter mais informações, consulte a descrição da propriedade `Sources` em [Definição do YAML do fluxo de trabalho](workflow-reference.md) para sua ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Fazer referência a arquivos do repositório de origem Se você tiver arquivos que residem em um repositório de origem e precisar se referir a esses arquivos em uma das ações do fluxo de trabalho, conclua o procedimento a seguir. **nota** Consulte também [Referência de arquivos em um artefato](workflows-working-artifacts-refer-files.md). **Como fazer referência a um arquivo armazenado em um repositório de origem** + Na ação em que você deseja fazer referência a um arquivo, adicione um código semelhante ao seguinte: ``` Actions: My-action: Inputs: Sources: - WorkflowSource Configuration: Steps: - run: cd my-app && cat file1.jar ``` No código anterior, a ação procura no diretório `my-app` na raiz do repositório de origem `WorkflowSource` para encontrar e exibir o arquivo `file1.jar`. # variáveis BranchName '' e CommitId '' A CodeCatalyst fonte produz `BranchName` e define `CommitId` variáveis quando seu fluxo de trabalho é executado. Elas são conhecidas como *variáveis predefinidas*. Veja a tabela a seguir para ter informações sobre essas variáveis. Para ter informações sobre como referenciar essas variáveis em um fluxo de trabalho, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). | Chave | Valor | | --- | --- | | CommitId | O ID de confirmação que representa o estado do repositório no momento em que a execução do fluxo de trabalho foi iniciada. Exemplo: `example3819261db00a3ab59468c8b` Consulte também: [Exemplo: referenciando a variável predefinida CommitId "”](workflows-predefined-examples.md#workflows-working-with-variables-ex-refer-action) | | BranchName | O nome da ramificação em que a execução do fluxo de trabalho foi iniciada. Exemplos: `main`, `feature/branch`, `test-LiJuan` Consulte também: [Exemplo: referenciando a variável predefinida BranchName "”](workflows-predefined-examples.md#workflows-working-with-variables-ex-branch) | # Conectar repositórios de pacotes a fluxos de trabalho Um *pacote* é um pacote que inclui o software e os metadados necessários para instalar o software e resolver quaisquer dependências. CodeCatalyst suporta o formato de pacote npm. Um pacote consiste em: + Um nome (por exemplo, `webpack` é o nome de um pacote npm conhecido) + Um [namespace](packages-concepts.md#packages-concepts-package-namespaces) opcional (por exemplo, `@types` em `@types/node`) + Um conjunto de [versões](packages-concepts.md#packages-concepts-package-versions) (por exemplo, `1.0.0`, `1.0.1`, `1.0.2`) + Metadados em nível de pacote (por exemplo, tags npm dist) Em CodeCatalyst, você pode publicar e consumir pacotes de repositórios de CodeCatalyst pacotes em seus fluxos de trabalho. Você pode configurar uma ação de compilação ou teste com um repositório de CodeCatalyst pacotes para configurar automaticamente o cliente npm de uma ação para enviar e extrair pacotes do repositório especificado. Para ter mais informações sobre pacotes, consulte [Publique e compartilhe pacotes de software no CodeCatalyst](packages.md). **nota** Atualmente, as ações de compilação e teste oferecem suporte a repositórios de CodeCatalyst pacotes. **Topics** + [ # Tutorial: extrair de um repositório de pacotes ](packages-tutorial.md) + [ # Especificação de repositórios de CodeCatalyst pacotes em fluxos de trabalho ](workflows-package-specify-action.md) + [ # Usar tokens de autorização em ações de fluxo de trabalho ](workflows-package-export-token.md) + [ # Exemplos: repositórios de pacotes em fluxos de trabalho ](workflows-working-packages-ex.md) # Tutorial: extrair de um repositório de pacotes Neste tutorial, você aprende a criar um fluxo de trabalho que executa um aplicativo cujas dependências são extraídas de um [repositório de CodeCatalyst pacotes](packages-concepts.md#packages-concepts-repository). O aplicativo é um aplicativo Node.js simples que imprime uma mensagem 'Hello World' nos CodeCatalyst registros. A aplicação tem uma única dependência: o pacote npm [lodash](https://www.npmjs.com/package/lodash). O pacote `lodash` é usado para transformar uma string `hello-world` em `Hello World`. Você usará a versão 4.17.20 desse pacote. Depois de configurar seu aplicativo e fluxo de trabalho, você configura CodeCatalyst para impedir que versões adicionais do `lodash` sejam importadas para o repositório de CodeCatalyst pacotes a partir do registro externo público ([npmjs.com](https://www.npmjs.com/)). Depois, você testa se versões adicionais do `lodash` foram bloqueadas. Ao final deste tutorial, você deve ter uma boa compreensão de como um fluxo de trabalho interage com repositórios de pacotes, tanto internos quanto externos CodeCatalyst, para recuperar pacotes. Você também deve entender as behind-the-scenes interações que ocorrem entre o npm, seu repositório de pacotes, seu fluxo de trabalho e o arquivo do `package.json` seu aplicativo. **Topics** + [ ## Pré-requisitos ](#packages-tutorial-prereqs) + [ ## Etapa 1: criar um repositório de origem ](#packages-tutorial-source-repo) + [ ## Etapa 2: Criar os repositórios de pacotes CodeCatalyst e gateway ](#packages-tutorial-package-repo) + [ ## Etapa 3: criar a aplicação “Hello World” ](#packages-tutorial-create-app) + [ ## Etapa 4: criar um fluxo de trabalho que execute o “Hello World” ](#packages-tutorial-create-workflow) + [ ## Etapa 5: verificar o fluxo de trabalho ](#packages-tutorial-verify) + [ ## Etapa 6: bloquear importações de npmjs.com ](#packages-tutorial-block) + [ ## Etapa 7: testar o recurso de bloqueio ](#packages-tutorial-test-block) + [ ## Limpeza ](#packages-tutorial-cleanup) ## Pré-requisitos Antes de começar + Você precisa de um CodeCatalyst **espaço**. Para obter mais informações, consulte [Criar um espaço](spaces-create.md). + Em seu CodeCatalyst espaço, você precisa de um projeto vazio chamado: ``` codecatalyst-package-project ``` Use a opção **Começar do zero** para criar esse projeto. Para obter mais informações, consulte [Criando um projeto vazio na Amazon CodeCatalyst](projects-create.md#projects-create-empty). ## Etapa 1: criar um repositório de origem Nesta etapa, você cria um repositório de origem no CodeCatalyst. Esse repositório armazena os arquivos de origem do tutorial, como os arquivos `index.js` e `package.json`. Para ter mais informações sobre repositórios de origem, consulte [Criar um repositório de origem](source-repositories-create.md). **Como criar um repositório de origem** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Navegue até o projeto, `codecatalyst-package-project`. 1. No painel de navegação, selecione **Código** e, em seguida, selecione **Repositórios de origem**. 1. Escolha **Adicionar repositório** e selecione **Criar repositório**. 1. Em **Nome do repositório**, insira: ``` hello-world-app ``` 1. Escolha **Criar**. ## Etapa 2: Criar os repositórios de pacotes CodeCatalyst e gateway Nesta etapa, você cria um repositório de pacotes em seu CodeCatalyst projeto e o conecta a um repositório de gateway, também em seu CodeCatalyst projeto. Posteriormente, você importa a dependência do tutorial, `lodash`, de npmjs.com para os dois repositórios. O repositório do gateway é a “cola” que conecta seu repositório de pacotes CodeCatalyst ao npmjs.com público. Para ter mais informações sobre repositórios de pacote, consulte [Publique e compartilhe pacotes de software no CodeCatalyst](packages.md). **nota** Este tutorial usa os termos *repositório de CodeCatalyst pacotes e repositório* *de gateway* para se referir aos dois repositórios que você cria CodeCatalyst no procedimento a seguir. **Para criar repositórios de CodeCatalyst pacotes e gateways** 1. No painel de navegação, selecione **Packages (pacotes)**. 1. Escolha **Criar repositório de pacotes**. 1. Em **Nome do repositório**, insira: ``` codecatalyst-package-repository ``` 1. Escolha **\$1 Selecionar repositórios upstream**. 1. Escolha **Repositórios de gateway**. 1. Na **npm-public-registry-gateway**caixa, escolha **Criar**. 1. Escolha **Selecionar**. 1. Escolha **Criar**. CodeCatalyst cria um repositório de pacotes chamado `codecatalyst-package-repository` que está conectado a um repositório de gateway. O repositório de gateway está conectado ao registro npmjs.com. ## Etapa 3: criar a aplicação “Hello World” Nesta etapa, você cria um aplicativo Node.js 'Hello World' e importa sua dependência (`lodash`) para seu gateway e CodeCatalyst repositórios de pacotes. Para criar a aplicação, você precisa de uma máquina de desenvolvimento com o Node.js e o cliente `npm` associado instalado. Este tutorial pressupõe que você usará um ambiente de CodeCatalyst desenvolvimento como sua máquina de desenvolvimento. Embora você não precise usar um ambiente de CodeCatalyst desenvolvimento, ele é recomendado porque ele fornece um ambiente de trabalho limpo, tem o Node.js `npm` pré-instalado e é fácil de excluir quando você terminar o tutorial. Para obter mais informações sobre ambientes de CodeCatalyst desenvolvimento, consulte[Criar um Ambiente de Desenvolvimento](devenvironment-create.md). Use as instruções a seguir para iniciar um ambiente de CodeCatalyst desenvolvimento e usá-lo para criar o aplicativo “Hello World”. **Para iniciar um ambiente de CodeCatalyst desenvolvimento** 1. No painel de navegação, escolha **Código** e **Ambientes de Desenvolvimento**. 1. Na parte superior, escolha **Criar ambiente de desenvolvimento** e **AWS Cloud9 (no navegador)**. 1. Verifique se **Repositório** está definido como `hello-world-app` e **Ramificação existente** está definido como `main`. Escolha **Criar**. O Ambiente de Desenvolvimento é iniciado em uma nova guia do navegador e seu repositório (`hello-world-app`) é clonado nela. 1. Deixe as duas guias CodeCatalyst do navegador abertas e vá para o próximo procedimento. **Como criar a aplicação Node.js “Hello World”** 1. Acesse o Ambiente de Desenvolvimento. 1. No prompt do terminal, mude para o diretório raiz do repositório de origem `hello-world-app`: ``` cd hello-world-app ``` 1. Inicialize um projeto Node.js: ``` npm init -y ``` A inicialização cria um arquivo `package.json` no diretório raiz do `hello-world-app`. 1. Conecte o cliente npm em seu ambiente de desenvolvimento ao seu repositório de CodeCatalyst pacotes: 1. Mude para o CodeCatalyst console. 1. No painel de navegação, selecione **Packages (pacotes)**. 1. Selecione `codecatalyst-package-repository`. 1. Selecione **Conectar ao repositório**. 1. Selecione **Criar token**. Um token de acesso pessoal (PAT) é criado para você. 1. Selecione **Copiar** para copiar os comandos. 1. Mude para o Ambiente de Desenvolvimento. 1. Verifique se você está no diretório `hello-world-app`. 1. Cole os comandos. Eles são semelhantes a: ``` npm set registry=https://packages.us-west-2.codecatalyst.aws/npm/ExampleCompany/codecatalyst-package-project/codecatalyst-package-repository/ --location project npm set //packages.us-west-2.codecatalyst.aws/npm/ExampleCompany/codecatalyst-package-project/hello-world-app/:_authToken=username:token-secret ``` 1. Importe a versão 4.17.20 de `lodash`: ``` npm install lodash@v4.17.20 --save --save-exact ``` O npm procura a versão 4.17.20 de `lodash` nos seguintes locais, na seguinte ordem: + No Ambiente de Desenvolvimento. Ele não consegue encontrá-lo aqui. + No repositório de CodeCatalyst pacotes. Ele não consegue encontrá-lo aqui. + No repositório de gateway. Ele não consegue encontrá-lo aqui. + Em npmjs.com. Ele o encontra aqui. O npm importa `lodash` para o repositório do gateway, o repositório de CodeCatalyst pacotes e o Dev Environment. **nota** Se você não tivesse conectado o cliente npm ao seu repositório de CodeCatalyst pacotes na etapa 4, o npm teria sido retirado `lodash` diretamente do npmjs.com e não teria importado o pacote para nenhum dos repositórios. O npm também atualiza seu arquivo `package.json` com a dependência `lodash` e cria um diretório `node_modules` contendo `lodash` e todas as dependências. 1. Teste se `lodash` foi importado para seu Ambiente de Desenvolvimento. Insira: ``` npm list ``` A mensagem a seguir é exibida, indicando uma importação bem-sucedida: ``` `-- lodash@4.17.20 ``` 1. (Opcional) Abra `hello-world-app/package.json` e verifique se as linhas ***red bold***foram adicionadas: ``` { "name": "hello-world-app", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", dependencies": { "lodash": "4.17.20" } } ``` 1. Em `/hello-world-app`, crie um arquivo chamado `index.js` com o conteúdo a seguir: **dica** Você pode usar a navegação lateral no Ambiente de Desenvolvimento para criar esse arquivo. ``` // Importing lodash library const _ = require('lodash'); // Input string const inputString = 'hello-world'; // Transforming the string using lodash const transformedString = _.startCase(inputString.replace('-', ' ')); // Outputting the transformed string to the console console.log(transformedString); ``` **Para testar se 'lodash' foi importado para seu gateway e CodeCatalyst repositórios de pacotes** 1. Mude para o CodeCatalyst console. 1. No painel de navegação, selecione **Packages (pacotes)**. 1. Selecione **npm-public-registry-gateway**. 1. Certifique-se de que `lodash` seja exibido. A coluna **Versão mais recente** indica `4.17.20`. 1. Repita esse procedimento para o `codecatalyst-package-repository`. Talvez seja necessário atualizar a janela do navegador para ver o pacote importado. **Para testar o “Hello World” em seu Ambiente de Desenvolvimento** 1. Mude para o Ambiente de Desenvolvimento. 1. Verifique se você ainda está no diretório `hello-world-app` e execute a aplicação: ``` node index.js ``` Uma mensagem `Hello World` é exibida. O Node.js executou a aplicação usando o pacote `lodash` que você baixou para o Ambiente de Desenvolvimento em uma etapa anterior. **Como ignorar o diretório “node\$1modules” e confirmar “Hello World”** 1. Ignore o diretório `node_modules`. Insira: ``` echo "node_modules/" >> .gitignore ``` É uma prática recomendada evitar confirmar esse diretório. Além disso, a confirmação desse diretório interferirá nas etapas posteriores neste tutorial. 1. Adicione, confirme e envie: ``` git add . git commit -m "add the Hello World application" git push ``` Os arquivos da aplicação e do projeto “Hello World” são adicionados ao repositório de origem. ## Etapa 4: criar um fluxo de trabalho que execute o “Hello World” Nesta etapa, crie um fluxo de trabalho que executará a aplicação “Hello World” usando a dependência `lodash`. O fluxo de trabalho inclui uma única *ação* ou tarefa chamada `RunHelloWorldApp`. A ação `RunHelloWorldApp` inclui os seguintes comandos e seções notáveis: + **`Packages`** Esta seção indica o nome do repositório de CodeCatalyst pacotes ao qual a ação deve se conectar durante a execução`npm install`. + **`- Run: npm install`** Esse comando instrui o npm a instalar as dependências especificadas no arquivo `package.json`. A única dependência especificada no arquivo `package.json` é `lodash`. O npm procura `lodash` nos seguintes locais: + Na imagem do Docker que executa a ação. Ele não consegue encontrá-lo aqui. + No repositório de CodeCatalyst pacotes. Ele o encontra aqui. Depois que o npm encontra `lodash`, ele o importa para a imagem do Docker que executa a ação. + **`- Run: npm list`** Esse comando imprime qual versão do `lodash` foi baixada para a imagem do Docker que executa a ação. + **`- Run: node index.js`** Esse comando executa a aplicação “Hello World” usando a dependência especificada no arquivo `package.json`. Observe que a ação `RunHelloWorldApp` é uma ação de criação, conforme indicado pelo identificador `aws/build@v1` próximo à parte superior do fluxo de trabalho. Para ter mais informações sobre a ação de criação, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). Use as instruções a seguir para criar um fluxo de trabalho que extraia a `lodash` dependência do seu repositório de CodeCatalyst pacotes e, em seguida, execute seu aplicativo “Hello World”. **Para criar um fluxo de trabalho** 1. Mude para o CodeCatalyst console. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione **Criar fluxo de trabalho**. 1. Em **Repositório de origem**, selecione `hello-world-app`. 1. Em **Ramificação**, selecione `main`. O arquivo de definição do fluxo de trabalho será criado no repositório de origem e na ramificação escolhidos. 1. Escolha **Criar**. 1. Selecione **YAML** na parte superior. 1. Exclua o código de amostra YAML. 1. Adicione o seguinte código YAML: ``` Name: codecatalyst-package-workflow SchemaVersion: "1.0" # Required - Define action configurations. Actions: RunHelloWorldApp: # Identifies the action. Do not modify this value. Identifier: aws/build@v1 Compute: Type: Lambda Inputs: Sources: - WorkflowSource # This specifies your source repository. Configuration: Steps: - Run: npm install - Run: npm list - Run: node index.js Container: # This specifies the Docker image that runs the action. Registry: CODECATALYST Image: CodeCatalystLinuxLambda_x86_64:2024_03 Packages: NpmConfiguration: PackageRegistries: - PackagesRepository: codecatalyst-package-repository ``` No código anterior, *codecatalyst-package-repository* substitua pelo nome do repositório de CodeCatalyst pacotes que você criou. [Etapa 2: Criar os repositórios de pacotes CodeCatalyst e gateway](#packages-tutorial-package-repo) Para ter informações sobre as propriedades nesse arquivo, consulte a [Ações de criação e de teste YAML](build-action-ref.md). 1. (Opcional) Selecione **Validar** para garantir que o código YAML seja válido antes de confirmar. 1. Selecione **Confirmar**. 1. Na caixa de diálogo **Confirmar fluxo de trabalho**, insira o seguinte: 1. Em **Nome do arquivo do fluxo de trabalho**, mantenha o padrão, `codecatalyst-package-workflow`. 1. Em **Confirmar mensagem**, insira: ``` add initial workflow file ``` 1. Em **Repositório**, selecione **hello-world-app**. 1. Em **Nome da ramificação**, selecione **principal**. 1. Selecione **Confirmar**. Agora você criou um fluxo de trabalho. **Para executar o fluxo de trabalho** 1. Ao lado do fluxo de trabalho que você acabou de criar (`codecatalyst-package-workflow`), selecione **Ações** e, depois, selecione **Executar**. A execução do fluxo de trabalho é iniciada. 1. Na notificação verde na parte superior, à direita, escolha o link para a execução. O link é semelhante a `View Run-1234`. Um diagrama do fluxo de trabalho é exibido, mostrando quem iniciou a execução e a **RunHelloWorldApp**ação. 1. Escolha a caixa de **RunHelloWorldApp**ação para observar o progresso da ação. 1. Quando a execução terminar, vá para [Etapa 5: verificar o fluxo de trabalho](#packages-tutorial-verify). ## Etapa 5: verificar o fluxo de trabalho Nesta etapa, você verifica se o fluxo de trabalho executou a aplicação “Hello World” com a dependência `lodash`. **Como verificar se a aplicação “Hello World” foi executada usando a dependência** 1. No diagrama do fluxo de trabalho, escolha a **RunHelloWorldApp**caixa. Uma lista de mensagens de log é exibida. 1. Expanda a mensagem de log `node index.js`. A seguinte mensagem é exibida: ``` [Container] 2024/04/24 21:15:41.545650 Running command node index.js Hello World ``` A aparência de `Hello Word` (em vez de `hello-world`) indica que a dependência `lodash` foi usada. 1. Expanda o log `npm list`. Uma mensagem semelhante à seguinte é exibida: ``` └── lodash@4.17.20 ``` Essa mensagem indica que a versão 4.17.20 de `lodash` foi baixada para a imagem do Docker que executa a ação do fluxo de trabalho. ## Etapa 6: bloquear importações de npmjs.com Agora que a `lodash` versão 4.17.20 está presente em seu gateway e repositórios de CodeCatalyst pacotes, você pode bloquear importações de outras versões. O bloqueio impede que você importe acidentalmente versões posteriores (ou anteriores) do`lodash`, que podem conter código malicioso. Para obter mais informações, consulte [Editar controles de origem do pacote](package-origin-controls.md) e [Ataques de substituição de dependências](package-origin-controls.md#dependency-substitution-attacks). Use as instruções a seguir para bloquear as importações de `lodash` do seu repositório de gateway. Quando você bloqueia pacotes no gateway, eles também são bloqueados em locais posteriores. **Para bloquear importações para o repositório de gateway** 1. No painel de navegação, selecione **Packages (pacotes)**. 1. Selecione **npm-publish-registry-gateway**. 1. Selecione `lodash`. 1. Na parte superior, selecione **Controles de origem**. 1. Em **Upstream**, selecione **Bloquear**. 1. Escolha **Salvar**. Agora você bloqueou as importações para seu repositório de gateway (e repositórios e computadores downstream) em npmjs.com. ## Etapa 7: testar o recurso de bloqueio Nesta seção, você verifica se o bloqueio configurado em [Etapa 6: bloquear importações de npmjs.com](#packages-tutorial-block) está funcionando. Você começa configurando o “Hello World” para solicitar a versão 4.17.2**1** de `lodash` em vez da disponível no seu repositório de gateway, que é a 4.17.2**0**. Depois, você confere se a aplicação não pode extrair a versão 4.17.21 do nmpjs.com, indicando um bloqueio bem-sucedido. Como teste final, você desbloqueia as importações para o repositório do gateway e confere se a aplicação consegue extrair a versão 4.17.21 de `lodash`. Use o conjunto de procedimentos a seguir para testar o recurso de bloqueio. **Antes de começar** 1. Mude para o Ambiente de Desenvolvimento. 1. Extraia o `codecatalyst-package-workflow.yaml` arquivo que você criou usando o CodeCatalyst console anteriormente: ``` git pull ``` **Como configurar “Hello World” para solicitar a versão 4.17.21 de “lodash”** 1. Abra o `/hello-world-app/package.json`. 1. Altere a `lodash` versão para 4.17.21 conforme mostrado em: ***red bold*** ``` { "name": "hello-world-app", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", "dependencies": { "lodash": "4.17.21" } } ``` Agora há uma incompatibilidade entre a versão no `package.json` arquivo (4.17.21) e a versão no gateway e nos repositórios de CodeCatalyst pacotes (4.17.20). 1. Adicione, confirme e envie: ``` git add . git commit -m "update package.json to use lodash 4.17.21" git push ``` **Como testar se o “Hello World” não pode receber a versão 4.17.21 de “lodash”** 1. Execute o fluxo de trabalho com a incompatibilidade de versão: 1. Mude para o CodeCatalyst console. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Ao lado de `codecatalyst-package-workflow`, selecione **Ação** e **Executar**. O npm examina em `package.json` as dependências e vê que a versão 4.17.21 de `lodash` é exigida pelo “Hello World”. O npm procura a dependência nos seguintes locais, na seguinte ordem: + Na imagem do Docker que executa a ação. Ele não consegue encontrá-lo aqui. + No repositório de CodeCatalyst pacotes. Ele não consegue encontrá-lo aqui. + No repositório de gateway. Ele não consegue encontrá-lo aqui. + Em npmjs.com. Ele o encontra aqui. Depois que o npm encontra a versão 4.17.21 em npmjs.com, ele tenta importá-la para o repositório do gateway, mas como você configura o gateway para bloquear as importações de `lodash`, a importação não ocorre. Como a importação não ocorre, o fluxo de trabalho falha. 1. Verifique se o fluxo de trabalho falhou: 1. Na notificação verde na parte superior, à direita, escolha o link para a execução. O link é semelhante a `View Run-2345`. 1. No diagrama do fluxo de trabalho, escolha a **RunHelloWorldApp**caixa. 1. Expanda a mensagem de log `npm install`. A seguinte mensagem é exibida: ``` [Container] 2024/04/25 17:20:34.995591 Running command npm install npm ERR! code ETARGET npm ERR! notarget No matching version found for lodash@4.17.21. npm ERR! notarget In most cases you or one of your dependencies are requesting npm ERR! notarget a package version that doesn't exist. npm ERR! A complete log of this run can be found in: /tmp/.npm/_logs/2024-05-08T22_03_26_493Z-debug-0.log ``` O erro indica que a versão 4.17.21 não foi encontrada. Isso é esperado porque você a bloqueou. **Para desbloquear importações de npmjs.com** 1. No painel de navegação, selecione **Packages (pacotes)**. 1. Selecione **npm-publish-registry-gateway**. 1. Selecione `lodash`. 1. Na parte superior, selecione **Controles de origem**. 1. Em **Upstream**, selecione **Permitir**. 1. Escolha **Salvar**. Agora você desbloqueou as importações de `lodash`. Seu fluxo de trabalho agora pode importar a versão 4.17.21 de `lodash`. **Para testar se as importações de npmjs.com estão desbloqueadas** 1. Execute o fluxo de trabalho novamente. Desta vez, o fluxo de trabalho deve ser bem-sucedido porque a importação de 4.17.21 agora deve funcionar. Para executar o fluxo de trabalho novamente: 1. Selecione **CI/CD** e, depois, selecione **Fluxos de trabalho**. 1. Ao lado de `codecatalyst-package-workflow`, selecione **Ações** e **Executar**. 1. Na notificação verde na parte superior, à direita, escolha o link para a execução. O link é semelhante a `View Run-3456`. Um diagrama do fluxo de trabalho é exibido, mostrando quem iniciou a execução e a **RunHelloWorldApp**ação. 1. Escolha a caixa de **RunHelloWorldApp**ação para observar o progresso da ação. 1. Expanda a mensagem de log `npm list` e verifique se uma mensagem semelhante à seguinte é exibida: ``` └── lodash@4.17.21 ``` Essa mensagem indica que a versão 4.17.21 de `lodash` foi baixada. 1. Verifique se a versão 4.17.21 foi importada para seus repositórios CodeCatalyst e repositórios do gateway: 1. No painel de navegação, selecione **Packages (pacotes)**. 1. Selecione **npm-public-registry-gateway**. 1. Encontre `lodash` e verifique se a versão é `4.17.21`. **nota** Embora a versão 4.17.20 não esteja listada nesta página, você pode encontrá-la escolhendo `lodash` e **Versões** na parte superior. 1. Repita essas etapas para verificar se a versão 4.17.21 foi importada para o `codecatalyst-package-repository`. ## Limpeza Limpe os arquivos e serviços usados neste tutorial para evitar cobranças por eles. **Para limpar os pacotes (tutorial)** 1. Exclua o `codecatalyst-package-project`: 1. No CodeCatalyst console, navegue até o `codecatalyst-package-project` projeto se você ainda não estiver lá. 1. No painel de navegação, escolha **Configurações do projeto**. 1. Selecione **Excluir projeto**, insira **delete** e selecione **Excluir projeto**. CodeCatalyst exclui todos os recursos do projeto, incluindo os repositórios de origem, gateway e CodeCatalyst pacotes. O Ambiente de Desenvolvimento também é excluído. 1. Exclua o token PAT: 1. Escolha seu nome de usuário à direita e selecione **Minhas configurações**. 1. Em **Tokens de acesso pessoal**, escolha o token que você criou neste tutorial e selecione **Excluir**. Neste tutorial, você aprendeu a criar um fluxo de trabalho que executa um aplicativo que extrai suas dependências de um CodeCatalyst repositório de pacotes. Você também aprendeu a bloquear e desbloquear a entrada de pacotes no gateway e nos repositórios de CodeCatalyst pacotes. # Especificação de repositórios de CodeCatalyst pacotes em fluxos de trabalho Em CodeCatalyst, você pode adicionar um repositório de CodeCatalyst pacotes às suas ações de criação e teste em seu fluxo de trabalho. Seu repositório de pacotes deve ser configurado com um formato de pacote, como npm. Você também pode optar por incluir uma sequência de escopos para o repositório de pacotes selecionado. Use as instruções a seguir para especificar uma configuração de pacote a ser usada com uma ação de fluxo de trabalho. ------ #### [ Visual ] **Como especificar a configuração do pacote que uma ação usará (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação **Criar** ou **Testar** com a qual você deseja configurar com um repositório de pacotes. 1. Selecione **Pacotes**. 1. No menu suspenso **Adicionar configuração**, selecione a configuração de pacote que você deseja usar com as ações do fluxo de trabalho. 1. Selecione **Adicionar repositório de pacotes**. 1. No menu suspenso **Package repository**, especifique o nome do *repositório de CodeCatalyst pacotes* que você deseja que a ação use. Para ter mais informações sobre repositórios de pacote, consulte [Repositórios de pacotes](packages-concepts.md#packages-concepts-repository). 1. (Opcional) Em **Escopos – opcional**, especifique uma sequência de *escopos* que deseja definir no registro do pacote. Na definição de escopos, o repositório de pacotes especificado é configurado como o registro para todos os escopos listados. Se um pacote com o escopo for solicitado por meio do cliente npm, ele usará esse repositório em vez do padrão. Cada nome de escopo deve ter o prefixo “@”. Se `Scopes` for omitido, o repositório de pacotes especificado será configurado como o registro padrão para todos os pacotes usados pela ação. Para ter mais informações sobre escopos, consulte [Namespaces de pacote](packages-concepts.md#packages-concepts-package-namespaces) e [Pacotes com escopo definido](https://docs.npmjs.com/cli/v10/using-npm/scope). 1. Escolha **Adicionar**. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Como especificar a configuração do pacote que uma ação usará (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma ação **Criar** ou **Testar**, adicione um código semelhante ao seguinte: ``` action-name: Configuration: Packages: NpmConfiguration: PackageRegistries: - PackagesRepository: package-repository Scopes: - "@scope" ``` Para ter mais informações, consulte a descrição da propriedade `Packages` em [Ações de criação e de teste YAML](build-action-ref.md) para sua ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Usar tokens de autorização em ações de fluxo de trabalho Você pode usar um token fornecido pela ação do fluxo de trabalho para configurar manualmente um gerenciador de pacotes para se autenticar com repositórios de CodeCatalyst pacotes. CodeCatalyst disponibiliza esse token como uma variável de ambiente para você referenciar em suas ações. | Variável de ambiente | Valor | | --- | --- | | CATALYST\$1MACHINE\$1RESOURCE\$1NAME | A identidade do usuário do token de autorização. | | CATALYST\$1PACKAGES\$1AUTHORIZATION\$1TOKEN | O valor do token de autorização. | **nota** Observe que essas variáveis de ambiente só serão preenchidas se você tiver configurado sua ação para exportar o token de autorização. Use as instruções a seguir para usar um token de autorização com uma ação de fluxo de trabalho. ------ #### [ Visual ] **Como usar um token de autorização exportado com uma ação (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação **Criar** ou **Testar** com a qual você deseja configurar com um repositório de pacotes. 1. Selecione **Pacotes**. 1. Ative o **token de autorização de exportação**. ------ #### [ YAML ] **Como usar um token de autorização exportado com uma ação (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma ação **Criar** ou **Testar**, adicione um código semelhante ao seguinte: ``` Actions: action-name: Packages: ExportAuthorizationToken: true ``` Você pode referenciar as variáveis de ambiente `$CATALYST_MACHINE_RESOURCE_NAME` e `$CATALYST_PACKAGES_AUTHORIZATION_TOKEN` na seção `Steps` do seu YAML. Para obter mais informações, consulte [Exemplo: configuração manual `pip` para autenticação com CodeCatalyst](workflows-working-packages-ex.md#workflows-working-packages-pypi-token). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Exemplos: repositórios de pacotes em fluxos de trabalho Os exemplos a seguir mostram como referenciar pacotes no arquivo de definição de fluxo de trabalho. **Topics** + [ ## Exemplo: definição de pacotes com `NpmConfiguration` ](#workflows-working-packages-ex-basic) + [ ## Exemplo: substituição do registro padrão ](#workflows-working-packages-ex-overriding-registry) + [ ## Exemplo: substituição de escopos em seu registro de pacotes ](#workflows-working-packages-ex-overriding-scopes) + [ ## Exemplo: configuração manual `pip` para autenticação com CodeCatalyst ](#workflows-working-packages-pypi-token) ## Exemplo: definição de pacotes com `NpmConfiguration` O exemplo a seguir mostra como definir um pacote com `NpmConfiguration` no arquivo de definição do fluxo de trabalho. ``` Actions: Build: Identifier: aws/build-beta@v1 Configuration: Packages: NpmConfiguration: PackageRegistries: - PackagesRepository: main-repo - PackagesRepository: scoped-repo Scopes: - "@scope1" ``` Este exemplo configura o cliente npm da seguinte forma: ``` default: main-repo @scope1: scoped-repo ``` Neste exemplo, há dois repositórios definidos. O registro padrão é definido como `main-repo` sem um escopo. O escopo `@scope1` está configurado em `PackageRegistries` para `scoped-repo`. ## Exemplo: substituição do registro padrão O exemplo a seguir mostra como substituir o registro padrão. ``` NpmConfiguration: PackageRegistries: - PackagesRepository: my-repo-1 - PackagesRepository: my-repo-2 - PackagesRepository: my-repo-3 ``` Este exemplo configura o cliente npm da seguinte forma: ``` default: my-repo-3 ``` Se você especificar vários repositórios padrão, o último repositório terá prioridade. Neste exemplo, o último repositório listado é `my-repo-3`, o que significa que o npm se conectará a `my-repo-3`. Isso substitui os repositórios `my-repo-1` e `my-repo-2`. ## Exemplo: substituição de escopos em seu registro de pacotes O exemplo a seguir mostra como substituir um escopo em seu registro de pacotes. ``` NpmConfiguration: PackageRegistries: - PackagesRepository: my-default-repo - PackagesRepository: my-repo-1 Scopes: - "@scope1" - "@scope2" - PackagesRepository: my-repo-2 Scopes: - "@scope2" ``` Este exemplo configura o cliente npm da seguinte forma: ``` default: my-default-repo @scope1: my-repo-1 @scope2: my-repo-2 ``` Se você incluir escopos substitutos, o último repositório terá prioridade. Neste exemplo, a última vez em que o escopo `@scope2` foi configurado em `PackageRegistries` é para `my-repo-2`. Isso substitui o escopo `@scope2` configurado para `my-repo-1`. ## Exemplo: configuração manual `pip` para autenticação com CodeCatalyst O exemplo a seguir mostra como referenciar variáveis de ambiente de CodeCatalyst autorização em uma ação de criação. ``` Actions: Build: Identifier: aws/build@v1.0.0 Configuration: Steps: - Run: pip config set global.index-url https://$CATALYST_MACHINE_RESOURCE_NAME:$CATALYST_PACKAGES_AUTHORIZATION_TOKEN@codecatalyst.aws/pypi/my-space/my-project/my-repo/simple/ Packages: ExportAuthorizationToken: true ``` # Invocar uma função do Lambda usando um fluxo de trabalho Esta seção descreve como invocar uma AWS Lambda função usando um CodeCatalyst fluxo de trabalho. Para fazer isso, você deve adicionar a ação **Invocação do AWS Lambda ** ao seu fluxo de trabalho. A ação **Invocação do AWS Lambda ** invoca a função do Lambda que você especifica. Além de invocar sua função, a ação **Invocação do AWS Lambda ** também converte cada chave de nível superior na carga útil de resposta recebida da função do Lambda em uma [variável de saída do fluxo de trabalho](workflows-working-with-variables.md). Essas variáveis podem ser referenciadas em ações subsequentes do fluxo de trabalho. Se você não quiser que todas as chaves de nível superior sejam convertidas em variáveis, use filtros para especificar as chaves exatas. Para ter mais informações, consulte a descrição da propriedade [ResponseFilters](lam-invoke-action-ref.md#lam.invoke.response.filters) na [YAML da ação “Invocação do AWS Lambda ”](lam-invoke-action-ref.md). **Topics** + [ ## Quando usar essa ação ](#lam-invoke-action-when-to-use) + [ ## Imagem de tempo de execução usada pela AWS Lambda ação 'invocar' ](#lam-invoke-action-runtime) + [ # Exemplo: invocar uma função do Lambda ](lam-invoke-action-example-workflow.md) + [ # Adicionando a ação 'AWS Lambda invocar' ](lam-invoke-action-add.md) + [ # Variáveis de “Invocação do AWS Lambda ” ](lam-invoke-action-variables.md) + [ # YAML da ação “Invocação do AWS Lambda ” ](lam-invoke-action-ref.md) ## Quando usar essa ação Use essa ação se quiser adicionar funcionalidade ao seu fluxo de trabalho que é encapsulada e executada por uma função do Lambda. Por exemplo, talvez você queira que seu fluxo de trabalho envie uma notificação `Build started` para um canal do Slack antes de começar a criar a aplicação. Nesse caso, seu fluxo de trabalho incluiria uma ação **Invocação do AWS Lambda ** para invocar um Lambda para enviar a notificação do Slack e uma [ação de criação](build-add-action.md) para criar a aplicação. Como outro exemplo, você talvez queira que o fluxo de trabalho realize uma verificação de vulnerabilidade na aplicação antes de ser implantada. Nesse caso, você usaria uma ação de criação para criar a aplicação, uma ação **Invocação do AWS Lambda ** para invocar um Lambda para verificar vulnerabilidades e uma ação de implantação para implantar a aplicação verificada. ## Imagem de tempo de execução usada pela AWS Lambda ação 'invocar' A ação **Invocação do AWS Lambda ** é executada em uma [imagem de novembro de 2022](build-images.md#build.previous-image). Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). # Exemplo: invocar uma função do Lambda O exemplo de fluxo de trabalho a seguir inclui a ação **Invocação do AWS Lambda **, junto com uma ação de implantação. O fluxo de trabalho envia uma notificação do Slack indicando que uma implantação foi iniciada e, em seguida, implanta um aplicativo AWS usando um CloudFormation modelo. O fluxo de trabalho consiste nos seguintes blocos de compilação que são executados sequencialmente: + Um **gatilho**: esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + Uma ação **Invocação do AWS Lambda ** (`LambdaNotify`) — No gatilho, essa ação invoca a função do Lambda `Notify-Start` na conta da AWS e região especificadas (`my-aws-account` e `us-west-2`). Na invocação, a função do Lambda envia uma notificação do Slack indicando que a implantação foi iniciada. + Uma ação **Deploy CloudFormation stack** (`Deploy`) — Ao concluir a ação de **AWS Lambda invocação**, a ação **Deploy CloudFormation stack** executa o template (`cfn-template.yml`) para implantar sua pilha de aplicativos. Para obter mais informações sobre a ação **Deploy CloudFormation stack**, consulte[Implantação de uma pilha CloudFormation](deploy-action-cfn.md). **nota** O exemplo de fluxo de trabalho a seguir serve para fins ilustrativos e não funcionará sem configuração adicional. **nota** No código YAML a seguir, você pode omitir as seções `Connections:` se quiser. Se você omitir essas seções, deverá garantir que a função especificada no campo Função **padrão do IAM** em seu ambiente inclua as permissões e as políticas de confiança exigidas pelas ações de **AWS Lambda invocação** e **implantação da CloudFormation pilha**. Para ter mais informações sobre como configurar um ambiente com um perfil do IAM padrão, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Para obter mais informações sobre as permissões e as políticas de confiança exigidas pelas ações **AWS Lambda invoke** e **Deploy CloudFormation stack**, consulte a descrição da `Role` propriedade em e. [YAML da ação “Invocação do AWS Lambda ”](lam-invoke-action-ref.md) [Ação “Implantar CloudFormation pilha” YAML](deploy-action-ref-cfn.md) ``` Name: codecatalyst-lamda-invoke-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: LambdaNotify: Identifier: aws/lambda-invoke@v1 Environment: Name: my-production-environment Connections: - Name: my-aws-account Role: codecatalyst-lambda-invoke-role Inputs: Sources: - WorkflowSource Configuration: Function: Notify-Start AWSRegion: us-west-2 Deploy: Identifier: aws/cfn-deploy@v1 Environment: Name: my-production-environment Connections: - Name: my-aws-account Role: codecatalyst-deploy-role Inputs: Sources: - WorkflowSource Configuration: name: my-application-stack region: us-west-2 role-arn: arn:aws:iam::111122223333:role/StackRole template: ./cfn-template.yml capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND ``` # Adicionando a ação 'AWS Lambda invocar' Use as instruções a seguir para adicionar a ação **Invocação do AWS Lambda ** ao seu fluxo de trabalho. **Pré-requisito** Antes de começar, certifique-se de que sua AWS Lambda função e a função de execução do Lambda associada estejam prontas e disponíveis no. AWS Para ter mais informações, consulte [Perfil de execução do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) no *Guia do desenvolvedor do AWS Lambda *. ------ #### [ Visual ] **Para adicionar a ação 'AWS Lambda invocar' usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Invocação do AWS Lambda ** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Invocação do AWS Lambda **. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas**, **Configuração** e **Saídas**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [YAML da ação “Invocação do AWS Lambda ”](lam-invoke-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar a ação 'AWS Lambda invocar' usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Procure a ação **Invocação do AWS Lambda ** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione **Invocação do AWS Lambda **. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [YAML da ação “Invocação do AWS Lambda ”](lam-invoke-action-ref.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Variáveis de “Invocação do AWS Lambda ” Por padrão, a ação **Invocação do AWS Lambda ** produz uma variável por chave de nível superior na carga útil de resposta do Lambda. Por exemplo, se a carga útil de resposta for semelhante a esta: ``` responsePayload = { "name": "Saanvi", "location": "Seattle", "department": { "company": "Amazon", "team": "AWS" } } ``` ... a ação vai gerar as seguintes variáveis. | Chave | Valor | | --- | --- | | name | Saanvi | | location | Seattle | | department | \$1"company": "Amazon", "team": "AWS"\$1 | **nota** Você pode alterar quais variáveis são geradas usando a propriedade YAML `ResponseFilters`. Para obter mais informações, consulte o [ResponseFilters](lam-invoke-action-ref.md#lam.invoke.response.filters) no [YAML da ação “Invocação do AWS Lambda ”](lam-invoke-action-ref.md). As variáveis produzidas e definidas pela ação 'AWS Lambda invoke' em tempo de execução são conhecidas como variáveis *predefinidas*. Para ter informações sobre como referenciar essas variáveis em um fluxo de trabalho, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). # YAML da ação “Invocação do AWS Lambda ” Confira a seguir a definição de YAML da ação **Invocação do AWS Lambda **. Para saber como usar essa ação, consulte [Invocar uma função do Lambda usando um fluxo de trabalho](lam-invoke-action.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. LambdaInvoke\$1nn: Identifier: aws/lambda-invoke@v1 DependsOn: - dependent-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - request-payload Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Configuration: Function: my-function|function-arn AWSRegion: us-west-2 # Specify RequestPayload or RequestPayloadFile, but not both. RequestPayload: '{"firstname": "Li", lastname: "Jean", "company": "ExampleCo", "team": "Development"}' RequestPayloadFile: my/request-payload.json ContinueOnError: true|false LogType: Tail|None ResponseFilters: '{"name": ".name", "company": ".department.company"}' Outputs: Artifacts: - Name: lambda_artifacts Files: - "lambda-response.json" ``` ## LambdaInvoke (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Padrão: `Lambda_Invoke_Action_Workflow_nn`. Interface de usuário correspondente: guia Configuração/**Nome da ação** ## Identifier (*LambdaInvoke*/**Identifier**) (Obrigatório) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Padrão: `aws/lambda-invoke@v1`. Interface de usuário correspondente: diagrama de fluxo de trabalho/rótuloLambdaInvoke\$1nn/**aws/lambda-invoke@v1** ## DependsOn (*LambdaInvoke*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*LambdaInvoke*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*LambdaInvoke*/Compute/**Type**) (Obrigatório se [Compute](#lam.invoke.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2**(editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). Interface de usuário correspondente: guia Configuração/**Tipo de computação** ## Fleet (*LambdaInvoke*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. Interface de usuário correspondente: guia Configuração/**Frota de computação** ## Timeout (*LambdaInvoke*/**Timeout**) (Obrigatório) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Inputs (*LambdaInvoke*/**Inputs**) (Obrigatório) A seção `Inputs` define os dados que a ação **Invocação do AWS Lambda ** precisa durante a execução de um fluxo de trabalho. **nota** Somente uma entrada (uma origem ou um artefato) é permitida por ação **Invocação do AWS Lambda **. As variáveis não são contadas nesse total. Interface de usuário correspondente: guia **Entradas** ## Sources (*LambdaInvoke*/Inputs/**Sources**) (Obrigatório se [RequestPayloadFile](#lam.invoke.request.payload.file)for fornecido) Se você quiser transmitir um arquivo JSON de carga útil de solicitação para a ação **Invocação do AWS Lambda **, e esse arquivo de carga útil estiver armazenado em um repositório de origem, especifique o rótulo desse repositório de origem. Atualmente, o único rótulo compatível é `WorkflowSource`. Se o arquivo de carga útil de solicitação não estiver em um repositório de origem, ele deverá residir em um artefato gerado por outra ação. Para ter mais informações sobre o arquivo de carga útil, consulte [RequestPayloadFile](#lam.invoke.request.payload.file). **nota** Em vez de especificar um arquivo de carga útil, você pode adicionar o código JSON da carga útil diretamente à ação usando a propriedade `RequestPayload`. Para obter mais informações, consulte [RequestPayload](#lam.invoke.request.payload). Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*LambdaInvoke*/Inputs/**Artifacts**) (Obrigatório se [RequestPayloadFile](#lam.invoke.request.payload.file)for fornecido) Se você quiser transmitir um arquivo JSON de carga útil de solicitação para a ação **Invocação do AWS Lambda **, e esse arquivo de carga estiver contido em um [artefato de saída](build-action-ref.md#build.outputs.artifacts) de uma ação anterior, especifique esse artefato aqui. Para ter mais informações sobre o arquivo de carga útil, consulte [RequestPayloadFile](#lam.invoke.request.payload.file). **nota** Em vez de especificar um arquivo de carga útil, você pode adicionar o código JSON da carga útil diretamente à ação usando a propriedade `RequestPayload`. Para obter mais informações, consulte [RequestPayload](#lam.invoke.request.payload). Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Configuração/**Artefatos - opcional** ## Variables - input (*LambdaInvoke*/Inputs/**Variables**) (Optional) Especifique uma sequência de name/value pares que defina as variáveis de entrada que você deseja disponibilizar para a ação. Os nomes de variável são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de variável. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Interface de usuário correspondente: guia Entradas/**Variáveis - opcional** ## Environment (*LambdaInvoke*/**Environment**) (Obrigatório) Especifique o CodeCatalyst ambiente a ser usado com a ação. A ação se conecta à Conta da AWS Amazon VPC opcional especificada no ambiente escolhido. A ação usa a função padrão do IAM especificada no ambiente para se conectar ao e usa a Conta da AWS função do IAM especificada na [conexão da Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) para se conectar à Amazon VPC. **nota** Se o perfil do IAM padrão não tiver as permissões exigidas pela ação, você poderá configurar a ação para usar um perfil diferente. Para obter mais informações, consulte [Alteração do perfil do IAM de uma ação](deploy-environments-switch-role.md). Para ter mais informações sobre ambientes, consulte [Implantação em e Contas da AWS VPCs](deploy-environments.md) e [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: guia Configuração/**Ambiente** ## Name (*LambdaInvoke*/Environment/**Name**) (Obrigatório se [Environment](#lam.invoke.environment) for incluído) Especifique o nome de um ambiente existente que deseja associar à ação. Interface de usuário correspondente: guia Configuração/**Ambiente** ## Connections (*LambdaInvoke*/Environment/**Connections**) (Opcional nas versões mais recentes da ação; obrigatório nas versões mais antigas) Especifique a conexão da conta a ser associada à ação. É possível especificar no máximo uma conexão de conta em `Environment`. Se você não especificar uma conexão de conta: + A ação usa a Conta da AWS conexão e a função padrão do IAM especificadas no ambiente no CodeCatalyst console. Para ter informações sobre como adicionar uma conexão de conta e um perfil do IAM padrão ao ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). + O perfil do IAM padrão deve incluir as políticas e as permissões exigidas pela ação. Para determinar quais são essas políticas e permissões, consulte a descrição da propriedade **Perfil** na documentação de definição de YAML da ação. Para ter mais informações sobre conexões de conta, consulte [Permitindo acesso a AWS recursos com conexão Contas da AWS](ipa-connect-account.md). Para ter informações sobre como adicionar uma conexão de conta a um ambiente, consulte [Criar um ambiente](deploy-environments-creating-environment.md). Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Name (*LambdaInvoke*/Environment/Connections/**Name**) (Obrigatório se [Connections](#lam.invoke.environment.connections) for incluído) Especifique o nome da conexão da conta. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' Environment/account/role AWS '/ conexão de conta** ## Role (*LambdaInvoke*/Environment/Connections/**Role**) (Obrigatório se [Connections](#lam.invoke.environment.connections) for incluído) Especifique o nome da função do IAM que a ação de **AWS Lambda invocação** usa para acessar AWS e invocar sua função Lambda. Certifique-se de ter [adicionado a função ao seu CodeCatalyst espaço](ipa-connect-account-addroles.md) e de que a função inclua as seguintes políticas. Se você não especificar uma função do IAM, a ação usará a função padrão do IAM listada no [ambiente](deploy-environments.md) no CodeCatalyst console. Se você usar o perfil padrão no ambiente, verifique se ele tem as políticas a seguir. + A política de permissões a seguir: **Atenção** Limite as permissões às exibidas na política a seguir. Usar um perfil com permissões mais amplas pode representar um risco de segurança. + A política de confiança personalizada a seguir: **nota** Você pode usar o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` com essa ação, se desejar. Para obter mais informações sobre essa função, consulte [Criar o perfil **CodeCatalystWorkflowDevelopmentRole-*spaceName*** para a conta e o espaço](ipa-iam-roles.md#ipa-iam-roles-service-create). Entenda que o perfil `CodeCatalystWorkflowDevelopmentRole-spaceName` tem permissões de acesso completas, o que pode representar um risco de segurança. Recomendamos que você use esse perfil apenas em tutoriais e em cenários em que a segurança seja menos preocupante. Interface de usuário correspondente: uma das seguintes, dependendo da versão da ação: + (Versões mais recentes) A configuração tab/Environment/What está pronta? *my-environment* **/menu de três pontos/ Mudar função** + **(Versões mais antigas) Guia de configuração/' '/ Função Environment/account/role** ## Configuration (*LambdaInvoke*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## Function (*LambdaInvoke*/Configuration/**Function**) (Obrigatório) Especifique a AWS Lambda função que essa ação invocará. Você pode especificar o nome da função ou o nome do recurso da Amazon (ARN). É possível encontrar o nome ou ARN no console do Lambda. **nota** A AWS conta na qual a função Lambda reside pode ser diferente da conta especificada em. `Connections:` Interface de usuário correspondente: guia Configuração/**Função** ## AWSRegion (*LambdaInvoke*/Configuration/**AWSRegion**) (Obrigatório) Especifique a AWS região em que sua AWS Lambda função reside. Para ver uma lista de códigos de região, consulte [Endpoints regionais](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints) na *Referência geral da AWS*. Interface de usuário correspondente: guia Configuração/**Bucket de destino - opcional** ## RequestPayload (*LambdaInvoke*/Configuration/**RequestPayload**) (Optional) Se você quiser transmitir uma carga útil de solicitação para a ação **Invocação do AWS Lambda **, especifique a carga útil da solicitação aqui, no formato JSON. Exemplo da carga útil de solicitação: ``` '{ "key": "value" }' ``` Se você não quiser transmitir uma carga útil de solicitação para sua função do Lambda, omita essa propriedade. **nota** Você pode especificar `RequestPayload` ou `RequestPayloadFile`, mas não os dois. Para ter mais informações sobre a carga útil da solicitação, consulte o tópico [Invocar](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) na *Referência da API do AWS Lambda *. Interface de usuário correspondente: guia Configuração/**Carga útil de solicitação - opcional** ## RequestPayloadFile (*LambdaInvoke*/Configuration/**RequestPayloadFile**) (Optional) Se você quiser transmitir uma carga útil de solicitação para a ação **Invocação do AWS Lambda **, especifique o caminho até essa carga útil aqui. O arquivo estar no formato JSON. O arquivo de carga útil da solicitação pode residir em um repositório de origem ou em um artefato de uma ação anterior. O caminho do arquivo é relativo ao repositório de origem ou à raiz do artefato. Se você não quiser transmitir uma carga útil de solicitação para sua função do Lambda, omita essa propriedade. **nota** Você pode especificar `RequestPayload` ou `RequestPayloadFile`, mas não os dois. Para ter mais informações sobre o arquivo de carga útil da solicitação, consulte o tópico [Invocar](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) na *Referência da API do AWS Lambda *. Interface de usuário correspondente: guia Configuração/**Arquivo de carga útil de solicitação - opcional** ## ContinueOnError (*LambdaInvoke*/Configuration/**RequestPayloadFile**) (Optional) Especifique se você deseja marcar a ação **Invocação do AWS Lambda ** como bem-sucedida, mesmo que a função invocada do AWS Lambda falhe. Considere definir essa propriedade como `true` para permitir que ações subsequentes em seu fluxo de trabalho sejam iniciadas apesar da falha do Lambda. O padrão é falhar na ação se a função do Lambda falhar (“desativada” no editor visual ou `false` no editor YAML). Interface de usuário correspondente: guia Configuração/**Continuar com erro** ## LogType (*LambdaInvoke*/Configuration/**LogType**) (Optional) Especifique se você deseja incluir logs de erros na resposta da função do Lambda depois que ela for invocada. Você pode ver esses registros na guia **Logs** **da ação de invocação do Lambda** no console. CodeCatalyst Os valores possíveis são: + `Tail` - logs de retorno + `None` - logs não de retorno O padrão é **Tail**. Para ter mais informações sobre o tipo de log, consulte o tópico [Invocar](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) na *Referência da API do AWS Lambda *. Para obter mais informações sobre como visualizar logs, consulte [Visualização do status e detalhes de execução do fluxo de trabalho](workflows-view-run.md). Interface de usuário correspondente: guia Configuração/**Tipo de log** ## ResponseFilters (*LambdaInvoke*/Configuration/**ResponseFilters**) (Optional) Especifique quais chaves na carga útil de resposta do Lambda você deseja converter em variáveis de saída. Em seguida, você pode referenciar as variáveis de saída em ações subsequentes no fluxo de trabalho. Para obter mais informações sobre variáveis em CodeCatalyst, consulte[Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Por exemplo, se a carga útil de resposta for semelhante a esta: ``` responsePayload = { "name": "Saanvi", "location": "Seattle", "department": { "company": "Amazon", "team": "AWS" } } ``` ... e os filtros de resposta forem semelhantes a estes: ``` Configuration: ... ResponseFilters: '{"name": ".name", "company": ".department.company"}' ``` ... a ação gera as seguintes variáveis de saída: | Chave | Valor | | --- | --- | | name | Saanvi | | company | Amazon | Depois, você pode referenciar as variáveis `name` e `company` em ações subsequentes. Se você não especificar nenhuma chave em `ResponseFilters`, a ação converterá cada chave de nível superior na resposta do Lambda em uma variável de saída. Para obter mais informações, consulte [Variáveis de “Invocação do AWS Lambda ”](lam-invoke-action-variables.md). Considere usar filtros de resposta para limitar as variáveis de saída geradas somente às que você realmente deseja usar. Interface de usuário correspondente: guia Configuração/**Filtros de resposta - opcional** ## Outputs (*LambdaInvoke*/**Outputs**) (Optional) Define os dados que são gerados pela ação durante a execução de um fluxo de trabalho. Interface de usuário correspondente: guia **Saídas** ## Artifacts (*LambdaInvoke*/Outputs/**Artifacts**) (Optional) Especifique os artefatos gerados pela ação. Você pode referenciar esses artefatos como entrada em outras ações. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Saídas/Artefatos/**Nome do artefato de criação** ## Name (*LambdaInvoke*/Outputs/Artifacts/**Name**) (Optional) Especifique o nome do artefato que conterá a carga útil de resposta do Lambda que é retornada pela função do Lambda. O valor padrão é `lambda_artifacts`. Se você não especificar um artefato, a carga útil da resposta do Lambda poderá ser visualizada nos registros da ação, que estão disponíveis na guia Registros **da** ação no console. CodeCatalyst Para obter mais informações sobre como visualizar logs, consulte [Visualização do status e detalhes de execução do fluxo de trabalho](workflows-view-run.md). Interface de usuário correspondente: guia Saídas/Artefatos/**Nome do artefato de criação** ## Files (*LambdaInvoke*/Outputs/Artifacts/**Files**) (Optional) Especifique os arquivos a serem incluídos no artefato. Você deve especificar `lambda-response.json` para que o arquivo de carga útil de resposta do Lambda seja incluído. Interface de usuário correspondente: guia Saídas/Artefatos/**Arquivos produzidos pela criação** # Modificação de uma definição de tarefa do Amazon ECS Esta seção descreve como atualizar o `image` campo em um arquivo de [definição de tarefa do Amazon Elastic Container Service (Amazon ECS) usando](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) um fluxo de trabalho. CodeCatalyst Para fazer isso, você deve adicionar a ação **Renderizar definição de tarefa do Amazon ECS** ao seu fluxo de trabalho. Essa ação atualiza o campo de imagem no arquivo de definição de tarefa com um nome de imagem do Docker fornecido pelo seu fluxo de trabalho no runtime. **nota** Você também pode usar esta ação para atualizar o campo `environment` da definição de tarefa com variáveis de ambiente. **Topics** + [ ## Quando usar essa ação ](#render-ecs-action-when-to-use) + [ ## Como a ação “Renderizar definição de tarefa do Amazon ECS” funciona ](#render-ecs-action-how-it-works) + [ ## Imagem de runtime usada pela ação “Renderizar definição de tarefa do Amazon ECS” ](#render-ecs-action-runtime) + [ # Exemplo: modificar uma definição de tarefa do Amazon ECS ](render-ecs-action-example-workflow.md) + [ # Adicionar a ação “Renderizar definição de tarefa do Amazon ECS” ](render-ecs-action-add.md) + [ # Visualização do arquivo de definição de tarefa atualizado ](render-ecs-action-view.md) + [ # Variáveis de “Renderizar definição de tarefa do Amazon ECS” ](render-ecs-action-variables.md) + [ # Ação YAML “Renderizar definição de tarefa do Amazon ECS” ](render-ecs-action-ref.md) ## Quando usar essa ação Use essa ação se você tiver um fluxo de trabalho que cria e marca uma imagem do Docker com conteúdo dinâmico, como um ID de confirmação ou carimbo de data/hora. Não use essa ação se o arquivo de definição de tarefa tiver um valor de imagem que permanece sempre o mesmo. Nesse caso, você pode inserir manualmente o nome da sua imagem no arquivo de definição de tarefa. ## Como a ação “Renderizar definição de tarefa do Amazon ECS” funciona Você deve usar a ação **Renderizar definição de tarefa do Amazon ECS** com as ações **Compilar** e **Implantar no Amazon ECS** em seu fluxo de trabalho. Juntas, essas ações funcionam da seguinte forma: 1. A ação de **criação** cria sua imagem do Docker e a marca com um nome, um ID de confirmação, um carimbo de data/hora ou outro conteúdo dinâmico. Por exemplo, sua ação de criação pode ser semelhante a esta: ``` MyECSWorkflow Actions: BuildAction: Identifier: aws/build@v1 ... Configuration: Steps: # Build, tag, and push the Docker image... - Run: docker build -t MyDockerImage:${WorkflowSource.CommitId} . ... ``` No código anterior, a diretiva `docker build -t` indica compilar a imagem do Docker e marcá-la com o ID de confirmação no runtime da ação. O nome da imagem gerada pode ser semelhante a este: `MyDockerImage:a37bd7e` 1. A ação **Renderizar definição de tarefa do Amazon ECS** adiciona o nome da imagem gerada dinamicamente, `MyDockerImage:a37bd7e`, ao seu arquivo de definição de tarefa, da seguinte forma: ``` { "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role", "containerDefinitions": [ { "name": "codecatalyst-ecs-container", "image": MyDockerImage:a37bd7e, "essential": true, ... "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ] } ], ... } ``` Opcionalmente, você também pode fazer com que a ação **Renderizar definição de tarefa do Amazon ECS** adicione variáveis de ambiente à definição de tarefa, assim: ``` { "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role", "containerDefinitions": [ { "name": "codecatalyst-ecs-container", "image": MyDockerImage:a37bd7e, ... "environment": [ { name": "ECS_LOGLEVEL", value": "info" } ] } ], ... } ``` Para ter mais informações sobre as variáveis de ambiente, consulte [Especificar variáveis de ambiente](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. 1. A ação **Implantar no Amazon ECS** registra o arquivo de definição de tarefa atualizado no Amazon ECS. O registro do arquivo de definição de tarefa atualizado implanta a nova imagem, `MyDockerImage:a37bd7e` no Amazon ECS. ## Imagem de runtime usada pela ação “Renderizar definição de tarefa do Amazon ECS” A ação **Renderizar definição de tarefa do Amazon ECS** é executada em uma [imagem de novembro de 2022](build-images.md#build.previous-image). Para obter mais informações, consulte [Imagens ativas](build-images.md#build-curated-images). # Exemplo: modificar uma definição de tarefa do Amazon ECS Veja a seguir um exemplo de um fluxo de trabalho completo que inclui a ação **Renderizar definição de tarefa do Amazon ECS**, junto com ações de compilação e implantação. O objetivo do fluxo de trabalho é compilar e implantar uma imagem do Docker em seu cluster do Amazon ECS. O fluxo de trabalho consiste nos seguintes blocos de compilação que são executados sequencialmente: + Um **gatilho**: esse gatilho inicia a execução automática do fluxo de trabalho quando você envia uma alteração ao seu repositório de origem. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). + Uma ação de **criação** (`BuildDocker`) – No gatilho, a ação compila a imagem do Docker usando o Dockerfile, a marca com um ID de confirmação e envia a imagem para o Amazon ECR. Para ter mais informações sobre a ação de criação, consulte [Criação com fluxos de trabalho](build-workflow-actions.md). + Uma ação **Renderizar definição de tarefa do Amazon ECS** (`RenderTaskDef`): na realização da ação de criação, essa ação atualiza um `taskdef.json` existente, localizado na raiz do repositório de origem, com um valor de campo `image` que inclui o ID de confirmação correto. O arquivo atualizado é salvo com um novo nome de arquivo (`task-definition-random-string.json`) e, depois, cria um artefato de saída que contém esse arquivo. A ação de renderização também gera uma variável chamada `task-definition` e a define como o nome do novo arquivo de definição de tarefa. O artefato e a variável serão usados na ação de implantação, que será a seguir. + Uma ação **Implantar no Amazon ECS** (`DeployToECS`) – Ao concluir a ação **Renderizar definição de tarefa do Amazon ECS**, a ação **Implantar no Amazon ECS** procura o artefato de saída gerado pela ação de renderização (`TaskDefArtifact`), encontra o arquivo `task-definition-random-string.json` dentro dele e o registra no seu serviço do Amazon ECS. Em seguida, o serviço do Amazon ECS segue as instruções no arquivo `task-definition-random-string.json` para executar as tarefas do Amazon ECS – e os contêineres de imagem do Docker associados – dentro do seu cluster do Amazon ECS. ``` Name: codecatalyst-ecs-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: BuildDocker: Identifier: aws/build@v1 Environment: Name: codecatalyst-ecs-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-ecs-build-role Inputs: Variables: - Name: REPOSITORY_URI Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo - Name: IMAGE_TAG Value: ${WorkflowSource.CommitId} Configuration: Steps: #pre_build: - Run: echo Logging in to Amazon ECR... - Run: aws --version - Run: aws ecr get-login-password --region us-east-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-2.amazonaws.com #build: - Run: echo Build started on `date` - Run: echo Building the Docker image... - Run: docker build -t $REPOSITORY_URI:latest . - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG #post_build: - Run: echo Build completed on `date` - Run: echo Pushing the Docker images... - Run: docker push $REPOSITORY_URI:latest - Run: docker push $REPOSITORY_URI:$IMAGE_TAG RenderTaskDef: DependsOn: - BuildDocker Identifier: aws/ecs-render-task-definition@v1 Inputs: Variables: - Name: REPOSITORY_URI Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo - Name: IMAGE_TAG Value: ${WorkflowSource.CommitId} Configuration: task-definition: taskdef.json container-definition-name: codecatalyst-ecs-container image: $REPOSITORY_URI:$IMAGE_TAG # The output artifact contains the updated task definition file. # The new file is prefixed with 'task-definition'. # The output variable is set to the name of the updated task definition file. Outputs: Artifacts: - Name: TaskDefArtifact Files: - "task-definition*" Variables: - task-definition DeployToECS: Identifier: aws/ecs-deploy@v1 Environment: Name: codecatalyst-ecs-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-ecs-deploy-role #Input artifact contains the updated task definition file. Inputs: Sources: [] Artifacts: - TaskDefArtifact Configuration: region: us-east-2 cluster: codecatalyst-ecs-cluster service: codecatalyst-ecs-service task-definition: ${RenderTaskDef.task-definition} ``` # Adicionar a ação “Renderizar definição de tarefa do Amazon ECS” Use as instruções a seguir para adicionar a ação **Renderizar definição de tarefa do Amazon ECS** ao seu fluxo de trabalho. **Pré-requisito** Antes de começar, verifique se você tem um fluxo de trabalho que inclua uma ação de criação que gere dinamicamente uma imagem do Docker. Consulte o [fluxo de trabalho de exemplo](render-ecs-action-example-workflow.md) anterior para saber detalhes. ------ #### [ Visual ] **Como adicionar a ação “Renderizar definição de tarefa do Amazon ECS” usando o editor visual** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Pesquise a ação **Renderizar definição de tarefa do Amazon ECS** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione a opção **Renderizar definição de tarefa do Amazon ECS**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [Ação YAML “Renderizar definição de tarefa do Amazon ECS”](render-ecs-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para adicionar a ação “Renderizar definição de tarefa do Amazon ECS” usando o editor YAML** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. No canto superior esquerdo, selecione **\$1 Ações** para abrir o catálogo de ações. 1. **Na lista suspensa, escolha Amazon. CodeCatalyst** 1. Pesquise a ação **Renderizar definição de tarefa do Amazon ECS** e faça o seguinte: + Selecione o sinal de adição (**\$1**) para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. Ou + Selecione a opção **Renderizar definição de tarefa do Amazon ECS**. A caixa de diálogo de detalhes da ação é exibida. Nessa caixa de diálogo: + (Opcional) Selecione **Visualizar origem** para [visualizar o código-fonte da ação](workflows-view-source.md#workflows-view-source.title). + Selecione **Adicionar ao fluxo de trabalho** para adicionar a ação ao diagrama do fluxo de trabalho e abrir seu painel de configuração. 1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [Ação YAML “Renderizar definição de tarefa do Amazon ECS”](render-ecs-action-ref.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ **Próximas etapas** Depois de adicionar a ação de renderização, adicione a ação **Implantar no Amazon ECS** ao seu fluxo de trabalho seguindo as instruções em [Implantação no Amazon ECS com um fluxo de trabalho](deploy-action-ecs.md). Ao adicionar a ação de implantação, faça o seguinte: 1. Na guia **Entradas** da ação de implantação, em **Artefatos - opcional**, selecione o artefato que foi gerado pela ação de renderização. Ele contém o arquivo de definição de tarefa atualizado. Para obter mais informações sobre artefatos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). 1. Na guia **Configuração** da ação de implantação, no campo **Definição da tarefa**, especifique a seguinte variável de ação: `${action-name.task-definition}` onde *action-name* está o nome da sua ação de renderização, por exemplo,`RenderTaskDef`. A ação de renderização define essa variável com o novo nome do arquivo de definição da tarefa. Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Para ter mais informações sobre como configurar a ação de implantação, consulte o [exemplo de fluxo de trabalho](render-ecs-action-example-workflow.md) anterior. # Visualização do arquivo de definição de tarefa atualizado Você pode visualizar o nome e o conteúdo do arquivo de definição de tarefa atualizado. **Para visualizar o nome do arquivo de definição de tarefa atualizado, depois que a ação **Renderizar definição de tarefa do Amazon ECS** o tiver processado.** 1. Encontre a execução que inclui uma ação de renderização concluída: 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha uma execução que inclua a ação de renderização concluída. 1. No diagrama do fluxo de trabalho, selecione a ação de renderização. 1. Selecione **Saídas**. 1. Selecione **Variáveis**. 1. O nome do arquivo de definição de tarefa é exibido. Ele é semelhante a `task-definition--259-0a2r7gxlTF5X-.json`. **Para visualizar o conteúdo do arquivo de definição de tarefa atualizado** 1. Encontre a execução que inclui uma ação de renderização concluída: 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha uma execução que inclua a ação de renderização concluída. 1. Na execução do fluxo de trabalho, na parte superior, ao lado de **Visual** e **YAML**, selecione **Saídas do fluxo de trabalho**. 1. Na seção **Artefatos**, selecione **Baixar** ao lado do artefato que contém o arquivo de definição de tarefa atualizado. Esse artefato terá uma coluna **Produzido por** definida com o nome da sua ação de renderização. 1. Abra o arquivo .zip para visualizar o arquivo .json de definição de tarefa. # Variáveis de “Renderizar definição de tarefa do Amazon ECS” A ação **Renderizar definição de tarefa do Amazon ECS** produz e define as seguintes variáveis em runtime. Elas são conhecidas como *variáveis predefinidas*. Para ter informações sobre como referenciar essas variáveis em um fluxo de trabalho, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). | Chave | Valor | | --- | --- | | task-definition | O nome dado ao arquivo de definição de tarefa que foi atualizado pela ação **Renderizar definição de tarefa do Amazon ECS**. O nome segue o formato `task-definition-random-string.json`. Exemplo: `task-definition--259-0a2r7gxlTF5Xr.json` | # Ação YAML “Renderizar definição de tarefa do Amazon ECS” Veja a seguir a definição YAML da ação **Renderizar definição de tarefa do Amazon ECS**. Para saber como usar essa ação, consulte [Modificação de uma definição de tarefa do Amazon ECS](render-ecs-action.md). Essa definição de ação existe como uma seção dentro de um arquivo de definição de fluxo de trabalho mais amplo. Para obter mais informações sobre esse arquivo, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. ``` # The workflow definition starts here. # See Propriedades de nível superior for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. ECSRenderTaskDefinition\$1nn: Identifier: aws/ecs-render-task-definition@v1 DependsOn: - build-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - task-definition-artifact Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Configuration task-definition: task-definition-path container-definition-name: container-definition-name image: docker-image-name environment-variables: - variable-name-1=variable-value-1 - variable-name-2=variable-value-2 Outputs: Artifacts: - Name: TaskDefArtifact Files: "task-definition*" Variables: - task-definition ``` ## ECSRenderTaskDefinition (Obrigatório) Especifique o nome da ação. Todos os nomes de ação devem ser exclusivos no fluxo de trabalho. Os nomes de ação são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de ação. Padrão: `ECSRenderTaskDefinition_nn`. Interface de usuário correspondente: guia Configuração/**Nome da ação** ## Identifier (*ECSRenderTaskDefinition*/**Identifier**) (Obrigatório) Identifica a ação. Não altere essa propriedade, a menos que você queira alterar a versão. Para obter mais informações, consulte [Especificação da versão da ação a ser usada](workflows-action-versions.md). Padrão: `aws/ecs-render-task-definition@v1`. **UI correspondente: diagrama de fluxo de trabalho/ ECSRenderTaskDefinition \$1nn/ aws/ @v1 label ecs-render-task-definition** ## DependsOn (*ECSRenderTaskDefinition*/**DependsOn**) (Optional) Especifique uma ação, um grupo de ação ou um portão que deve ser executado com êxito para que essa ação seja executada. Para ter mais informações sobre a funcionalidade “Depende de”, consulte [Sequenciar ações](workflows-depends-on.md). Interface de usuário correspondente: guia Entradas/**Depende de - opcional** ## Compute (*ECSRenderTaskDefinition*/**Compute**) (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ## Type (*ECSRenderTaskDefinition*/Compute/**Type**) (Obrigatório se [Compute](#render.ecs.computename) for incluído) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2**(editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). Interface de usuário correspondente: guia Configuração/**Tipo de computação** ## Fleet (*ECSRenderTaskDefinition*/Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. Interface de usuário correspondente: guia Configuração/**Frota de computação** ## Timeout (*ECSRenderTaskDefinition*/**Timeout**) (Optional) Especifique a quantidade de tempo em minutos (editor YAML) ou horas e minutos (editor visual) que a ação pode ser executada antes de CodeCatalyst finalizar a ação. O mínimo é de cinco minutos e o máximo está descrito em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). O tempo limite padrão é igual ao tempo limite máximo. Interface de usuário correspondente: guia Configuração/**Tempo limite - opcional** ## Inputs (*ECSRenderTaskDefinition*/**Inputs**) (Optional) A seção `Inputs` define os dados que `ECSRenderTaskDefinition` precisa durante a execução de um fluxo de trabalho. **nota** Somente uma entrada (uma origem ou um artefato) é permitida por ação **Renderizar definição de tarefa do Amazon ECS**. As variáveis não são contadas nesse total. Interface de usuário correspondente: guia **Entradas** ## Sources (*ECSRenderTaskDefinition*/Inputs/**Sources**) (Obrigatório se o arquivo de definição de tarefas estiver armazenado em um repositório de origem) Se seu arquivo de definição de tarefa estiver armazenado em um repositório de origem, especifique o rótulo do repositório de origem. Atualmente, o único rótulo compatível é `WorkflowSource`. Se seu arquivo de definição de tarefa não estiver em um repositório de origem, ele deverá residir em um artefato gerado por outra ação. Para obter mais informações sobre fontes, consulte [Conectar repositórios de origem aos fluxos de trabalho](workflows-sources.md). Interface de usuário correspondente: guia Entradas/**Origens - opcional** ## Artifacts - input (*ECSRenderTaskDefinition*/Inputs/**Artifacts**) (Obrigatório se o arquivo de definição de tarefa estiver armazenado em um [artefato de saída](workflows-working-artifacts-output.md) de uma ação anterior) Se o arquivo de definição de tarefa que você deseja implantar estiver em um artefato gerado por uma ação anterior, especifique esse artefato aqui. Se seu arquivo de definição de tarefa não estiver em um artefato, ele deverá residir em seu repositório de origem. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Configuração/**Artefatos - opcional** ## Variables - input (*ECSRenderTaskDefinition*/Inputs/**Variables**) (Obrigatório) Especifique uma sequência de name/value pares que defina as variáveis de entrada que você deseja disponibilizar para a ação. Os nomes de variável são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de variável. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Interface de usuário correspondente: guia Entradas/**Variáveis - opcional** ## Configuration (*ECSRenderTaskDefinition*/**Configuration**) (Obrigatório) Uma seção na qual você pode definir as propriedades de configuração da ação. Interface de usuário correspondente: guia **Configuração** ## task-definition (*ECSRenderTaskDefinition*/Configuration/**task-definition**) (Obrigatório) Especifique o caminho para um arquivo de definição de tarefa existente. Se o arquivo residir em seu repositório de origem, o caminho é relativo à pasta raiz do repositório de origem. Se o arquivo residir em um artefato de uma ação anterior do fluxo de trabalho, o caminho é relativo à pasta raiz do artefato. Para ter mais informações sobre os arquivos de definição de tarefa, consulte [Definições de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Interface de usuário correspondente: guia Configuração/**Definição de tarefa** ## container-definition-name (*ECSRenderTaskDefinition*/Configuration/**container-definition-name**) (Obrigatório) Especifique o nome do contêiner em que sua imagem do Docker será executada. Você pode encontrar esse nome em `containerDefinitions`, campo `name` em seu arquivo de definição de tarefa. Para ter mais informações, consulte [Nome](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_name) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Interface de usuário correspondente: guia Configuração/**Nome do contêiner** ## image (*ECSRenderTaskDefinition*/Configuration/**image**) (Obrigatório) Especifique o nome da imagem do Docker que você deseja que a ação **Renderizar definição de tarefa do Amazon ECS** adicione ao seu arquivo de definição de tarefas. A ação adiciona esse nome a `containerDefinitions`, campo `image` em seu arquivo de definição de tarefa. Se um valor já existir no campo `image`, a ação o substituirá. Você pode incluir variáveis no nome da imagem. Exemplos: Se você especificar`MyDockerImage:${WorkflowSource.CommitId}`, a ação será adicionada `MyDockerImage:commit-id` ao arquivo de definição da tarefa, onde *commit-id* está uma ID de confirmação gerada em tempo de execução pelo fluxo de trabalho. Se você especificar`my-ecr-repo/image-repo:$(date +%m-%d-%y-%H-%m-%s)`, a ação adicionará *my-ecr-repo* /image-repo: *date \$1%m-%d-%y-%H-%m-%s* ao arquivo de definição da tarefa, onde *my-ecr-repo* é o URI de um Amazon Elastic Container Registry (ECR) e *date \$1%m-%d-%y-%H-%m-%s* é um timestamp no formato `month-day-year-hour-minute-second` gerado em tempo de execução pelo fluxo de trabalho. Para ter mais informações sobre o campo `image`, consulte [Imagem](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_image) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). Interface de usuário correspondente: guia Configuração/**Nome da imagem** ## environment-variables (*ECSRenderTaskDefinition*/Configuration/**environment-variables**) (Obrigatório) Especifique as variáveis de ambiente que você deseja que a ação **Renderizar definição de tarefa do Amazon ECS** adicione ao seu arquivo de definição de tarefa. A ação adiciona as variáveis a `containerDefinitions`, campo `environment` em seu arquivo de definição de tarefa. Se as variáveis já existirem no arquivo, a ação substituirá os valores das variáveis existentes e adicionará quaisquer novas variáveis. Para ter mais informações sobre as variáveis de ambiente do Amazon ECS, consulte [Especificar variáveis de ambiente](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Interface de usuário correspondente: guia Configuração/**Variáveis de ambiente – opcional** ## Outputs (*ECSRenderTaskDefinition*/**Outputs**) (Obrigatório) Define os dados que são gerados pela ação durante a execução de um fluxo de trabalho. Interface de usuário correspondente: guia **Saídas** ## Artifacts (*ECSRenderTaskDefinition*/Outputs/**Artifacts**) (Obrigatório) Especifique os artefatos gerados pela ação. Você pode referenciar esses artefatos como entrada em outras ações. Para ter mais informações sobre artefatos, inclusive exemplos, consulte [Compartilhar artefatos e arquivos entre ações](workflows-working-artifacts.md). Interface de usuário correspondente: guia Saídas/**Artefatos** ## Name (*ECSRenderTaskDefinition*/Outputs/Artifacts/**Name**) (Obrigatório) Especifique o nome do artefato que conterá o arquivo de definição de tarefa atualizado. O valor padrão é `MyTaskDefinitionArtifact`. Em seguida, você deve especificar esse artefato como entrada na ação **Implantar no Amazon ECS**. Para entender como adicionar esse artefato como entrada para a ação **Implantar no Amazon ECS**, consulte [Exemplo: modificar uma definição de tarefa do Amazon ECS](render-ecs-action-example-workflow.md). Interface de usuário correspondente: guia Saídas/Artefatos/**Nome** ## Files (*ECSRenderTaskDefinition*/Outputs/Artifacts/**Files**) (Obrigatório) Especifique os arquivos a serem incluídos no artefato. Você deve especificar `task-definition-*` para que o arquivo de definição de tarefa atualizado, que começa com `task-definition-`, seja incluído. Interface de usuário correspondente: guia Saídas/Artefatos/**Arquivos** ## Variables (*ECSRenderTaskDefinition*/Outputs/**Variables**) (Obrigatório) Especifique o nome de uma variável a ser definida pela ação de renderização. A ação de renderização definirá o valor dessa variável como o nome do arquivo de definição de tarefa atualizado (por exemplo, `task-definition-random-string.json`). Em seguida, você deve especificar essa variável na propriedade **Definição de tarefa** (editor visual) ou `task-definition` (editor yaml) da ação **Implantar no Amazon ECS**. Para entender como adicionar essa variável na ação **Implantar no Amazon ECS**, consulte [Exemplo: modificar uma definição de tarefa do Amazon ECS](render-ecs-action-example-workflow.md). Padrão: `task-definition` Interface de usuário correspondente: guia Saídas/Variáveis/**Nome** # Uso de variáveis em fluxos de trabalho Uma *variável* é um par de valores-chave que contém informações que você pode consultar em seu fluxo de trabalho da Amazon CodeCatalyst . A parte do valor da variável é substituída por um valor real quando o fluxo de trabalho é executado. Há dois tipos de variáveis que podem ser usadas no fluxo de trabalho: + **Variáveis definidas pelo usuário** – Pares chave-valor que você define. + **Variáveis predefinidas** – Pares de chave-valor que são emitidos automaticamente por um fluxo de trabalho. Você não precisa defini-las. Para obter mais informações sobre fluxos de trabalho, consulte [Compilação, teste e implantação com fluxos de trabalhoCompilação, teste e implantação com fluxos de trabalho](workflow.md). **nota** CodeCatalyst também suporta [parâmetros GitHub de saída](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter), que se comportam como variáveis e podem ser referenciados em outras ações. Para ter mais informações, consulte [Exportação dos parâmetros de saída do GitHub](integrations-github-action-export.md) e [Referenciando parâmetros GitHub de saída](integrations-github-action-referencing.md) **Topics** + [ # Usar variáveis definidas pelo usuário ](workflows-using-variables.md) + [ # Usar variáveis predefinidas ](workflows-using-predefined-variables.md) # Usar variáveis definidas pelo usuário *As variáveis definidas pelo usuário* são pares chave-valor que você define. Existem dois tipos: + **Variáveis de texto simples**, ou simplesmente **variáveis** – Pares de chave-valor que você define em texto simples no arquivo de definição do fluxo de trabalho. + **Segredos** — Esses são pares de valores-chave que você define em uma página separada de **segredos** do console da Amazon CodeCatalyst . A *chave* (nome) é um rótulo público e o *valor* contém as informações que você deseja manter privadas. Especifique apenas a chave no arquivo de definição do fluxo de trabalho. Use segredos no lugar de senhas e outras informações confidenciais no arquivo de definição do fluxo de trabalho. **nota** Resumindo, este guia usa o termo *variável* para *variável de texto simples*. Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **Topics** + [ # Exemplos de variáveis ](workflows-working-with-variables-ex.md) + [ # Definição de uma variável ](workflows-working-with-variables-define-input.md) + [ # Definição de um segredo ](workflows-working-with-variables-define-secret.md) + [ # Exportação de uma variável para que outras ações possam usá-la ](workflows-working-with-variables-export-input.md) + [ # Referência a uma variável na ação que a define ](workflows-working-with-variables-reference-input.md) + [ # Referência a uma saída de variável por outra ação ](workflows-working-with-variables-reference-action.md) + [ # Referência a um segredo ](workflows-working-with-variables-reference-secret.md) # Exemplos de variáveis Os exemplos a seguir mostram como definir e referenciar variáveis no arquivo de definição de fluxo de trabalho. Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **Topics** + [ ## Exemplo: definição de uma variável usando a propriedade de entradas ](#workflows-working-with-variables-ex-define-inputs) + [ ## Exemplo: definição de uma variável usando a propriedade de etapas ](#workflows-working-with-variables-ex-define-steps) + [ ## Exemplo: exportação de uma variável usando a propriedade de saídas ](#workflows-working-with-variables-ex-export-outputs) + [ ## Exemplo: referência de uma variável definida na mesma ação ](#workflows-working-with-variables-ex-refer-current) + [ ## Exemplo: referência de uma variável definida em outra ação ](#workflows-working-with-variables-ex-refer-other) + [ ## Exemplo: referenciar um segredo ](#workflows-working-with-variables-ex-refer-secret) ## Exemplo: definição de uma variável usando a propriedade de entradas O exemplo a seguir mostra como definir duas variáveis, `VAR1` e `VAR2`, em uma seção `Inputs`. ``` Actions: Build: Identifier: aws/build@v1 Inputs: Variables: - Name: VAR1 Value: "My variable 1" - Name: VAR2 Value: "My variable 2" ``` ## Exemplo: definição de uma variável usando a propriedade de etapas O exemplo a seguir mostra como definir explicitamente uma variável `DATE` na seção `Steps`. ``` Actions: Build: Identifier: aws/build@v1 Configuration: Steps: - Run: DATE=$(date +%m-%d-%y) ``` ## Exemplo: exportação de uma variável usando a propriedade de saídas O exemplo a seguir mostra como definir duas variáveis, `REPOSITORY-URI` e `TIMESTAMP`, e exportá-las usando a seção `Outputs`. ``` Actions: Build: Identifier: aws/build@v1 Inputs: Variables: - Name: REPOSITORY-URI Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo Configuration: Steps: - Run: TIMESTAMP=$(date +%m-%d-%y-%H-%m-%s) Outputs: Variables: - REPOSITORY-URI - TIMESTAMP ``` ## Exemplo: referência de uma variável definida na mesma ação O exemplo a seguir mostra como especificar uma variável `VAR1` em `MyBuildAction` e, depois, referenciá-la na mesma ação usando `$VAR1`. ``` Actions: MyBuildAction: Identifier: aws/build@v1 Inputs: Variables: - Name: VAR1 Value: my-value Configuration: Steps: - Run: $VAR1 ``` ## Exemplo: referência de uma variável definida em outra ação O exemplo a seguir mostra como especificar uma variável `TIMESTAMP` em `BuildActionA`, exportá-la usando a propriedade `Outputs` e, depois, referenciá-la em `BuildActionB` usando `${BuildActionA.TIMESTAMP}`. ``` Actions: BuildActionA: Identifier: aws/build@v1 Configuration: Steps: - Run: TIMESTAMP=$(date +%m-%d-%y-%H-%m-%s) Outputs: Variables: - TIMESTAMP BuildActionB: Identifier: aws/build@v1 Configuration: Steps: - Run: docker build -t my-ecr-repo/image-repo:latest . - Run: docker tag my-ecr-repo/image-repo:${BuildActionA.TIMESTAMP} # Specifying just '$TIMESTAMP' here will not work # because TIMESTAMP is not a variable # in the BuildActionB action. ``` ## Exemplo: referenciar um segredo Os exemplos a seguir mostram como referenciar um segredo de `my-password`. `my-password` é a chave do segredo. A chave secreta e o valor da senha correspondente devem ser especificados na página **Segredos** do CodeCatalyst console antes de serem usados no arquivo de definição do fluxo de trabalho. Para obter mais informações, consulte [Mascarar dados usando segredos](workflows-secrets.md). ``` Actions: BuildActionA: Identifier: aws/build@v1 Configuration: Steps: - Run: curl -u LiJuan:${Secrets.my-password} https://example.com ``` # Definição de uma variável É possível definir variáveis de duas maneiras: + Na seção `Inputs` de uma ação de fluxo de trabalho. Consulte [Para definir uma variável na seção “Entradas”](#workflows-to-define-variable-input) + Na seção `Steps` de uma ação de fluxo de trabalho. Consulte [Para definir uma variável na seção “Etapas”](#workflows-to-define-variable-steps) **nota** O `Steps` método só funciona com as ações de CodeCatalyst compilação, teste e **GitHub ações**, porque essas são as únicas ações que incluem uma `Steps` seção. Para obter exemplos, consulte [Exemplos de variáveis](workflows-working-with-variables-ex.md). Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). ------ #### [ Visual ] **Para definir uma variável na seção “Entradas” (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação onde deseja configurar a variável. 1. Selecione **Entradas**. 1. Em **Variáveis – opcional**, selecione **Adicionar variável** e, depois, faça o seguinte: Especifique uma sequência de name/value pares que defina as variáveis de entrada que você deseja disponibilizar para a ação. Os nomes de variável são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Não é possível usar aspas para habilitar caracteres especiais e espaços nos nomes de variável. Para ter mais informações sobre variáveis, inclusive exemplos, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para definir uma variável na seção “Entradas” (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma ação de fluxo de trabalho, adicione um código semelhante ao seguinte: ``` action-name: Inputs: Variables: - Name: variable-name Value: variable-value ``` Para obter mais exemplos, consulte [Exemplos de variáveis](workflows-working-with-variables-ex.md). Para ter mais informações, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md) para sua ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ ------ #### [ Visual ] **Para definir uma variável na seção “Etapas” (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama do fluxo de trabalho, selecione a ação onde deseja configurar a variável. 1. Escolher **configuração**. 1. Nos **comandos do Shell** ou no **GitHubActions YAML**, o que estiver disponível, defina uma variável na ação`Steps`, explícita ou implicitamente. + Para definir a variável explicitamente, inclua-a em um comando bash diretamente na seção `Steps`. + Para definir uma variável implicitamente, especifique-a em um arquivo referenciado na seção `Steps` da ação. Para obter exemplos, consulte [Exemplos de variáveis](workflows-working-with-variables-ex.md). Para ter mais informações, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md) para a ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para definir uma variável na seção “Etapas” (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma ação de fluxo de trabalho, defina uma variável na seção `Steps` da ação, explícita ou implicitamente. + Para definir a variável explicitamente, inclua-a em um comando bash diretamente na seção `Steps`. + Para definir uma variável implicitamente, especifique-a em um arquivo referenciado na seção `Steps` da ação. Para obter exemplos, consulte [Exemplos de variáveis](workflows-working-with-variables-ex.md). Para ter mais informações, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md) para a ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Definição de um segredo Você define um segredo na página **Segredos** do CodeCatalyst console. Para obter mais informações, consulte [Mascarar dados usando segredos](workflows-secrets.md). Por exemplo, você pode definir um segredo parecido com este: + Nome (chave): **my-password** + Valor: **^\$1H3\$1\$1b9** Depois que o segredo for definido, você poderá especificar a chave do segredo (**my-password**) no arquivo de definição do fluxo de trabalho. Para obter um exemplo de como fazer isso, consulte [Exemplo: referenciar um segredo](workflows-working-with-variables-ex.md#workflows-working-with-variables-ex-refer-secret). # Exportação de uma variável para que outras ações possam usá-la Use as instruções a seguir para exportar uma variável de uma ação para que você possa referenciá-la em outras ações. Antes de exportar uma variável, verifique o seguinte: + Se você só precisar referenciar a variável dentro da ação em que ela está definida, não será necessário exportá-la. + Nem todas as ações são compatíveis com a exportação de variáveis. Para determinar se a ação é compatível com esse recurso, siga as instruções do editor visual a seguir e veja se a ação inclui um botão **Variáveis** na guia **Saídas**. Se sim, a exportação de variáveis é compatível. + Para exportar uma variável de uma GitHub Ação, consulte[Exportação dos parâmetros de saída do GitHub](integrations-github-action-export.md). Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **Pré-requisito** Certifique-se de ter definido a variável que você deseja exportar. Para obter mais informações, consulte [Definição de uma variável](workflows-working-with-variables-define-input.md). ------ #### [ Visual ] **Para exportar uma variável (editor visual)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **Visual**. 1. No diagrama de fluxo de trabalho, selecione a ação da qual deseja exportar a variável. 1. Selecione **Saídas**. 1. Em **Variáveis – opcional**, selecione **Adicionar variável** e, depois, faça o seguinte: Especifique o nome de uma variável a ser exportada pela ação. Essa variável já deve estar definida na seção `Inputs` ou `Steps` da mesma ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ #### [ YAML ] **Para exportar uma variável (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Na ação da qual você deseja exportar a variável, adicione um código semelhante ao seguinte: ``` action-name: Outputs: Variables: - Name: variable-name ``` Para obter mais exemplos, consulte [Exemplos de variáveis](workflows-working-with-variables-ex.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Referência a uma variável na ação que a define Use as instruções a seguir para referenciar uma variável na ação que a define. **nota** Para referenciar uma variável gerada por uma GitHub Ação, consulte[Referenciando parâmetros GitHub de saída](integrations-github-action-referencing.md). Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **Pré-requisito** Certifique-se de ter definido a variável que você deseja referenciar. Para obter mais informações, consulte [Definição de uma variável](workflows-working-with-variables-define-input.md). ------ #### [ Visual ] *Não disponível. Escolha YAML para visualizar as instruções YAML.* ------ #### [ YAML ] **Para referenciar uma variável na ação que a define** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Na CodeCatalyst ação que define a variável à qual você deseja se referir, adicione a variável usando a seguinte sintaxe bash: ``` $variable-name ``` Por exemplo: ``` MyAction: Configuration: Steps: - Run: $variable-name ``` Para obter mais exemplos, consulte [Exemplos de variáveis](workflows-working-with-variables-ex.md). Para ter mais informações, consulte as informações de referência da ação em [Definição do YAML do fluxo de trabalho](workflow-reference.md). 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Referência a uma saída de variável por outra ação Use as instruções a seguir para referenciar saídas de variáveis por outras ações. **nota** Para referenciar uma saída variável de uma GitHub Ação, consulte[Referenciando parâmetros GitHub de saída](integrations-github-action-referencing.md). Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **Pré-requisito** Certifique-se de ter exportado a variável que você deseja referenciar. Para obter mais informações, consulte [Exportação de uma variável para que outras ações possam usá-la](workflows-working-with-variables-export-input.md). ------ #### [ Visual ] *Não disponível. Escolha YAML para visualizar as instruções YAML.* ------ #### [ YAML ] **Para referenciar uma saída de variável por outra ação (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Na CodeCatalyst ação, adicione uma referência à variável usando a seguinte sintaxe: ``` ${action-group-name.action-name.variable-name} ``` Substitua: + *action-group-name*com o nome do grupo de ações que contém a ação que gera a variável. **nota** Você pode omitir *action-group-name* se não houver um grupo de ações ou se a variável for produzida por uma ação no mesmo grupo de ações. + *action-name*com o nome da ação que gera a variável. + *variable-name*com o nome da variável. Por exemplo: ``` MySecondAction: Configuration: Steps: - Run: ${MyFirstAction.TIMESTAMP} ``` Para obter mais exemplos, consulte [Exemplos de variáveis](workflows-working-with-variables-ex.md). Para ter mais informações, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md) para sua ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Referência a um segredo Para receber instruções sobre como fazer referência a um segredo no arquivo de definição do fluxo de trabalho, consulte [Usar um segredo](workflows-secrets.using.md). Para ver um exemplo, consulte [Exemplo: referenciar um segredo](workflows-working-with-variables-ex.md#workflows-working-with-variables-ex-refer-secret). # Usar variáveis predefinidas *Variáveis predefinidas* são pares de chave-valor emitidos automaticamente por um fluxo de trabalho e disponibilizados para você usar em ações de fluxo de trabalho. Para ter mais informações sobre variáveis, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md). **Topics** + [ # Exemplos de referência de variáveis predefinidas ](workflows-predefined-examples.md) + [ # Referência a uma variável predefinida ](workflows-working-with-variables-reference-output-vars.md) + [ # Determinação de quais variáveis predefinidas seu fluxo de trabalho emite ](workflows-working-with-variables-determine-output-vars.md) + [ # Lista de variáveis predefinidas ](workflow-ref-action-variables.md) # Exemplos de referência de variáveis predefinidas Os exemplos a seguir mostram como fazer referência a variáveis predefinidas no arquivo de definição de fluxo de trabalho. Para ter mais informações sobre variáveis predefinidas, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). **Topics** + [ ## Exemplo: referenciando a variável predefinida CommitId "” ](#workflows-working-with-variables-ex-refer-action) + [ ## Exemplo: referenciando a variável predefinida BranchName "” ](#workflows-working-with-variables-ex-branch) ## Exemplo: referenciando a variável predefinida CommitId "” O exemplo a seguir mostra como fazer referência à variável predefinida `CommitId` na ação `MyBuildAction`. A `CommitId` variável é gerada automaticamente por CodeCatalyst. Para obter mais informações, consulte [Lista de variáveis predefinidas](workflow-ref-action-variables.md). Embora o exemplo mostre a variável que está sendo usada na ação de criação, você pode usar `CommitId` em qualquer ação. ``` MyBuildAction: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: #Build Docker image and tag it with a commit ID - Run: docker build -t image-repo/my-docker-image:latest . - Run: docker tag image-repo/my-docker-image:${WorkflowSource.CommitId} ``` ## Exemplo: referenciando a variável predefinida BranchName "” O exemplo a seguir mostra como fazer referência à variável predefinida `BranchName` na ação `CDKDeploy`. A `BranchName` variável é gerada automaticamente por CodeCatalyst. Para obter mais informações, consulte [Lista de variáveis predefinidas](workflow-ref-action-variables.md). Embora o exemplo mostre a variável que está sendo usada na ação **implantar AWS CDK **, você pode usar `BranchName` em qualquer ação. ``` CDKDeploy: Identifier: aws/cdk-deploy@v2 Inputs: Sources: - WorkflowSource Configuration: StackName: app-stack-${WorkflowSource.BranchName} ``` # Referência a uma variável predefinida Você pode referenciar variáveis predefinidas em qualquer ação dentro de um CodeCatalyst fluxo de trabalho da Amazon. Use as instruções a seguir para referenciar uma variável predefinida em um fluxo de trabalho. Para ter mais informações sobre variáveis predefinidas, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). **Pré-requisito** Determine o nome da variável predefinida que você deseja referenciar, como `CommitId`. Para obter mais informações, consulte [Determinação de quais variáveis predefinidas seu fluxo de trabalho emite](workflows-working-with-variables-determine-output-vars.md). ------ #### [ Visual ] *Não disponível. Escolha YAML para visualizar as instruções YAML.* ------ #### [ YAML ] **Como fazer referência a uma variável predefinida (editor YAML)** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Em uma CodeCatalyst ação, adicione a referência de variável predefinida usando a seguinte sintaxe: ``` ${action-group-name.action-name-or-WorkflowSource.variable-name} ``` Substitua: + *action-group-name*com o nome do grupo de ação. **nota** Você pode omitir *action-group-name* se não houver um grupo de ações ou se a variável for produzida por uma ação no mesmo grupo de ações. + *action-name-or-WorkflowSource*com: O nome da ação que gera a variável. or `WorkflowSource`, se a variável for `BranchName` ou `CommitId`. + *variable-name*com o nome da variável. Por exemplo: ``` MySecondAction: Configuration: Steps: - Run: echo ${MyFirstECSAction.cluster} ``` Outro exemplo: ``` MySecondAction: Configuration: Steps: - Run: echo ${WorkflowSource.CommitId} ``` Para obter mais exemplos, consulte [Exemplos de referência de variáveis predefinidas](workflows-predefined-examples.md). Para ter mais informações, consulte [Definição do YAML do fluxo de trabalho](workflow-reference.md) para sua ação. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. ------ # Determinação de quais variáveis predefinidas seu fluxo de trabalho emite Use o seguinte procedimento para determinar quais variáveis predefinidas um fluxo de trabalho emite quando executado. Em seguida, você pode referenciar essas variáveis no mesmo fluxo de trabalho. Para ter mais informações sobre variáveis predefinidas, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). **Como determinar as variáveis predefinidas que seu fluxo de trabalho emite** + Execute um destes procedimentos: + **Execute o fluxo de trabalho uma vez**. Após a conclusão da execução, as variáveis emitidas pelo fluxo de trabalho são exibidas na guia **Variáveis** da página de detalhes da execução. Para obter mais informações, consulte [Visualização do status e detalhes de execução do fluxo de trabalho](workflows-view-run.md). + **Consulte [Lista de variáveis predefinidas](workflow-ref-action-variables.md)**. Essa referência lista o nome da variável (chave) e o valor de cada variável predefinida. **nota** O tamanho total máximo das variáveis de um fluxo de trabalho está listado em [Cotas para fluxos de trabalho em CodeCatalyst](workflows-quotas.md). Se o tamanho total exceder o máximo, a ação seguinte poderá falhar. # Lista de variáveis predefinidas Consulte as seções a seguir para visualizar as variáveis predefinidas produzidas automaticamente pelas ações do CodeCatalyst como parte da execução de um fluxo de trabalho. Para ter mais informações sobre variáveis predefinidas, consulte [Usar variáveis predefinidas](workflows-using-predefined-variables.md). **nota** Essa lista inclui somente variáveis predefinidas emitidas pela origem do CodeCatalyst e pelas [ações do CodeCatalyst](workflows-actions.md#workflows-actions-types). Se você estiver usando outros tipos de ações, como ações do GitHub ou do CodeCatalyst Labs, consulte [Determinação de quais variáveis predefinidas seu fluxo de trabalho emite](workflows-working-with-variables-determine-output-vars.md). **Lista** **nota** Nem todas as ações do CodeCatalyst produzem variáveis predefinidas. Se a ação não estiver na lista, ela não produzirá variáveis. + [variáveis BranchName '' e CommitId ''](workflows-sources-variables.md) + [Variáveis de “ CloudFormation pilha de implantação”](deploy-action-cfn-variables.md) + [Variáveis de “Implantar no Amazon ECS”](deploy-action-ecs-variables.md) + [Variáveis de “Implantar no cluster do Kubernetes”](deploy-action-eks-variables.md) + [Variáveis de “Implantação do AWS CDK ”](cdk-dep-action-variables.md) + [variáveis de “Inicialização do AWS CDK ”](cdk-boot-action-variables.md) + [Variáveis de “Invocação do AWS Lambda ”](lam-invoke-action-variables.md) + [Variáveis de “Renderizar definição de tarefa do Amazon ECS”](render-ecs-action-variables.md) # Mascarar dados usando segredos Pode haver momentos em que você precise usar dados confidenciais, como credenciais de autenticação, em seus fluxos de trabalho. Armazenar esses valores em texto simples em qualquer lugar do seu repositório deve ser evitado, pois qualquer pessoa com acesso ao repositório que contém o segredo pode vê-los. Da mesma forma, esses valores não devem ser usados diretamente em nenhuma definição de fluxo de trabalho porque estarão visíveis como arquivos no seu repositório. Com CodeCatalyst, você pode proteger esses valores adicionando um segredo ao seu projeto e, em seguida, referenciando o segredo no seu arquivo de definição de fluxo de trabalho. Observe que você pode ter, no máximo, cinco segredos por ação. **nota** Os segredos só podem ser usados para substituir senhas e informações confidenciais no arquivo de definição do fluxo de trabalho. **Topics** + [ # Criar um segredo ](workflows-secrets.creating.md) + [ # Editar um segredo ](workflows-secrets.editing.md) + [ # Usar um segredo ](workflows-secrets.using.md) + [ # Excluir um segredo ](workflows-secrets.deleting.md) # Criar um segredo Use o procedimento a seguir para criar um segredo. O segredo contém as informações confidenciais que você deseja ocultar da visualização. **nota** Os segredos são visíveis para ações e não são mascarados quando gravados em um arquivo. **Como criar um segredo** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Segredos**. 1. Escolha **Criar segredo**. 1. Insira as seguintes informações: **Nome** Insira um nome para o segredo. **Valor** Insira o valor do segredo. Essas são as informações confidenciais que você deseja ocultar da visualização. Por padrão, o valor não é exibido. Para exibir o valor, selecione **Mostrar valor**. **Descrição** (Opcional) Insira uma descrição para o seu segredo. 1. Escolha **Criar**. # Editar um segredo Utilize o seguinte procedimento para editar um segredo. **Como editar um segredo** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Segredos**. 1. Na lista de segredos, selecione o segredo que você quer editar. 1. Escolha **Editar**. 1. Edite as seguintes propriedades: **Valor** Insira o valor do segredo. Esse é o valor que você deseja ocultar da visualização. Por padrão, o valor não é exibido. **Descrição** (Opcional) Insira uma descrição para o seu segredo. 1. Escolha **Salvar**. # Usar um segredo Para usar um segredo em uma ação de fluxo de trabalho, obtenha o identificador de referência do segredo e use-o na ação do fluxo de trabalho. **Topics** + [ ## Receber o identificador de um segredo ](#workflows-using-secrets.get-identifier) + [ ## Fazer referência a um segredo em um fluxo de trabalho ](#workflows-using-secrets.using-identifier) ## Receber o identificador de um segredo Use o procedimento a seguir para obter o identificador de referência do segredo. Esse identificador será adicionado ao seu fluxo de trabalho. **Como receber o identificador de referência do segredo** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Segredos**. 1. Na lista de segredos, selecione o segredo que você deseja usar. 1. Na coluna **ID de referência**, copie o identificador do segredo. Veja a seguir a sintaxe do **ID de referência**: ``` ${Secrets.} ``` ## Fazer referência a um segredo em um fluxo de trabalho Use o procedimento a seguir para fazer referência a um segredo em um fluxo de trabalho. **Como fazer referência a um segredo** 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Modifique o YAML para usar o identificador do segredo. Por exemplo, para usar um nome de usuário e uma senha armazenados como segredos com o comando `curl`, use um comando `Run` semelhante ao seguinte: ``` - Run: curl -u : https://example.com ``` 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. # Excluir um segredo Use o procedimento a seguir para excluir um segredo e o identificador de referência do segredo. **nota** Antes de excluir um segredo, recomendamos que você remova o identificador de referência do segredo de todas as ações do fluxo de trabalho. Se você excluir o segredo sem excluir o identificador de referência, a ação falhará na próxima vez em que for executada. **Como excluir o identificador de referência de um segredo de um fluxo de trabalho** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. 1. Escolha **Editar**. 1. Selecione **YAML**. 1. Pesquise no fluxo de trabalho a seguinte string: ``` ${Secrets. ``` Todos os identificadores de referência de todos os segredos serão encontrados. 1. Exclua o identificador de referência do segredo selecionado ou substitua-o por um valor de texto simples. 1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar. 1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente. **Para excluir um segredo** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. No painel de navegação, escolha **CI/CD** e **Segredos**. 1. Na lista de segredos, selecione o segredo que você quer excluir. 1. Escolha **Excluir**. 1. Insira **delete** para confirmar a exclusão. 1. Escolha **Excluir**. # Visualização do status de um fluxo de trabalho Talvez você queira ver o status de um fluxo de trabalho para ver se há algum problema de configuração do fluxo de trabalho que você precise resolver ou para solucionar problemas de execuções que não iniciam. CodeCatalystavalia o status do fluxo de trabalho sempre que você cria ou atualiza o [arquivo de definição de fluxo de trabalho subjacente do fluxo de trabalho](workflows-concepts.md#workflows-concepts-workflows-def). **nota** Você também pode visualizar o status de *execução* do fluxo de trabalho, que é diferente do status do fluxo de trabalho. Para obter mais informações, consulte [Visualização do status e detalhes de execução do fluxo de trabalho](workflows-view-run.md). Para ver uma lista de possíveis estados de fluxo de trabalho, consulte [Estados do fluxo de trabalho em CodeCatalyst](workflows-workflow-status.md). **Como visualizar o status de um fluxo de trabalho** 1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Selecione o projeto. 1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**. 1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho. O status é exibido com o fluxo de trabalho na lista. 1. (Opcional) Selecione o nome do fluxo de trabalho e encontre o campo **Definição do fluxo de trabalho**. Ele mostra o status do fluxo de trabalho. # Cotas para fluxos de trabalho em CodeCatalyst A tabela a seguir descreve cotas e limites para fluxos de trabalho na Amazon. CodeCatalyst Para obter mais informações sobre cotas na Amazon CodeCatalyst, consulte[Cotas para o CodeCatalyst](quotas.md). | | | | --- |--- | | Número máximo de fluxos de trabalho por espaço | 800 | | Tamanho máximo do arquivo de definição do fluxo de trabalho | 256 KB | | Número máximo de arquivos de fluxo de trabalho processados em um único evento de origem | 50 | | Número máximo de arquivos processados em um único evento de origem | 4.000 | | Número máximo de frotas ativas por espaço | 10 | | Número máximo de instâncias de computação ativas por frota | 20 | | Número máximo de artefatos de entrada por ação | 10 | | Número máximo de artefatos de saída por ação | 10 | | Tamanho total máximo das variáveis de saída de uma única ação | 120 KB | | Comprimento máximo do valor de uma variável de saída | 500 caracteres ou mais, dependendo da ação que emite o valor. Os valores podem ser truncados se excederem o limite da ação. | | Número máximo de dias para manter os artefatos gerados durante a execução de fluxo de trabalho | 30 | | Número máximo de relatórios por ação | 50 | | Número máximo de casos de teste por relatório de teste | 20.000 | | Número máximo de arquivos por relatório de cobertura de código | 20.000 | | Número máximo de descobertas da análise de composição de software por relatório | 20.000 | | Número máximo de arquivos por relatório de análise estática | 20.000 | | Número máximo de execuções simultâneas de fluxo de trabalho por espaço | 100 | | Número máximo de ações por fluxo de trabalho | 50 | | Número máximo de ações em execução simultânea por fluxo de trabalho | 50 | | Número máximo de ações em execução simultânea por espaço | 200 | | Quantidade máxima de tempo que uma ação pode ser executada | Para as ações de criação e teste, o tempo limite é de 8 horas. Para todas as outras ações, o tempo limite é de 1 hora. | | Número máximo de ambientes associados a uma Conta da AWS por espaço | 5.000 | | Número máximo de segredos por ação | 5 | | Número máximo de segredos por espaço | 500.000 | # Estados de execução do fluxo de trabalho Uma execução de fluxo de trabalho pode estar em um dos seguintes estados: + **Bem-sucedido** – A execução do fluxo de trabalho foi processada com êxito. + **Com falha** – Uma ou mais ações na execução do fluxo de trabalho falharam. + **Em andamento** – A execução do fluxo de trabalho está sendo processada. + **Parado** – Uma pessoa parou a execução do fluxo de trabalho enquanto ele estava em andamento. + **Parando** – A execução do fluxo de trabalho está sendo interrompida no momento. + **Cancelado** — A execução do fluxo de trabalho foi cancelada CodeCatalyst porque o fluxo de trabalho associado foi excluído ou atualizado enquanto a execução estava em andamento. + **Substituído** – Ocorre somente se você tiver configurado o [modo de execução de substituição](workflows-configure-runs.md#workflows-configure-runs-superseded). A execução do fluxo de trabalho foi cancelada CodeCatalyst porque uma execução posterior do fluxo de trabalho a substituiu. # Estados do fluxo de trabalho em CodeCatalyst Um fluxo de trabalho pode ter um dos seguintes estados: + **Válido** – O fluxo de trabalho é executável e pode ser ativado por [gatilhos](workflows-add-trigger.md#workflows-add-trigger.title). Para que um fluxo de trabalho seja marcado como válido, ambas as seguintes condições devem ser verdadeiras: + O arquivo de definição do fluxo de trabalho do deve ser válido. + O fluxo de trabalho não deve ter gatilhos, gatilhos de envio ou gatilho de extração executados usando os arquivos na ramificação atual. Para obter mais informações, consulte [Diretrizes para o uso de gatilhos e ramificações](workflows-add-trigger-considerations.md). + **Inválido** – O arquivo de definição do fluxo de trabalho é inválido. O fluxo de trabalho não pode ser executado manual ou automaticamente por meio de gatilhos. Os fluxos de trabalho que não são válidos aparecem com uma **definição de fluxo de trabalho com mensagem de *n* erros** (ou similar) no CodeCatalyst console. Para que um fluxo de trabalho seja marcado como inválido, as seguintes condições devem ser verdadeiras: + O arquivo de definição do fluxo de trabalho deve estar configurado incorretamente. Para corrigir um arquivo de definição de fluxo de trabalho configurado incorretamente, consulte [Como faço para corrigir os erros “A definição do fluxo de trabalho tem *n* erros”?](troubleshooting-workflows.md#troubleshooting-workflows-asterisks). + **Inativo** – A definição do fluxo de trabalho é válida, mas não pode ser executada manual ou automaticamente por meio de gatilhos. Para que um fluxo de trabalho seja marcado como inativo, ambas as seguintes condições devem ser verdadeiras: + O arquivo de definição do fluxo de trabalho do deve ser válido. + O arquivo de definição do fluxo de trabalho deve incluir um gatilho de envio que especifique uma ramificação diferente daquela em que o arquivo de definição do fluxo de trabalho está atualmente. Para obter mais informações, consulte [Diretrizes para o uso de gatilhos e ramificações](workflows-add-trigger-considerations.md). Para mudar um fluxo de trabalho de **Inativo** para **Ativo**, consulte [Como faço para corrigir as mensagens “O fluxo de trabalho está inativo”?](troubleshooting-workflows.md#troubleshooting-workflows-inactive). **nota** Se houver muitos fluxos de trabalho no estado **Inativo**, filtre-os para a visualização. Para filtrar fluxos de trabalho inativos, selecione o campo **Filtrar fluxos de trabalho** na parte superior da página **Fluxos de trabalho**, selecione **Status**, **Status \$1= Não igual** e selecione **INATIVO**. **nota** Se o fluxo de trabalho especificar um recurso que você removerá posteriormente (por exemplo, um repositório de pacotes), CodeCatalyst não detectará essa alteração e continuará marcando o fluxo de trabalho como válido. Esses tipos de problemas serão detectados quando o fluxo de trabalho for executado. # Definição do YAML do fluxo de trabalho Veja a seguir a documentação de referência do arquivo de definição do fluxo de trabalho. *Arquivo de definição de fluxo de trabalho* é um arquivo YAML que descreve o fluxo de trabalho. Por padrão, o arquivo é armazenado em uma pasta `~/.codecatalyst/workflows/` na raiz do [repositório de origem](source-repositories.md). O arquivo pode ter uma extensão .yml ou .yaml, e a extensão deve estar em minúsculas. Para criar e editar o arquivo de definição do fluxo de trabalho, você pode usar um editor como o vim ou usar o editor visual ou o editor YAML do CodeCatalyst console. Para obter mais informações, consulte [Usando os editores visual e YAML do CodeCatalyst console](workflow.md#workflow.editors). **nota** A maioria das propriedades YAML a seguir tem elementos de interface de usuário correspondentes no editor visual. Para pesquisar um elemento de interface, use **Ctrl\$1F**. O elemento será listado com a propriedade YAML associada. **Topics** + [ ## Exemplo de um arquivo de definição de fluxo de trabalho ](#workflow.anatomy) + [ ## Diretrizes e convenções de sintaxe ](#workflow.terms.syntax.conv) + [ ## Propriedades de nível superior ](#workflow.top.level) ## Exemplo de um arquivo de definição de fluxo de trabalho Veja a seguir um exemplo de um arquivo de definição de fluxo de trabalho simples. Inclui algumas propriedades de nível superior, uma seção `Triggers` e uma seção `Actions` com duas ações: `Build` e `Test`. Para obter mais informações, consulte [Sobre o arquivo de definição do fluxo de trabalho](workflow.md#workflow.example). ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: docker build -t MyApp:latest . Test: Identifier: aws/managed-test@v1 DependsOn: - Build Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: npm install - Run: npm run test ``` ## Diretrizes e convenções de sintaxe Esta seção descreve as regras de sintaxe para o arquivo de definição do fluxo de trabalho, bem como as convenções de nomenclatura usadas nesta documentação de referência. ### Diretrizes de sintaxe do YAML O arquivo de definição do fluxo de trabalho é escrito em YAML e segue a [especificação YAML 1.1](https://yaml.org/spec/), portanto, tudo o que é permitido nessa especificação também é permitido no YAML do fluxo de trabalho. Se você for novo no YAML, aqui estão algumas diretrizes rápidas para garantir o fornecimento de um código YAML válido. + **Diferenciação entre maiúsculas e minúsculas**: o arquivo de definição do fluxo de trabalho diferencia maiúsculas de minúsculas, portanto, certifique-se de usar as maiúsculas e minúsculas mostradas nesta documentação. + **Caracteres especiais**: recomendamos o uso de aspas ou aspas duplas em torno dos valores das propriedades que incluam qualquer um dos seguintes caracteres especiais: `{`, `}` , `[` , `]` , &, `*` , `#` , `?` , `|` , `-` , < , >, `=` , `!` , `%` , `@` , `:` , ``` e `,` Se você não incluir as aspas, os caracteres especiais listados anteriormente poderão ser interpretados de forma inesperada. + **Nomes de propriedades**: os *nomes* das propriedades (em oposição aos *valores* das propriedades) são limitados a caracteres alfanuméricos (a-z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Você não pode usar aspas ou aspas duplas para ativar caracteres especiais e espaços nos nomes das propriedades. Não permitido: `'My#Build@action'` `My#Build@action` `My Build Action` Permitido: `My-Build-Action_1` + **Códigos de escape**: se o valor da sua propriedade incluir códigos de escape (por exemplo, `\n` ou `\t`), siga estas diretrizes: + Use aspas simples para retornar o código de escape como uma string. Por exemplo, `'my string \n my string'`, retorna a string `my string \n my string`. + Use aspas duplas para analisar o código de escape. Por exemplo, `"my string \n my new line"`, retorna: ``` my string my new line ``` + **Comentários**: prefacie os comentários com `#`. Exemplo: ``` Name: MyWorkflow # This is a comment. SchemaVersion: 1.0 ``` + **Triple dash (`---`)**: não use `---` em seu código YAML. CodeCatalyst ignora tudo depois do`---`. ### Convenções de nomenclatura Neste guia, usamos os termos *propriedade* e *seção* para nos referirmos aos itens principais em um arquivo de definição de fluxo de trabalho. + Uma *propriedade* é qualquer item que inclua dois pontos (`:`). Por exemplo, no trecho de código a seguir, todas as seguintes são propriedades: `Name`, `SchemaVersion`, `RunMode`, `Triggers`, `Type` e `Branches`. + Uma *seção* é qualquer propriedade que tenha subpropriedades. No trecho de código a seguir, há uma seção `Triggers`. **nota** Neste guia, as “seções” às vezes são chamadas de “propriedades” e vice-versa, dependendo do contexto. ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main ``` ## Propriedades de nível superior Veja a seguir a documentação de referência das propriedades de nível superior do arquivo de definição do fluxo de trabalho. ``` # Name Name: workflow-name # Schema version SchemaVersion: 1.0 # Run mode RunMode: QUEUED|SUPERSEDED|PARALLEL # Compute Compute: ... # Triggers Triggers: ... # Actions Actions: ... ``` ### Name (Obrigatório) O nome do fluxo de trabalho. O nome do fluxo de trabalho é mostrado na lista de fluxos de trabalho e mencionado nas notificações e nos logs. O nome do fluxo de trabalho e o nome do arquivo de definição do fluxo de trabalho podem corresponder, ou você pode nomeá-los de forma diferente. Os nomes de fluxos de trabalho não precisam ser exclusivos. Os nomes de fluxos de trabalho são limitados a caracteres alfanuméricos (a-z, A-Z, 0-9), hifens (-) e sublinhados (\$1). Não são permitidos espaços. Você não pode usar aspas para habilitar caracteres especiais e espaços nos nomes de fluxo de trabalho. **UI correspondente: editor/Workflow propriedades visuais/nome do fluxo de trabalho** ### SchemaVersion (Obrigatório) A versão do esquema da definição do fluxo de trabalho. Atualmente, o único valor válido é `1.0`. Interface de usuário correspondente: *nenhuma* ### RunMode (Optional) Como CodeCatalyst lida com várias execuções. É possível usar um dos seguintes valores: + `QUEUED` – Várias execuções são colocadas em fila e executadas uma após a outra. É possível ter até 50 execuções em uma fila. + `SUPERSEDED` – Várias execuções são colocadas em fila e executadas uma após a outra. Uma fila só pode ter uma execução, portanto, se duas execuções terminarem juntas na mesma fila, a execução posterior substituirá a execução anterior e a execução anterior será cancelada. + `PARALLEL` – Várias execuções ocorrem simultaneamente. Se essa propriedade for omitida, o padrão será `QUEUED`. Para obter mais informações, consulte [Configurar o comportamento de enfileiramento das execuções](workflows-configure-runs.md). **UI correspondente: editor/Workflow propriedades visuais/Avançado/Modo de execução** ### Compute (Optional) O mecanismo de computação usado para executar as ações de fluxo de trabalho. É possível especificar a computação em nível de fluxo de trabalho ou em nível de ação, mas não em ambos. Quando especificada em nível de fluxo de trabalho, a configuração de computação se aplica a todas as ações definidas no fluxo de trabalho. Em nível de fluxo de trabalho, também é possível realizar várias ações na mesma instância. Para obter mais informações, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Para ter mais informações sobre computação, consulte [Configuração de imagens de computação e runtime](workflows-working-compute.md). Interface de usuário correspondente: *nenhuma* ``` Name: MyWorkflow SchemaVersion: 1.0 ... Compute: Type: EC2 | Lambda Fleet: fleet-name SharedInstance: true | false ``` #### Type (Compute/**Type**) (Necessário se `Compute` estiver definido) O tipo do mecanismo de computação. É possível usar um dos seguintes valores: + **EC2** (editor visual) ou `EC2` (editor YAML) Otimizado para flexibilidade durante as execuções de ação. + **Lambda** (editor visual) ou `Lambda` (editor YAML) Velocidades otimizadas de inicialização da ação. Para obter informações sobre tipos de dados, consulte [Tipos de computação](workflows-working-compute.md#compute.types). **UI correspondente: editor/Workflow propriedades visuais/Avançada/Tipo de computação** #### Fleet (Compute/**Fleet**) (Optional) Especifique a máquina ou a frota que executará o fluxo de trabalho ou as ações de fluxo de trabalho. Com frotas sob demanda, quando uma ação é iniciada, o fluxo de trabalho provisiona os recursos necessários e as máquinas são destruídas quando a ação termina. Exemplos de frota sob demanda: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. Para ter mais informações sobre frotas sob demanda, consulte [Propriedades da frota sob demanda](workflows-working-compute.md#compute.on-demand). Com frotas provisionadas, você configura um conjunto de máquinas dedicadas para realizar as ações do fluxo de trabalho. Essas máquinas permanecem ociosas, prontas para processar ações imediatamente. Para ter mais informações sobre frotas provisionadas, consulte [Propriedades da frota provisionada](workflows-working-compute.md#compute.provisioned-fleets). Se `Fleet` for omitido, o padrão será `Linux.x86-64.Large`. Para ter mais informações sobre frotas de computação, consulte [Frotas de computação](workflows-working-compute.md#compute.fleets). **UI correspondente: editor/Workflow propriedades visuais/Avançada/Frota de computação** #### SharedInstance (Compute/**SharedInstance**) (Optional) Especifique o recurso de compartilhamento de computação para suas ações. Com o compartilhamento de computação, as ações em um fluxo de trabalho são executadas na mesma instância (imagem do ambiente de runtime). É possível usar um dos seguintes valores: + `TRUE` significa que a imagem do ambiente de runtime é compartilhada entre as ações do fluxo de trabalho. + `FALSE` significa que uma imagem separada do ambiente de runtime é iniciada e usada para cada ação em um fluxo de trabalho, portanto, você não pode compartilhar recursos como artefatos e variáveis sem configuração adicional. Para ter mais informações sobre compartilhamento de computação, consulte [Compartilhamento de computação entre ações](compute-sharing.md). Interface de usuário correspondente: *nenhuma* ### Triggers (Optional) Uma sequência de um ou mais gatilhos para esse fluxo de trabalho. Se um gatilho não for especificado, inicie manualmente seu fluxo de trabalho. Para ter mais informações sobre gatilhos, consulte [Início da execução automática de um fluxo de trabalho usando gatilhos](workflows-add-trigger.md). **UI correspondente: editor/workflow diagrama visual/acionadores** ``` Name: MyWorkflow SchemaVersion: 1.0 ... Triggers: - Type: PUSH Branches: - branch-name FilesChanged: - folder1/file - folder2/ - Type: PULLREQUEST Events: - OPEN - CLOSED - REVISION Branches: - branch-name FilesChanged: - file1.txt - Type: SCHEDULE # Run the workflow at 10:15 am (UTC+0) every Saturday Expression: "15 10 ? * 7 *" Branches: - branch-name ``` #### Type (Triggers/**Type**) (Necessário se `Triggers` estiver definido) Especifique o tipo de gatilho. É possível usar um dos seguintes valores: + **Envio** (editor visual) ou `PUSH` (editor YAML) Um gatilho de envio inicia a execução de um fluxo de trabalho quando uma alteração é enviada para seu repositório de origem. A execução do fluxo de trabalho usará os arquivos na ramificação *para* a qual você está enviando (ou seja, a ramificação de destino). + **Solicitação pull** (editor visual) ou `PULLREQUEST` (editor YAML) Um gatilho de solicitação pull inicia a execução de um fluxo de trabalho quando uma solicitação pull é aberta, atualizada ou fechada no seu repositório de origem. A execução do fluxo de trabalho usará os arquivos na ramificação *da* a qual você está extraindo (ou seja, a ramificação de origem). + **Programação** (editor visual) ou `SCHEDULE` (editor YAML) Um gatilho de programação inicia a execução do fluxo de trabalho em uma programação definida por uma expressão cron especificada por você. Uma execução de fluxo de trabalho separada será iniciada para cada ramificação em seu repositório de origem usando os arquivos da ramificação. (Para limitar as ramificações nas quais o gatilho é ativado, use o campo **Ramificações** (editor visual) ou a propriedade `Branches` (editor YAML).) Ao configurar um gatilho de programação, siga estas instruções: + Use apenas um gatilho de programação por fluxo de trabalho. + Se você definiu vários fluxos de trabalho em seu CodeCatalyst espaço, recomendamos que você agende no máximo 10 deles para começarem simultaneamente. + Certifique-se de configurar a expressão cron do gatilho com tempo adequado entre as execuções. Para obter mais informações, consulte [Expression](#workflow.triggers.expression). Para obter exemplos, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). **UI correspondente: editor/workflow diagrama visual/acionadores/tipo de gatilho** #### Events (Triggers/**Events**) (Obrigatório se o gatilho `Type` estiver definido como `PULLREQUEST`) Especifique o tipo de eventos de solicitação pull que iniciarão a execução de um fluxo de trabalho. Os valores válidos são os seguintes: + **A solicitação pull é criada** (editor visual) ou `OPEN` (editor YAML) A execução do fluxo de trabalho é iniciada quando uma solicitação pull é criada. + **A solicitação pull é fechada** (editor visual) ou `CLOSED` (editor YAML) A execução do fluxo de trabalho é iniciada quando uma solicitação pull é fechada. O comportamento do evento `CLOSED` é complicado e é melhor compreendido por meio de um exemplo. Consulte [Exemplo: um gatilho com uma extração, ramificações e um evento “FECHADO”](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close) para obter mais informações. + **Uma nova revisão é feita para solicitação pull** (editor visual) ou `REVISION` (editor YAML) A execução do fluxo de trabalho é iniciada quando uma revisão da solicitação pull é criada. A primeira revisão é criada quando a solicitação pull é criada. Depois disso, uma nova revisão é criada sempre que alguém envia uma nova confirmação para a ramificação de origem especificada na solicitação pull. Se você incluir o evento `REVISION` em seu gatilho de solicitação pull, poderá omitir o evento `OPEN`, pois `REVISION` é um superconjunto de `OPEN`. Você pode especificar vários eventos no mesmo gatilho de solicitação pull. Para obter exemplos, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). **UI correspondente: editor/workflow diagrama visual/acionadores/eventos para pull request** #### Branches (Triggers/**Branches**) (Optional) Especifique as ramificações em seu repositório de origem que o acionador monitora para saber quando iniciar a execução de um fluxo de trabalho. Você pode usar padrões regex para definir os nomes das ramificações. Por exemplo, use `main.*` para combinar todas as ramificações que começam com `main`. As ramificações a serem especificadas são diferentes dependendo do tipo de gatilho: + Para um gatilho de envio, especifique as ramificações *para* as quais você está enviando, ou seja, as ramificações de *destino*. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando os arquivos na ramificação correspondente. Exemplos: `main.*`, `mainline` + Para um gatilho de solicitação pull, especifique as ramificações *para* as quais você está enviando, ou seja, as ramificações de *destino*. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando o arquivo de definição do fluxo de trabalho e os arquivos de origem na ramificação de **origem** (*não* a ramificação correspondente). Exemplos: `main.*`, `mainline`, `v1\-.*` (corresponde às ramificações que começam com `v1-`) + Para um gatilho de programação, especifique as ramificações que contêm os arquivos que devem ser usados pela sua execução programada. Uma execução de fluxo de trabalho será iniciada por ramificação correspondente, usando o arquivo de definição do fluxo de trabalho e os arquivos de origem na ramificação correspondente. Exemplos: `main.*`, `version\-1\.0` **nota** Se você *não* especificar ramificações, o gatilho monitorará todas as ramificações em seu repositório de origem e iniciará a execução de um fluxo de trabalho usando o arquivo de definição do fluxo de trabalho e os arquivos de origem em: A ramificação *para* a qual você está enviando (para gatilhos de envio). Para obter mais informações, consulte [Exemplo: um simples gatilho de envio de código](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple). A ramificação *da* qual você está extraindo (para gatilhos de solicitação pull). Para obter mais informações, consulte [Exemplo: um simples gatilho de solicitação pull](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple). Todas as ramificações (para gatilhos de programação). Uma execução de fluxo de trabalho será iniciada por ramificação em seu repositório de origem. Para obter mais informações, consulte [Exemplo: um gatilho de programação simples](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple). Para ter mais informações sobre ramificações e gatilhos, consulte [Diretrizes para o uso de gatilhos e ramificações](workflows-add-trigger-considerations.md). Para obter mais exemplos, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). UI correspondente: visualeditor/workflow diagram/Triggers/**Branches** #### FilesChanged (Triggers/**FilesChanged**) (Opcional se o gatilho `Type` estiver definido como `PUSH`, ou `PULLREQUEST`. Não compatível se o gatilho `Type` estiver definido como `SCHEDULE`.) Especifique os arquivos ou pastas em seu repositório de origem que o acionador monitora para saber quando iniciar a execução de um fluxo de trabalho. Você pode usar expressões regulares para corresponder nomes ou caminhos de arquivos. Para obter exemplos, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). **UI correspondente: editor/workflow diagrama visual/acionadores/arquivos alterados** #### Expression (Triggers/**Expression**) (Obrigatório se o gatilho `Type` estiver definido como `SCHEDULE`) Especifique a expressão cron que descreve quando você deseja que suas execuções de fluxo de trabalho programadas ocorram. As expressões Cron CodeCatalyst usam a seguinte sintaxe de seis campos, em que cada campo é separado por um espaço: *minutes* *hours* *days-of-month* *month* *days-of-week* *year* **Exemplos de expressões cron** | Minutos | Horas | Dias do mês | Mês | Dias da semana | Ano | Significado | | --- | --- | --- | --- | --- | --- | --- | | 0 | 0 | ? | \$1 | SEG-SEX | \$1 | Executada um fluxo de trabalho à meia-noite (UTC\$10) de segunda a sexta. | | 0 | 2 | \$1 | \$1 | ? | \$1 | Executada um fluxo de trabalho às 2h (UTC\$10) todos os dias. | | 15 | 22 | \$1 | \$1 | ? | \$1 | Executada um fluxo de trabalho às 22h15 (UTC\$10) todos os dias. | | 0/30 | 22-2 | ? | \$1 | SÁB-DOM | \$1 | Executa um fluxo de trabalho a cada 30 minutos de sábado a domingo, entre 22h do dia inicial e 2h do dia seguinte (UTC\$10). | | 45 | 13 | L | \$1 | ? | 2023-2027 | Executa um fluxo de trabalho às 13h45 (UTC\$10) no último dia do mês entre os anos de 2023 e 2027, inclusive. | Ao especificar expressões cron em CodeCatalyst, siga estas diretrizes: + Especifique uma única expressão cron por gatilho `SCHEDULE`. + Coloque a expressão cron entre aspas duplas (`"`) no editor YAML. + Especifique o horário em Tempo Universal Coordenado (UTC). Outros fusos horários não são suportados. + Configure pelo menos 30 minutos entre as execuções. Não há suporte para uma cadência mais rápida. + Especifique o *days-of-week* campo *days-of-month* ou, mas não ambos. Se você especificar um valor ou asterisco (`*`) em um dos campos, deverá usar um ponto de interrogação (`?`) no outro. O asterisco significa “tudo” e o ponto de interrogação significa “qualquer”. Para obter mais exemplos de expressões cron e informações sobre curingas como`?`,, e `*``L`, consulte a [referência de expressões Cron no Guia](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html) do usuário da *Amazon EventBridge *. As expressões Cron CodeCatalyst funcionam exatamente da mesma maneira. EventBridge Para ver exemplos de gatilhos de programação, consulte [Exemplos: gatilhos em fluxos de trabalho](workflows-add-trigger-examples.md). UI correspondente: visualeditor/workflow diagram/Triggers/**Schedule** ### Ações Uma sequência de uma ou mais ações para esse fluxo de trabalho. CodeCatalyst suporta vários tipos de ação, como ações de criação e teste, que oferecem diferentes tipos de funcionalidade. Cada tipo de ação tem: + uma propriedade `Identifier` que indica o ID exclusivo e de codificação rígida da ação. Por exemplo, `aws/build@v1` identifica a ação de criação. + uma seção `Configuration` que contém propriedades específicas da ação. Para ter mais informações sobre cada tipo de ação, consulte [Tipos de ação](workflows-actions.md#workflows-actions-types). O tópico [Tipos de ação](workflows-actions.md#workflows-actions-types) tem links para a documentação de cada ação. Veja a seguir a referência YAML para ações e grupos de ações no arquivo de definição do fluxo de trabalho. ``` Name: MyWorkflow SchemaVersion: 1.0 ... Actions: action-or-gate-name: Identifier: identifier Configuration: ... #Action groups action-group-name: Actions: ... ``` #### action-or-gate-name (Actions/*action-or-gate-name*) (Obrigatório) *action-name*Substitua por um nome que você deseja dar à ação. Os nomes das ações devem ser exclusivos no fluxo de trabalho e incluir apenas caracteres alfanuméricos, hifens e sublinhados. Para ter mais informações sobre as regras de sintaxe, consulte [Diretrizes de sintaxe do YAML](#workflow.syntax.conv). Para ter mais informações sobre práticas de nomenclatura para ações, inclusive restrições, consulte [action-or-gate-name](#workflow.actions.name). **UI correspondente: editor visual//Guia de *action-name* configuração/ Nome da ação ou **Nome de exibição da ação**** #### action-group-name (Actions/*action-group-name*) (Optional) Um *grupo de ações* contém uma ou mais ações. O agrupamento de ações em grupos ajuda a manter o fluxo de trabalho organizado e também permite configurar dependências entre grupos diferentes. *action-group-name*Substitua por um nome que você deseja dar ao grupo de ação. Os nomes de grupos das ações devem ser exclusivos no fluxo de trabalho e incluir apenas caracteres alfanuméricos, hifens e sublinhados. Para ter mais informações sobre as regras de sintaxe, consulte [Diretrizes de sintaxe do YAML](#workflow.syntax.conv). Para ter mais informações sobre os grupos de ações, consulte [Agrupar ações em grupos de ações](workflows-group-actions.md). Interface de usuário correspondente: *nenhuma*