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