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á.
# 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).