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á.
# CodePipeline referência de estrutura de tubulação
Você pode usar CodePipeline para estruturar um CI/CD pipeline de etapas automatizadas que realizam tarefas que criam, testam e implantam o código-fonte do seu aplicativo. Esta seção de referência dá detalhes sobre a estrutura JSON e os parâmetros no pipeline. Para obter uma lista detalhada dos conceitos que descrevem como os pipelines são usados, consulte [CodePipeline conceitos ](concepts.md).
+ Ao criar um pipeline, você escolhe uma ação e um provedor de origem disponíveis, como um bucket S3, CodeCommit repositório, repositório Bitbucket ou GitHub repositório que contém seu código-fonte e inicia seu pipeline quando você confirma uma alteração no código-fonte. Esta seção de referência fornece informações de referência sobre as origens disponíveis para o pipeline. Para obter mais informações sobre como trabalhar com ações de origem, consulte [Inicie um pipeline em CodePipeline](pipelines-about-starting.md).
+ Você pode escolher as ações e os provedores de teste, criação e implantação que deseja incluir automaticamente nas execuções do pipeline. Esta seção de referência apresenta informações de referência sobre as ações disponíveis e como elas se encaixam no JSON do pipeline.
+ O pipeline finalizado consistirá em um estágio de origem com estágios adicionais nos quais você configura ações para implantar e testar a aplicação. Para obter um exemplo conceitual de um DevOps pipeline que implanta seu aplicativo, consulte. [DevOps exemplo de pipeline](concepts-devops-example.md)
Por padrão, qualquer pipeline criado com sucesso AWS CodePipeline tem uma estrutura válida. No entanto, se você criar ou editar manualmente um arquivo JSON para criar um pipeline ou atualizar um pipeline a partir do AWS CLI, poderá criar inadvertidamente uma estrutura inválida. A referência a seguir pode ajudar a entender melhor os requisitos da estrutura do pipeline e como solucionar problemas. Consulte as restrições em [Cotas no AWS CodePipeline.](limits.md), que se aplicam a todos os pipelines.
As seções a seguir fornecem parâmetros de alto nível e a posição na estrutura do pipeline. Os requisitos de estrutura de pipeline são detalhados em cada seção para os seguintes tipos de componentes de pipeline:
+ Referência de campo para o [Declaração de pipeline](pipeline-requirements.md)
+ Referência de campo para o [Declaração de estágio](stage-requirements.md)
+ Referência de campo para o [Declaração de ação](action-requirements.md)
+ Lista de [Provedores de ação válidos em CodePipeline](actions-valid-providers.md) por tipo de ação
+ Referência do [Configurações válidas para o parâmetro `PollForSourceChanges`](PollForSourceChanges-defaults.md)
+ Referência do [Artefatos de entrada e saída válidos para cada tipo de ação](reference-action-artifacts.md)
+ Lista de links para [Parâmetros de configuração válidos para cada tipo de provedor](structure-configuration-examples.md)
Para obter mais informações, consulte o [PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)objeto no *Guia CodePipeline da API*.
O exemplo de visualização do console do pipeline a seguir mostra o pipeline chamado new-github, os estágios chamados `Source``manual`, e`Build`, e as ações de GitHub (via GitHub aplicativo), aprovação manual e CodeBuild provedores de ação.
![\[Um exemplo da visualização do pipeline no CodePipeline console.\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/images/pipeline-console-view.png)
O modo de edição de pipeline, quando visualizado no diagrama do console, permite que você edite substituições de origem, gatilhos e ações, conforme mostrado no exemplo a seguir.
![\[Um exemplo do modo de edição de pipeline no CodePipeline console.\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/images/pipeline-console-view-edit.png)
**Topics**
+ [Declaração de pipeline](pipeline-requirements.md)
+ [Declaração de estágio](stage-requirements.md)
+ [Declaração de ação](action-requirements.md)
+ [Provedores de ação válidos em CodePipeline](actions-valid-providers.md)
+ [Configurações válidas para o parâmetro `PollForSourceChanges`](PollForSourceChanges-defaults.md)
+ [Artefatos de entrada e saída válidos para cada tipo de ação](reference-action-artifacts.md)
+ [Parâmetros de configuração válidos para cada tipo de provedor](structure-configuration-examples.md)
# Declaração de pipeline
O nível de pipeline e metadados de um pipeline tem uma estrutura básica que inclui os seguintes parâmetros e sintaxe. O parâmetro pipeline representa a estrutura de ações e estágios a serem executados no pipeline.
Para obter mais informações, consulte o [PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)objeto no *Guia CodePipeline da API*.
O exemplo a seguir mostra o nível de pipeline e metadados da estrutura do pipeline em JSON e YAML para um pipeline do tipo V2.
------
#### [ YAML ]
```
pipeline:
name: MyPipeline
roleArn: >-
arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline
artifactStore:
type: S3
location: amzn-s3-demo-bucket
stages:
...
version: 6
executionMode: SUPERSEDED
pipelineType: V2
variables:
- name: MyVariable
defaultValue: '1'
triggers:
- providerType: CodeStarSourceConnection
gitConfiguration:
sourceActionName: Source
push:
- branches:
includes:
- main
excludes:
- feature-branch
pullRequest:
- events:
- CLOSED
branches:
includes:
- main*
metadata:
pipelineArn: 'arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline'
created: '2019-12-12T06:49:02.733000+00:00'
updated: '2020-09-10T06:34:07.447000+00:00'
pollingDisabledAt: '2020-09-10T06:34:07.447000\$100:00'
```
------
#### [ JSON ]
```
{
"pipeline": {
"name": "MyPipeline",
"roleArn": "arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline",
"artifactStore": {
"type": "S3",
"location": "amzn-s3-demo-bucket"
},
"stages": {
...
},
"version": 6,
"executionMode": "SUPERSEDED",
"pipelineType": "V2",
"variables": [
{
"name": "MyVariable",
"defaultValue": "1"
}
],
"triggers": [
{
"providerType": "CodeStarSourceConnection",
"gitConfiguration": {
"sourceActionName": "Source",
"push": [
{
"branches": {
"includes": [
"main"
],
"excludes": [
"feature-branch"
]
}
}
],
"pullRequest": [
{
"events": [
"CLOSED"
],
"branches": {
"includes": [
"main*"
]
}
}
]
}
}
]
},
"metadata": {
"pipelineArn": "arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline",
"created": "2019-12-12T06:49:02.733000+00:00",
"updated": "2020-09-10T06:34:07.447000+00:00",
"pollingDisabledAt": "2020-09-10T06:34:07.447000+00:00"
}
}
```
------
## `name`
O nome do pipeline. Quando você edita ou atualiza um pipeline, o nome do pipeline não pode ser alterado.
**nota**
Se você deseja renomear um pipeline existente, pode usar o comando `get-pipeline` da CLI para criar um arquivo JSON que contenha a estrutura do pipeline. Depois, você pode usar o comando `create-pipeline` da CLI para criar um pipeline com essa estrutura e dar a ele um novo nome.
## `roleArn`
O ARN do IAM para a função de CodePipeline serviço, como arn:aws:iam: :80398Example:role/ \$1Service\$1Role. CodePipeline
Para usar o console e visualizar o ARN do perfil de serviço do pipeline em vez da estrutura JSON, escolha o pipeline no console e selecione **Configurações**. Na guia **Geral**, o campo **ARN do perfil de serviço** é exibido.
## `artifactStore` OU `artifactStores`
O `artifactStore` campo contém o tipo de compartimento de artefatos e a localização de um pipeline com todas as ações na mesma AWS região. Se você adicionar ações em uma região diferente do seu pipeline, o `artifactStores` mapeamento será usado para listar o repositório de artefatos para cada AWS região em que as ações são executadas. Ao criar ou editar um pipeline, é necessário ter um bucket de artefato na região do pipeline e ter um bucket de artefato por região em que planeja executar uma ação.
**nota**
Na estrutura do pipeline, você deve incluir `artifactStore` ou `artifactStores` no pipeline, mas não é possível usar os dois. Se você criar uma ação entre regiões em seu pipeline, use `artifactStores`.
O exemplo a seguir mostra a estrutura básica de um pipeline com ações entre regiões que usa o parâmetro `artifactStores`:
```
"pipeline": {
"name": "YourPipelineName",
"roleArn": "CodePipeline_Service_Role",
"artifactStores": {
"us-east-1": {
"type": "S3",
"location": "S3 artifact bucket name, such as amzn-s3-demo-bucket"
},
"us-west-2": {
"type": "S3",
"location": "S3 artifact bucket name, such as amzn-s3-demo-bucket"
}
},
"stages": [
{
...
```
### `type`
O tipo de localização do bucket de artefatos, especificado como Amazon S3.
### `location`
O nome do bucket do Amazon S3 gerado automaticamente para você na primeira vez que você cria um pipeline usando o console, como codepipeline-us-east -2-1234567890, ou qualquer bucket do Amazon S3 que você provisiona para essa finalidade
## `stages`
Esse parâmetro contém o nome de cada estágio no pipeline. Para obter mais informações sobre os parâmetros e a sintaxe no nível de estágio da estrutura do pipeline, consulte o [StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)objeto no *Guia da CodePipeline API*.
A estrutura do pipeline para estágios tem os seguintes requisitos:
+ Um pipeline deve ter pelo menos dois estágios.
+ O primeiro estágio de um pipeline deve ter pelo menos uma ação de origem. Só pode conter ações de origem.
+ Somente o primeiro estágio de um pipeline pode ter ações de origem.
+ Pelo menos um estágio em cada pipeline deve ter uma ação que não seja uma ação de origem.
+ Os nomes de todos os estágios de um pipeline devem ser exclusivos.
+ Os nomes artísticos não podem ser editados no CodePipeline console. Se você editar um nome artístico usando o. AWS CLI e o palco contiver uma ação com um ou mais parâmetros secretos (como um OAuth token), o valor desses parâmetros secretos não será preservado. É necessário inserir manualmente o valor dos parâmetros (que são mascarados por quatro asteriscos no JSON devolvido pela AWS CLI) e incluí-los na estrutura JSON.
**Importante**
Os pipelines inativos por mais de 30 dias terão a sondagem desabilitada para o pipeline. Para obter mais informações, consulte [pollingDisabledAt](#metadata.pollingDisabledAt)na referência da estrutura do pipeline. Para obter as etapas a fim de migrar o pipeline da sondagem para a detecção de alterações baseada em eventos, consulte [Métodos de detecção da alteração](change-detection-methods.md).
## `version`
O número de versão de um pipeline é gerado e atualizado automaticamente sempre que o pipeline é atualizado.
## `executionMode`
Você pode definir o modo de execução do pipeline para poder especificar o comportamento do pipeline para execuções consecutivas, como enfileiramento, substituição ou execução em modo paralelo. Para obter mais informações, consulte [Definir ou alterar o modo de execução do pipeline](execution-modes.md).
**Importante**
Para pipelines em modo PARALLEL, a reversão do estágio não está disponível. Da mesma forma, condições de falha com um tipo de resultado de reversão não podem ser adicionadas a um pipeline de modo PARALLEL.
## `pipelineType`
O tipo de pipeline especifica a estrutura e os recursos disponíveis no pipeline, como para um pipeline do tipo V2. Para obter mais informações, consulte [Tipos de pipeline](pipeline-types.md).
## `variables`
As variáveis em nível de pipeline são definidas quando o pipeline é criado e resolvido no runtime do pipeline. Para obter mais informações, consulte [Referência de variáveis](reference-variables.md). Para assistir a um tutorial com uma variável no nível do pipeline que é passada no momento da execução do pipeline, consulte. [Tutorial: Usar variáveis no nível do pipeline](tutorials-pipeline-variables.md)
## `triggers`
Os gatilhos permitem configurar o pipeline para iniciar em um determinado tipo de evento ou tipo de evento filtrado, como quando uma alteração em uma ramificação específica ou solicitação pull é detectada. Os acionadores são configuráveis para ações de origem com conexões que usam a `CodeStarSourceConnection` ação em CodePipeline GitHub, como Bitbucket e. GitLab Para ter mais informações sobre ações de origem que usam conexões, consulte [Adicionar provedores de origem de terceiros usando CodeConnections](pipelines-connections.md).
Para obter informações e exemplos mais detalhados, consulte [Automatizar a inicialização de pipelines usando gatilhos e filtragem](pipelines-triggers.md).
Para filtragem, padrões de expressão regular no formato glob são compatíveis conforme detalhado em [Trabalhar com padrões glob na sintaxe](syntax-glob.md).
**nota**
As ações de origem CodeCommit e do S3 exigem um recurso de detecção de alterações configurado (uma EventBridge regra) ou use a opção de pesquisar alterações na fonte no repositório. Para pipelines com uma ação de origem do Bitbucket ou do GitHub Enterprise Server, você não precisa configurar um webhook ou usar a pesquisa como padrão. GitHub A ação do Connections gerencia a detecção de alterações para você.
**Importante**
Os pipelines inativos por mais de 30 dias terão a sondagem desabilitada para o pipeline. Para obter mais informações, consulte [pollingDisabledAt](#metadata.pollingDisabledAt)na referência da estrutura do pipeline. Para obter as etapas a fim de migrar o pipeline da sondagem para a detecção de alterações baseada em eventos, consulte [Métodos de detecção da alteração](change-detection-methods.md).
### Campos de `gitConfiguration`
A configuração do Git para o acionador, inclusive os tipos de eventos e todos os parâmetros para filtragem por ramificações, caminhos de arquivo, tags ou eventos pull request.
Os campos na estrutura JSON são definidos da seguinte forma:
+ `sourceActionName`: o nome da ação de origem do pipeline com a configuração do Git.
+ `push`: envie eventos com filtragem. Esses eventos usam o operador OU entre diferentes filtros push e o operador E dentro dos filtros.
+ `branches`: as ramificações a serem filtradas. As ramificações usam o operador E entre inclusões e exclusões.
+ `includes`: padrões para filtrar as ramificações que serão incluídas. Inclui o uso de um operador OU.
+ `excludes`: padrões para filtrar as ramificações que serão excluídas. Exclui o uso de um operador OU.
+ `filePaths`: os nomes dos caminhos do arquivo a serem filtrados.
+ `includes`: padrões para filtrar os caminhos de arquivo que serão incluídos. Inclui o uso de um operador OU.
+ `excludes`: padrões para filtrar os caminhos de arquivo que serão excluídos. Exclui o uso de um operador OU.
+ `tags`: os nomes das etiquetas a serem filtradas.
+ `includes`: padrões para filtrar as etiquetas que serão incluídas. Inclui o uso de um operador OU.
+ `excludes`: padrões para filtrar as etiquetas que serão excluídas. Exclui o uso de um operador OU.
+ `pullRequest`: eventos de solicitação pull com filtragem de eventos de solicitação pull e filtros de solicitação pull.
+ `events`: filtra eventos de solicitação pull abertos, atualizados ou fechados, conforme especificado.
+ `branches`: As ramificações a serem filtradas. As ramificações usam o operador E entre inclusões e exclusões.
+ `includes`: padrões para filtrar as ramificações que serão incluídas. Inclui o uso de um operador OU.
+ `excludes`: padrões para filtrar as ramificações que serão excluídas. Exclui o uso de um operador OU.
+ `filePaths`: os nomes dos caminhos do arquivo a serem filtrados.
+ `includes`: padrões para filtrar os caminhos de arquivo que serão incluídos. Inclui o uso de um operador OU.
+ `excludes`: padrões para filtrar os caminhos de arquivo que serão excluídos. Exclui o uso de um operador OU.
Este é um exemplo da configuração do acionador para tipos de evento push e pull request.
```
"triggers": [
{
"provider": "Connection",
"gitConfiguration": {
"sourceActionName": "ApplicationSource",
"push": [
{
"filePaths": {
"includes": [
"projectA/**",
"common/**/*.js"
],
"excludes": [
"**/README.md",
"**/LICENSE",
"**/CONTRIBUTING.md"
]
},
"branches": {
"includes": [
"feature/**",
"release/**"
],
"excludes": [
"mainline"
]
},
"tags": {
"includes": [
"release-v0", "release-v1"
],
"excludes": [
"release-v2"
]
}
}
],
"pullRequest": [
{
"events": [
"CLOSED"
],
"branches": {
"includes": [
"feature/**",
"release/**"
],
"excludes": [
"mainline"
]
},
"filePaths": {
"includes": [
"projectA/**",
"common/**/*.js"
],
"excludes": [
"**/README.md",
"**/LICENSE",
"**/CONTRIBUTING.md"
]
}
}
]
}
}
],
```
### Campos `push` do tipo de evento para inclusão e exclusão
O comportamento de inclusão e exclusão dos níveis dos campos de configuração do Git para tipos de evento **push** é mostrado na seguinte lista:
```
push (OR operation is used between push and pullRequest or multiples)
filePaths (AND operation is used between filePaths, branches, and tags)
includes (AND operation is used between includes and excludes)
**/FILE.md, **/FILE2 (OR operation is used between file path names)
excludes (AND operation is used between includes and excludes)
**/FILE.md, **/FILE2 (OR operation is used between file path names)
branches (AND operation is used between filePaths, branches, and tags)
includes (AND operation is used between includes and excludes)
BRANCH/**", "BRANCH2/** (OR operation is used between branch names)
excludes (AND operation is used between includes and excludes)
BRANCH/**", "BRANCH2/** (OR operation is used between branch names)
tags (AND operation is used between filePaths, branches, and tags)
includes (AND operation is used between includes and excludes)
TAG/**", "TAG2/** (OR operation is used between tag names)
excludes (AND operation is used between includes and excludes)
TAG/**", "TAG2/** (OR operation is used between tag names)
```
### Campos `pull request` do tipo de evento para inclusão e exclusão
O comportamento de inclusão e exclusão dos níveis dos campos de configuração do Git para tipos de evento **pull request** é mostrado na seguinte lista:
```
pullRequest (OR operation is used between push and pullRequest or multiples)
events (AND operation is used between events, filePaths, and branches). Includes/excludes are N/A for pull request events.
filePaths (AND operation is used between events, filePaths, and branches)
includes (AND operation is used between includes and excludes)
**/FILE.md, **/FILE2 (OR operation is used between file path names)
excludes (AND operation is used between includes and excludes)
**/FILE.md, **/FILE2 (OR operation is used between file path names)
branches (AND operation is used between events, filePaths, and branches)
includes (AND operation is used between includes and excludes)
BRANCH/**", "BRANCH2/** (OR operation is used between branch names)
excludes (AND operation is used between includes and excludes)
BRANCH/**", "BRANCH2/** (OR operation is used between branch names)
```
## `metadata`
Os campos de metadados de pipeline são diferentes da estrutura do pipeline e não podem ser editados. Quando você atualiza um pipeline, a data no campo de metadados `updated` é alterada automaticamente.
### `pipelineArn`
O nome do recurso da Amazon (ARN) do pipeline.
Para usar o console e visualizar o ARN do pipeline em vez da estrutura JSON, selecione o pipeline no console e selecione **Configurações**. Na guia **Geral**, o campo **ARN do pipeline** é exibido.
### `created`
A data e a hora em que o pipeline foi criado.
### `updated`
A data e a hora em que o pipeline foi atualizado pela última vez.
### `pollingDisabledAt`
A data e a hora quando, para um pipeline configurado para sondagem para detecção de alterações, a sondagem foi desativada.
Os pipelines inativos por mais de 30 dias terão a sondagem desabilitada para o pipeline.
+ Os pipelines inativos terão a pesquisa desabilitada após 30 dias sem execuções.
+ Os pipelines que usam EventBridge CodeStar conexões ou webhooks não serão afetados.
+ Os pipelines ativos não serão afetados.
Para obter mais informações, consulte o `pollingDisabledAt` parâmetro em [PipelineMetadata](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineMetadata.html)objeto no *Guia CodePipeline da API*. Para obter as etapas a fim de migrar o pipeline da sondagem para a detecção de alterações baseada em eventos, consulte [Métodos de detecção da alteração](change-detection-methods.md).
# Declaração de estágio
O nível de estágio de um pipeline tem uma estrutura básica que inclui os seguintes parâmetros e sintaxe. Para obter mais informações, consulte o [StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)objeto no *Guia CodePipeline da API*.
O exemplo a seguir mostra o nível de estágio da estrutura do pipeline em JSON e YAML. O exemplo mostra dois estágios chamados `Source` e `Build`. O exemplo contém duas condições, uma para `onSuccess` e outra para `beforeEntry`.
------
#### [ YAML ]
```
pipeline:
name: MyPipeline
roleArn: >-
arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline
artifactStore:
type: S3
location: amzn-s3-demo-bucket
stages:
- name: Source
actions:
- name: Source
...
- name: Build
actions:
- name: Build
...
onSuccess:
conditions:
- result: ROLLBACK
rules:
- name: DeploymentWindowRule
...
beforeEntry:
conditions:
- result: FAIL
rules:
- name: MyLambdaRule
...
version: 6
metadata:
pipelineArn: 'arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline'
created: '2019-12-12T06:49:02.733000+00:00'
updated: '2020-09-10T06:34:07.447000+00:00'
```
------
#### [ JSON ]
```
{
"pipeline": {
"name": "MyPipeline",
"roleArn": "arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline",
"artifactStore": {
"type": "S3",
"location": "amzn-s3-demo-bucket"
},
"stages": [
{
"name": "Source",
"actions": [
{
"name": "Source",
...
}
]
},
{
"name": "Build",
"actions": [
{
"name": "Build",
...
}
],
"onSuccess": {
"conditions": [
{
"result": "ROLLBACK",
"rules": [
{
"name": "DeploymentWindowRule",
...
}
]
}
]
},
"beforeEntry": {
"conditions": [
{
"result": "FAIL",
"rules": [
{
"name": "MyLambdaRule",
...
}
]
}
]
}
}
],
}
],
"version": 6
},
"metadata": {
"pipelineArn": "arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline",
"created": "2019-12-12T06:49:02.733000+00:00",
"updated": "2020-09-10T06:34:07.447000+00:00"
}
}
```
------
## `name`
O nome do estágio do .
## `actions`
O nível de ação de um pipeline tem uma estrutura básica que inclui os seguintes parâmetros e sintaxe. Para ver parâmetros e exemplos, consulte [Declaração de ação](action-requirements.md).
## `conditions`
As condições contêm uma ou mais regras que estão disponíveis em uma lista de regras em CodePipeline. Se todas as regras em uma condição forem bem-sucedidas, a condição será atendida. É possível definir condições para que, caso os critérios não sejam cumpridos, o resultado especificado seja ativado.
Você pode configurar os seguintes tipos de condições:
+ `beforeEntry`
+ `onFailure`
+ `onSuccess`
Para ter mais informações e exemplos, consulte [Configurar condições para um estágio](stage-conditions.md).
## `rules`
Toda condição contém um conjunto estruturado de regras, organizadas em uma ordem específica e avaliadas simultaneamente. Portanto, se uma regra falhar na condição, a condição falhará. Você pode substituir as condições da regra no runtime do pipeline.
As regras disponíveis são fornecidas na referência de Regra. Para ter mais informações, consulte a referência da estrutura de regras em [Referência da estrutura de regras](rule-reference.md).
# Declaração de ação
O nível de ação de um pipeline tem uma estrutura básica que inclui os seguintes parâmetros e sintaxe. Para obter mais informações, consulte o [ActionDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionDeclaration.html)objeto no *Guia CodePipeline da API*.
O exemplo a seguir mostra o nível de ação da estrutura do pipeline nos formatos JSON e YAML.
------
#### [ YAML ]
```
. . .
stages:
- name: Source
actions:
- name: Source
actionTypeId:
category: Source
owner: AWS
provider: S3
version: '1'
runOrder: 1
configuration:
PollForSourceChanges: 'false'
S3Bucket: amzn-s3-demo-bucket
S3ObjectKey: codedeploy_linux.zip
outputArtifacts:
- name: SourceArtifact
inputArtifacts: []
region: us-west-2
namespace: SourceVariables
- name: Build
actions:
- name: Build
actionTypeId:
category: Build
owner: AWS
provider: CodeBuild
version: '1'
runOrder: 1
configuration:
EnvironmentVariables: >-
[{"name":"ETag","value":"#{SourceVariables.ETag}","type":"PLAINTEXT"}]
ProjectName: my-project
outputArtifacts:
- name: BuildArtifact
inputArtifacts:
- name: SourceArtifact
region: us-west-2
namespace: BuildVariables
runOrder: 1
configuration:
CustomData: >-
Here are the exported variables from the build action: S3 ETAG:
#{BuildVariables.ETag}
outputArtifacts: []
inputArtifacts: []
region: us-west-2
```
------
#### [ JSON ]
```
. . .
"stages": [
{
"name": "Source",
"actions": [
{
"name": "Source",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"provider": "S3",
"version": "1"
},
"runOrder": 1,
"configuration": {
"PollForSourceChanges": "false",
"S3Bucket": "amzn-s3-demo-bucket",
"S3ObjectKey": "aws-codepipeline-s3-aws-codedeploy_linux.zip"
},
"outputArtifacts": [
{
"name": "SourceArtifact"
}
],
"inputArtifacts": [],
"region": "us-west-2",
"namespace": "SourceVariables"
}
]
},
{
"name": "Build",
"actions": [
{
"name": "Build",
"actionTypeId": {
"category": "Build",
"owner": "AWS",
"provider": "CodeBuild",
"version": "1"
},
"runOrder": 1,
"configuration": {
"EnvironmentVariables": "[{\"name\":\"ETag\",\"value\":\"#{SourceVariables.ETag}\",\"type\":\"PLAINTEXT\"}]",
"ProjectName": "my-build-project"
},
"outputArtifacts": [
{
"name": "BuildArtifact"
}
],
"inputArtifacts": [
{
"name": "SourceArtifact"
}
],
"region": "us-west-2",
"namespace": "BuildVariables"
}
]
. . .
```
------
Para obter uma lista de exemplos de detalhes de `configuration` adequados para o tipo de provedor, consulte [Parâmetros de configuração válidos para cada tipo de provedor](structure-configuration-examples.md).
A estrutura de ação tem estes requisitos:
+ Os nomes de todas as ações em um estágio devem ser exclusivos.
+ É necessária uma ação de origem para cada pipeline.
+ As ações de origem que não usam uma conexão podem ser configuradas para detecção de alterações ou para desativar a detecção de alterações. Consulte [Métodos de detecção de alterações](change-detection-methods.md).
+ Isso ocorre com todas as ações, não importa se estão no mesmo estágio ou em estágios seguintes. No entanto, o artefato de entrada não precisa ser a próxima ação na sequência rígida da ação que forneceu o artefato de saída. Ações em paralelo podem declarar pacotes de artefatos de saída diferentes, que, por sua vez, são usados por ações seguintes diferentes.
+ Quando você usa um bucket do Amazon S3 como local de implantação, também especifica uma chave de objeto. Uma chave de objeto pode ser um nome de arquivo (objeto) ou uma combinação de um prefixo (caminho da pasta) e um nome de arquivo. Você pode usar variáveis para especificar o nome do local que deseja que o pipeline use. As ações de implantação do Amazon S3 são compatíveis com o uso das variáveis nas chaves de objeto do Amazon S3 a seguir.
**Uso de variáveis no Amazon S3**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/action-requirements.html)
## `name`
O nome da ação.
## `region`
Para ações em que o provedor é um AWS service (Serviço da AWS), o Região da AWS do recurso.
Ações entre regiões usam o campo `Region` para designar a Região da AWS onde as ações devem ser criadas. Os AWS recursos criados para essa ação devem ser criados na mesma região fornecida no `region` campo. Não é possível criar ações entre regiões para os seguintes tipos de ação:
+ Ações de origem
+ Ações por provedores de terceiros
+ Ações por provedores personalizados
## `roleArn`
O ARN da função de serviço do IAM que executa a ação declarada. Isso é assumido por meio do roleArn especificado no nível do pipeline.
## `namespace`
As ações podem ser configuradas com variáveis. Use o campo `namespace` para definir as informações de namespace e de variáveis para as variáveis de execução. Para obter informações de referência sobre variáveis de execução e variáveis de saída de ação, consulte [Referência de variáveis](reference-variables.md).
**nota**
Para Amazon ECR, Amazon S3 CodeCommit ou fontes, você também pode criar uma substituição de origem usando a entrada de transformação de entrada para usar `revisionValue` o EventBridge in para seu evento de pipeline, onde `revisionValue` o é derivado da variável de evento de origem para sua chave de objeto, confirmação ou ID de imagem. Para saber mais, consulte a etapa opcional da entrada da transformação de entrada incluída nos procedimentos em [Recursos e ações de origem do Amazon ECR EventBridge](create-cwe-ecr-source.md), [Conexão a ações de origem do Amazon S3 com uma fonte habilitada para eventos](create-S3-source-events.md) ou [CodeCommit ações de origem e EventBridge](triggering.md).
## `actionTypeId`
O ID do tipo de ação é identificado como uma combinação dos quatro campos a seguir.
### `category`
O tipo de etapa ou ação dentro do pipeline, como, por exemplo, uma ação de origem. Cada tipo de ação tem um conjunto específico de provedores de ações válidos. Para conferir uma lista de provedores válidos por tipo de ação, consulte [Referência da estrutura da ação](action-reference.md).
Essas são as `actionTypeId` categorias válidas (tipos de ação) para CodePipeline:
+ `Source`
+ `Build`
+ `Approval`
+ `Deploy`
+ `Test`
+ `Invoke`
+ `Compute`
### `owner`
Para todos os tipos de ação compatíveis no momento, a única string proprietária válida é `AWS`, `ThirdParty` ou `Custom`. Para encontrar a string de proprietário válida para uma ação específica, consulte [Referência da estrutura da ação](action-reference.md).
Para obter mais informações, consulte a [Referência da API do CodePipeline ](https://docs.aws.amazon.com/codepipeline/latest/APIReference).
### `version`
A versão da ação.
### `provider`
O provedor da ação, como CodeBuild.
+ Os tipos válidos de provedor de uma categoria de ação dependem da categoria. Por exemplo, para um tipo de ação de origem, um tipo de provedor válido é `S3`, `CodeStarSourceConnection`, `CodeCommit` ou `Amazon ECR`. Esse exemplo mostra a estrutura para uma ação de origem com um provedor `S3`:
```
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"},
```
## `InputArtifacts`
Esse campo contém a estrutura do artefato de entrada, se for compatível com a categoria de ação. O artefato de entrada de uma ação deve ser exatamente igual ao artefato de saída declarado em uma ação precedente. Por exemplo, se uma ação anterior inclui a seguinte declaração:
```
"outputArtifacts": [
{
"MyApp"
}
],
```
e não há outros artefatos de saída, o artefato de entrada de uma ação seguinte deve ser:
```
"inputArtifacts": [
{
"MyApp"
}
],
```
Por exemplo, uma ação de origem não pode ter artefatos de entrada porque é a primeira ação no pipeline. No entanto, uma ação de origem sempre terá artefatos de saída que são processados pela ação a seguir. Os artefatos de saída para uma ação de origem são os arquivos do aplicativo do repositório de origem, compactados e fornecidos por meio do bucket de artefatos, que são processados pela ação a seguir, como uma CodeBuild ação que atua nos arquivos do aplicativo com comandos de construção.
Como exemplo de ações que não podem ter artefatos de saída, as ações de implantação não têm artefatos de saída porque essas ações geralmente são a última ação em um pipeline.
### `name`
O nome do artefato para os artefatos de entrada da ação.
## `outputArtifacts`
Os nomes dos artefatos de saída devem ser exclusivos em um pipeline. Por exemplo, um pipeline pode incluir uma ação que tenha um artefato de saída com o nome `"MyApp"` e outra ação que tenha um artefato de saída com o nome `"MyBuiltApp"`. Mas um pipeline não pode incluir duas ações que tenham um artefato de saída com o nome `"MyApp"`.
Esse campo contém a estrutura do artefato de saída, caso seja compatível com a categoria de ação. O artefato de saída de uma ação deve ser exatamente igual ao artefato de saída declarado em uma ação anterior. Por exemplo, se uma ação anterior inclui a seguinte declaração:
```
"outputArtifacts": [
{
"MyApp"
}
],
```
e não há outros artefatos de saída, o artefato de entrada de uma ação seguinte deve ser:
```
"inputArtifacts": [
{
"MyApp"
}
],
```
Por exemplo, uma ação de origem não pode ter artefatos de entrada porque é a primeira ação no pipeline. No entanto, uma ação de origem sempre terá artefatos de saída que são processados pela ação a seguir. Os artefatos de saída para uma ação de origem são os arquivos do aplicativo do repositório de origem, compactados e fornecidos por meio do bucket de artefatos, que são processados pela ação a seguir, como uma CodeBuild ação que atua nos arquivos do aplicativo com comandos de construção.
Como exemplo de ações que não podem ter artefatos de saída, as ações de implantação não têm artefatos de saída porque essas ações geralmente são a última ação em um pipeline.
### `name`
O nome do artefato para os artefatos de saída da ação.
## `configuration` (por provedor de ações)
A configuração da ação contém detalhes e parâmetros apropriados ao tipo de provedor. Na seção abaixo, os parâmetros de configuração da ação de exemplo são específicos da ação de origem do S3.
A configuração da ação e os limites do input/output artefato podem variar de acordo com o provedor da ação. Para conferir uma lista de exemplos de configuração de ação por provedor de ações, consulte [Referência da estrutura da ação](action-reference.md) e a tabela em [Parâmetros de configuração válidos para cada tipo de provedor](structure-configuration-examples.md). A tabela fornece um link para a referência de ação de cada tipo de provedor, que mostra os parâmetros de configuração para cada ação em detalhes. Para conferir uma tabela com os limites de artefatos de entrada e saída para cada provedor de ações, consulte [Artefatos de entrada e saída válidos para cada tipo de ação](reference-action-artifacts.md).
As considerações a seguir se aplicam ao trabalho com ações:
+ As ações de origem não têm artefatos de entrada, e as ações de implantação não têm artefatos de saída.
+ Para provedores de ações de origem que não usam uma conexão, como o S3, você deve usar o parâmetro `PollForSourceChanges` para especificar se deseja que o pipeline seja iniciado automaticamente quando uma alteração for detectada. Consulte [Configurações válidas para o parâmetro `PollForSourceChanges`](PollForSourceChanges-defaults.md).
+ Para configurar a detecção automática de alterações para iniciar o pipeline ou para desativar a detecção de alterações, consulte [Ações de origem e métodos de detecção de alterações](change-detection-methods.md).
+ Para configurar gatilhos com filtragem, use a ação de origem para conexões e, em seguida, consulte [Automatizar a inicialização de pipelines usando gatilhos e filtragem](pipelines-triggers.md).
+ Para conhecer as variáveis de saída de cada ação, consulte [Referência de variáveis](reference-variables.md).
**nota**
Para Amazon ECR, Amazon S3 CodeCommit ou fontes, você também pode criar uma substituição de origem usando a entrada de transformação de entrada para usar `revisionValue` o EventBridge in para seu evento de pipeline, onde `revisionValue` o é derivado da variável de evento de origem para sua chave de objeto, confirmação ou ID de imagem. Para obter mais informações, consulte a etapa opcional da entrada da transformação de entrada incluída nos procedimentos em [Recursos e ações de origem do Amazon ECR EventBridge](create-cwe-ecr-source.md), [Conexão a ações de origem do Amazon S3 com uma fonte habilitada para eventos](create-S3-source-events.md) ou [CodeCommit ações de origem e EventBridge](triggering.md).
**Importante**
Os pipelines inativos por mais de 30 dias terão a sondagem desabilitada para o pipeline. Para obter mais informações, consulte [pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)na referência da estrutura do pipeline. Consulte as etapas de migração do pipeline da sondagem para a detecção de alterações baseada em eventos em [Métodos de detecção da alteração](change-detection-methods.md).
**nota**
As ações de origem CodeCommit e do S3 exigem um recurso de detecção de alterações configurado (uma EventBridge regra) ou use a opção de pesquisar alterações na fonte no repositório. Para pipelines com uma ação de origem do Bitbucket ou do GitHub Enterprise Server, você não precisa configurar um webhook ou usar a pesquisa como padrão. GitHub A ação do Connections gerencia a detecção de alterações para você.
## `runOrder`
Um número inteiro positivo que indica a ordem de execução da ação dentro do estágio. As ações paralelas no estágio são mostradas como tendo o mesmo número inteiro. Por exemplo, duas ações com uma ordem de execução de duas serão executadas paralelamente após a execução da primeira ação na etapa.
O valor `runOrder` padrão de uma ação é 1. O valor deve ser um inteiro positivo (número natural). Não é permitido usar frações, números decimais ou negativos ou o número zero. Para especificar uma sequência de ações em série, use o menor número para a primeira ação e os maiores números para cada uma das ações em sequência restantes. Para especificar ações paralelas, use o mesmo número inteiro para cada ação que deseja executar em paralelo. No console, você pode especificar uma sequência serial para uma ação escolhendo **Adicionar grupo de ações** no nível do estágio em que deseja que ela seja executada ou você pode especificar uma sequência paralela escolhendo **Adicionar ação**. *Grupo de ações* se refere a uma ordem de execução de uma ou mais ações no mesmo nível.
Por exemplo, se você deseja que três ações sejam executadas em sequência em um estágio, você daria o valor `runOrder` de 1 para a primeira ação, o valor `runOrder` de 2 para a segunda ação e o valor `runOrder` de 3 para a terceira ação. No entanto, se você deseja que a segunda ação e a terceira ação sejam executadas em paralelo, você daria o valor `runOrder` de 1 para a primeira ação e o valor `runOrder` de 2 para a segunda e a terceira.
**nota**
A numeração das ações em série não precisa estar em uma sequência rígida. Por exemplo, se você tem três ações em uma sequência e decide remover a segunda ação, você não precisa numerar novamente o valor `runOrder` da terceira ação. Como o valor `runOrder` dessa ação (3) é superior ao valor `runOrder` da primeira ação (1), ele será executado em série após a primeira ação no estágio.
# Provedores de ação válidos em CodePipeline
O formato da estrutura de pipeline é usado para compilar ações e estágios em um pipeline. Um tipo de ação é composto por uma categoria de ação e um tipo de provedor.
Cada categoria de ação tem uma lista válida de provedores de ações. Para fazer referência aos provedores de ações válidos para cada categoria de ação, consulte [Referência da estrutura da ação](action-reference.md).
Cada categoria de ação tem um conjunto designado de provedores. Cada provedor de ação, como o Amazon S3, tem um nome de provedor, como `S3`, que deve ser usado no campo `Provider` na categoria de ação da estrutura do pipeline.
Há três valores válidos para o campo `Owner` na seção da categoria de ação na estrutura do pipeline: `AWS`, `ThirdParty` e `Custom`.
Para localizar o nome do provedor e as informações do proprietário do provedor de ações, consulte [Referência da estrutura da ação](action-reference.md) ou [Artefatos de entrada e saída válidos para cada tipo de ação](reference-action-artifacts.md).
Essa tabela lista os provedores válidos por tipo de ação.
**nota**
Para ações do Bitbucket ou do GitHub Enterprise Server, consulte o tópico de referência da [CodeStarSourceConnection para Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com e ações GitLab autogerenciadas](action-reference-CodestarConnectionSource.md) ação. GitHub
**Provedores de ação válidos por tipo de ação**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/actions-valid-providers.html)
Alguns tipos de ação CodePipeline estão disponíveis somente em AWS regiões selecionadas. É possível que um tipo de ação esteja disponível em uma AWS região, mas um AWS provedor para esse tipo de ação não esteja disponível.
Para obter mais informações sobre cada provedor de ações, consulte [Integrações com tipos de CodePipeline ação](integrations-action-type.md).
# Configurações válidas para o parâmetro `PollForSourceChanges`
O padrão do parâmetro `PollForSourceChanges` é determinado pelo método usado para criar o pipeline, conforme descrito na tabela a seguir. Em muitos casos, o parâmetro `PollForSourceChanges` é padronizado como verdadeiro e deve ser desativado.
Quando o parâmetro `PollForSourceChanges` for padronizado como verdadeiro, faça o seguinte:
+ Adicione o parâmetro `PollForSourceChanges` ao arquivo JSON ou ao modelo do CloudFormation .
+ Crie recursos de detecção de alterações (regra de CloudWatch eventos, conforme aplicável).
+ Defina o parâmetro `PollForSourceChanges` para false.
**nota**
Se você criar uma regra de CloudWatch eventos ou webhook, deverá definir o parâmetro como false para evitar acionar o pipeline mais de uma vez.
O parâmetro `PollForSourceChanges` não é usado em ações de origem do Amazon ECR.
+
**Padrões de parâmetros `PollForSourceChanges`**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/PollForSourceChanges-defaults.html)
# Artefatos de entrada e saída válidos para cada tipo de ação
Dependendo do tipo de ação e do provedor, você pode ter o seguinte número de artefatos de entrada e saída.
**Limitações dos tipos de ação dos artefatos**
| Proprietário | Tipo de ação | Fornecedor | Número válido de artefatos de entrada | Número válido de artefatos de saída |
| --- | --- | --- | --- | --- |
| AWS | Fonte | S3 | 0 | 1 |
| AWS | Fonte | CodeCommit | 0 | 1 |
| AWS | Fonte | ECR | 0 | 1 |
| ThirdParty | Fonte | CodeStarSourceConnection | 0 | 1 |
| AWS | Criar | CodeBuild | 1 – 5 | 0 – 5 |
| AWS | Testar | CodeBuild | 1 – 5 | 0 – 5 |
| AWS | Testar | DeviceFarm | 1 | 0 |
| AWS | Aprovação | ThirdParty | 0 | 0 |
| AWS | Implantar | S3 | 1 | 0 |
| AWS | Implantar | CloudFormation | 0 – 10 | 0 – 1 |
| AWS | Implantar | CodeDeploy | 1 | 0 |
| AWS | Implantar | ElasticBeanstalk | 1 | 0 |
| AWS | Implantar | OpsWorks | 1 | 0 |
| AWS | Implantar | ECS | 1 | 0 |
| AWS | Implantar | ServiceCatalog | 1 | 0 |
| AWS | Invocar | Lambda | 0 – 5 | 0 – 5 |
| ThirdParty | Implantar | AlexaSkillsKit | 1 – 2 | 0 |
| Custom | Criar | Jenkins | 0 – 5 | 0 – 5 |
| Custom | Testar | Jenkins | 0 – 5 | 0 – 5 |
| Custom | Qualquer categoria compatível | Conforme especificado na ação personalizada | 0 – 5 | 0 – 5 |
# Parâmetros de configuração válidos para cada tipo de provedor
Essa seção lista parâmetros de `configuration` válidos para cada provedor de ações.
Toda ação deve ter uma configuração válida de ação, que depende do tipo de provedor para a ação em questão. A tabela a seguir mostra os elementos de configuração de ação necessários para cada tipo de provedor válido:
**Propriedades de configuração de ação para tipos de provedor**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/structure-configuration-examples.html)
O exemplo a seguir mostra uma configuração válida para uma ação de implantação que usa o Alexa Skills Kit:
```
"configuration": {
"ClientId": "amzn1.application-oa2-client.aadEXAMPLE",
"ClientSecret": "****",
"RefreshToken": "****",
"SkillId": "amzn1.ask.skill.22649d8f-0451-4b4b-9ed9-bfb6cEXAMPLE"
}
```
O exemplo a seguir mostra uma configuração válida para uma aprovação manual:
```
"configuration": {
"CustomData": "Comments on the manual approval",
"ExternalEntityLink": "http://my-url.com",
"NotificationArn": "arn:aws:sns:us-west-2:12345EXAMPLE:Notification"
}
```