Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# CodePipeline referencia de estructura de tubería
Puede utilizarlos CodePipeline para estructurar una CI/CD canalización de pasos automatizados que realicen tareas de creación, prueba e implementación del código fuente de la aplicación. En esta sección de referencia, se proporcionan detalles sobre la estructura y los parámetros de JSON de la canalización. Para obtener una lista general de conceptos que describen cómo se utilizan las canalizaciones, consulte [CodePipeline conceptos ](concepts.md).
+ Al crear una canalización, eliges una acción fuente y un proveedor disponibles, como un bucket de S3, un CodeCommit repositorio, un repositorio de Bitbucket o un GitHub repositorio que contenga tu código fuente e inicia la canalización cuando realizas un cambio en el código fuente. Esta sección de referencia proporciona información de referencia sobre los orígenes disponibles para su canalización. Para obtener más información acerca de cómo trabajar con acciones de origen, consulte [Iniciar una canalización en CodePipeline](pipelines-about-starting.md).
+ Puede elegir las acciones y los proveedores de prueba, compilación e implementación que desee incluir automáticamente cuando se ejecute la canalización. Esta sección de referencia proporciona información de referencia sobre las acciones disponibles y cómo encajan en el JSON de la canalización.
+ La canalización finalizada constará de una etapa de origen junto con etapas adicionales en las que se configurarán las acciones para implementar y probar la aplicación. Para ver un ejemplo conceptual de una DevOps canalización que despliega tu aplicación, consulta. [DevOps ejemplo de canalización](concepts-devops-example.md)
De forma predeterminada, cualquier canalización que se cree correctamente AWS CodePipeline tiene una estructura válida. Sin embargo, si creas o editas manualmente un archivo JSON para crear una canalización o actualizas una canalización desde AWS CLI allí, podrías crear inadvertidamente una estructura que no sea válida. La siguiente referencia puede ayudarle a entender mejor los requisitos de estructura de su canalización y cómo solucionar los problemas. Consulte las restricciones en [Cuotas en AWS CodePipeline](limits.md), que se aplican a todas las canalizaciones.
En las siguientes secciones, se proporcionan parámetros de alto nivel y su posición en la estructura de canalización. Los requisitos de estructura de la canalización se detallan en cada sección para los siguientes tipos de componentes de canalización:
+ Referencia de campo para [Declaración de canalización](pipeline-requirements.md)
+ Referencia de campo para [Declaración de etapas](stage-requirements.md)
+ Referencia de campo para [Declaración de acciones](action-requirements.md)
+ Lista de [Proveedores de acciones válidos en CodePipeline](actions-valid-providers.md) por tipo de acción
+ Referencia de la para
+ Referencia de la para
+ Lista de enlaces para [Parámetros de configuración válidos para cada tipo de proveedor](structure-configuration-examples.md)
*Para obtener más información, consulta el [PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)objeto en la Guía de la CodePipeline API.*
El siguiente ejemplo de vista de consola de canalización muestra la canalización denominada new-github, las etapas denominadas y `Source` `manual``Build`, y las acciones de GitHub (mediante la GitHub aplicación), la aprobación manual y los proveedores de CodeBuild acciones.
![\[Un ejemplo de la vista de la canalización en la CodePipeline consola.\]](http://docs.aws.amazon.com/es_es/codepipeline/latest/userguide/images/pipeline-console-view.png)
El modo de edición de canalizaciones, visto en el diagrama de la consola, permite editar las anulaciones, desencadenadores y acciones de origen, tal y como se muestra en el siguiente ejemplo.
![\[Un ejemplo del modo de edición de canalizaciones en la CodePipeline consola.\]](http://docs.aws.amazon.com/es_es/codepipeline/latest/userguide/images/pipeline-console-view-edit.png)
**Topics**
+ [Declaración de canalización](pipeline-requirements.md)
+ [Declaración de etapas](stage-requirements.md)
+ [Declaración de acciones](action-requirements.md)
+ [Proveedores de acciones válidos en CodePipeline](actions-valid-providers.md)
+ [Configuración válida para el parámetro `PollForSourceChanges`](PollForSourceChanges-defaults.md)
+ [Artefactos de entrada y salida para cada tipo de acción](reference-action-artifacts.md)
+ [Parámetros de configuración válidos para cada tipo de proveedor](structure-configuration-examples.md)
# Declaración de canalización
La canalización y el nivel de metadatos de una canalización tienen una estructura básica que incluye los siguientes parámetros y sintaxis. El parámetro de canalización representa la estructura de las acciones y etapas que se van a realizar en la canalización.
Para obtener más información, consulta el [PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)objeto en la *Guía de la CodePipeline API*.
El siguiente ejemplo muestra la canalización y el nivel de metadatos de la estructura de la canalización tanto en JSON como en YAML para una canalización de 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`
El nombre de la canalización. El nombre de una canalización no se puede modificar al editarla o actualizarla.
**nota**
Si desea cambiar el nombre de una canalización existente, puede utilizar el comando `get-pipeline` de la CLI para crear un archivo JSON que incluya la estructura de la canalización. A continuación, puede utilizar el comando `create-pipeline` de la CLI para crear una canalización con esa estructura y asignarla un nombre nuevo.
## `roleArn`
El ARN de IAM para CodePipeline la función de servicio, como arn:aws:iam: :80398Example:role/ \$1Service\$1Role. CodePipeline
Para usar la consola a fin de ver el ARN del rol de servicio de la canalización en lugar de la estructura JSON, elija su canalización en la consola y, a continuación, seleccione **Configuración**. En la pestaña **General**, aparecerá el campo **ARN del rol de servicio**.
## `artifactStore` O `artifactStores`
El `artifactStore` campo contiene el tipo de depósito de artefactos y la ubicación de una canalización con todas las acciones en la misma región. AWS Si añades acciones en una región diferente a la de tu proceso, el `artifactStores` mapeo se utiliza para mostrar el depósito de artefactos de cada AWS región en la que se ejecutan las acciones. Al crear o editar una canalización, debe tener un bucket de artefactos en la región de la canalización, así como un bucket de artefactos por cada región en la que tiene previsto ejecutar una acción.
**nota**
En la estructura de la canalización, debe incluir `artifactStore` o `artifactStores` en su canalización, pero no puede usar ambos. Si crea una acción entre regiones en la canalización, debe utilizar `artifactStores`.
En el siguiente ejemplo, se muestra la estructura básica de una canalización con acciones entre regiones que utiliza el 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`
El tipo de ubicación del bucket de artefactos, especificado como Amazon S3.
### `location`
El nombre del bucket de Amazon S3 que se generó automáticamente la primera vez que creó una canalización con la consola, como codepipeline-us-east -2-1234567890, o cualquier bucket de Amazon S3 que aprovisione para este fin
## `stages`
Este parámetro contiene el nombre de cada etapa de la canalización. *Para obtener más información sobre los parámetros y la sintaxis a nivel de fase de la estructura de la canalización, consulte el [StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)objeto en la Guía de API. CodePipeline *
La estructura de la canalización para las etapas debe cumplir estos requisitos:
+ La canalización debe tener dos etapas como mínimo.
+ La primera fase de una canalización debe incluir al menos una acción de origen. Solo puede incluir acciones de origen.
+ La primera etapa de la canalización es la única que puede incluir acciones de origen.
+ Al menos una etapa de cada canalización debe contener una acción que no sea de origen.
+ Los nombres de las etapas de una canalización deben ser diferentes.
+ Los nombres de las etapas no se pueden editar en la CodePipeline consola. Si edita el nombre de una etapa con AWS CLI, y la etapa contiene una acción con uno o más parámetros secretos (como un OAuth token), el valor de esos parámetros secretos no se conserva. Tendrá que escribir manualmente el valor de los parámetros (que están enmascarados con cuatro asteriscos en el archivo JSON que devuelve la AWS CLI) e incluirlos en la estructura JSON.
**importante**
Las canalizaciones que estén inactivas durante más de 30 días tendrán deshabilitado el sondeo para la canalización. Para obtener más información, consulte [pollingDisabledAt](#metadata.pollingDisabledAt)la referencia sobre la estructura de la canalización. Consulte los pasos para migrar una canalización que usa sondeos para que use la detección de cambios basada en eventos en [Métodos de detección de cambios](change-detection-methods.md).
## `version`
El número de versión de una canalización se genera automáticamente y se actualiza cada vez que se actualiza la canalización.
## `executionMode`
Puede configurar el modo de ejecución de la canalización para poder especificar el comportamiento de la canalización para ejecuciones consecutivas, como poner en cola, reemplazar o ejecutar en modo paralelo. Para obtener más información, consulte [Configuración o cambio del modo de ejecución de una canalización](execution-modes.md).
**importante**
Para las canalizaciones en modo PARALELO, la reversión de etapas no está disponible. Del mismo modo, las condiciones de error con un tipo de resultado de reversión no se pueden agregar a una canalización en modo PARALELO.
## `pipelineType`
El tipo de canalización especifica la estructura y las características disponibles en la canalización, como en el caso de una canalización de tipo V2. Para obtener más información, consulte [Tipos de canalización](pipeline-types.md).
## `variables`
Las variables a nivel de canalización se definen cuando la canalización se crea y se resuelven en el tiempo de ejecución de la canalización. Para obtener más información, consulte [Referencia de variables](reference-variables.md). Para ver un tutorial con una variable a nivel de canalización que se transfiere en el momento de la ejecución de la canalización, consulte [Tutorial: Uso de variables a nivel de canalización](tutorials-pipeline-variables.md).
## `triggers`
Los desencadenadores permiten configurar la canalización para que se inicie con un tipo de evento concreto o filtrado, por ejemplo, cuando se detecta un cambio en una ramificación específica o en una solicitud de extracción. Los activadores se pueden configurar para las acciones de origen con conexiones que utilizan la `CodeStarSourceConnection` acción en CodePipeline, por ejemplo GitHub, Bitbucket y GitLab. Para obtener más información acerca de las acciones de origen que utilizan conexiones, consulte [Agregación de proveedores de origen de terceros a las canalizaciones mediante CodeConnections](pipelines-connections.md).
Para obtener más información y ejemplos detallados, consulte [Automatización del inicio de las canalizaciones mediante desencadenadores y filtrado](pipelines-triggers.md).
Para el filtrado, se admiten patrones de expresiones regulares en formato glob, tal y como se detalla en [Trabajar con patrones glob en la sintaxis](syntax-glob.md).
**nota**
Las acciones de origen CodeCommit y las de S3 requieren un recurso de detección de cambios configurado (una EventBridge regla) o utilizar la opción de sondear el repositorio en busca de cambios en la fuente. En el caso de las canalizaciones con una acción fuente de Bitbucket o GitHub Enterprise Server, no es necesario configurar un webhook ni utilizar el sondeo de forma predeterminada. GitHub La acción de conexiones administra la detección de cambios por usted.
**importante**
Las canalizaciones que estén inactivas durante más de 30 días tendrán deshabilitado el sondeo para la canalización. Para obtener más información, consulta la referencia sobre la [pollingDisabledAt](#metadata.pollingDisabledAt)estructura de canalizaciones. Consulte los pasos para migrar una canalización que usa sondeos para que use la detección de cambios basada en eventos en [Métodos de detección de cambios](change-detection-methods.md).
### Campos `gitConfiguration`
La configuración de Git para el desencadenador, incluidos los tipos de eventos y cualquier parámetro para filtrar por ramas, rutas de archivos, etiquetas o eventos de solicitud de extracción.
Los campos de la estructura JSON se definen de la siguiente manera:
+ `sourceActionName`: el nombre de la acción de origen de la canalización con la configuración de Git.
+ `push`: eventos de inserción con filtrado. Estos eventos utilizan una operación OR entre distintos filtros de inserción y una operación AND en los filtros.
+ `branches`: las ramificaciones se van a filtrar. Las ramificaciones utilizan una operación AND entre inclusiones y exclusiones.
+ `includes`: patrones para filtrar las ramificaciones que se incluirán. Incluye el uso de una operación OR.
+ `excludes`: patrones para filtrar las ramificaciones que se excluirán. Excluye el uso de una operación OR.
+ `filePaths`: los nombres de las rutas de archivo que se van a filtrar.
+ `includes`: patrones para filtrar las rutas de archivo que se incluirán. Incluye el uso de una operación OR.
+ `excludes`: patrones para filtrar las rutas de archivo que se excluirán. Excluye el uso de una operación OR.
+ `tags`: los nombres de las etiquetas que se van a filtrar.
+ `includes`: patrones para filtrar las etiquetas que se incluirán. Incluye el uso de una operación OR.
+ `excludes`: patrones para filtrar las etiquetas que se excluirán. Excluye el uso de una operación OR.
+ `pullRequest`: eventos de solicitud de extracción con filtrado de eventos de solicitud de extracción y filtros de solicitud de extracción.
+ `events`: filtra los eventos de solicitud de extracción que se abran, actualicen o cierren según se especifique.
+ `branches`: las ramificaciones se van a filtrar. Las ramificaciones utilizan una operación AND entre inclusiones y exclusiones.
+ `includes`: patrones para filtrar las ramificaciones que se incluirán. Incluye el uso de una operación OR.
+ `excludes`: patrones para filtrar las ramificaciones que se excluirán. Excluye el uso de una operación OR.
+ `filePaths`: los nombres de las rutas de archivo que se van a filtrar.
+ `includes`: patrones para filtrar las rutas de archivo que se incluirán. Incluye el uso de una operación OR.
+ `excludes`: patrones para filtrar las rutas de archivo que se excluirán. Excluye el uso de una operación OR.
El siguiente es un ejemplo de la configuración del desencadenador para los tipos de eventos de solicitud de inserción y extracción.
```
"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` del tipo de evento para inclusión y exclusión
El comportamiento de inclusión y exclusión de los niveles de los campos de configuración de Git para los tipos de eventos de **inserción** se muestra en la siguiente 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` del tipo de evento para inclusión y exclusión
El comportamiento de inclusión y exclusión de los niveles de los campos de configuración de Git para los tipos de eventos de **solicitud de extracción** se muestra en la siguiente 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`
Los campos de metadatos de la canalización son distintos de la estructura de la canalización y no se pueden editar. Al actualizar una canalización, la fecha del campo de metadatos `updated` cambia automáticamente.
### `pipelineArn`
El nombre de recurso de Amazon (ARN) de la canalización.
Para usar la consola a fin de ver el ARN de la canalización en lugar de la estructura JSON, elija su canalización en la consola y, a continuación, seleccione **Configuración**. En la pestaña **General**, aparecerá el campo **ARN de la canalización**.
### `created`
Fecha y hora en que se creó la canalización.
### `updated`
Fecha y hora en que se actualizó por última vez la canalización.
### `pollingDisabledAt`
La fecha y la hora en las que se deshabilitó el sondeo, en el caso de una canalización configurada para el sondeo con fines de detección de cambios.
Las canalizaciones que estén inactivas durante más de 30 días tendrán deshabilitado el sondeo para la canalización.
+ Si no se llevan a cabo ejecuciones en 30 días, se deshabilitará el sondeo en las canalizaciones inactivas.
+ Las canalizaciones que usen EventBridge CodeStar conexiones o webhooks no se verán afectadas.
+ Las canalizaciones activas no se verán afectadas.
Para obtener más información, consulta el `pollingDisabledAt` parámetro situado debajo del [PipelineMetadata](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineMetadata.html)objeto en la Guía de la * CodePipeline API*. Consulte los pasos para migrar una canalización que usa sondeos para que use la detección de cambios basada en eventos en [Métodos de detección de cambios](change-detection-methods.md).
# Declaración de etapas
El nivel de etapa de una canalización tiene una estructura básica que incluye los siguientes parámetros y sintaxis. Para obtener más información, consulta el [StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)objeto en la *Guía de la CodePipeline API*.
En el siguiente ejemplo se muestra el nivel de etapa de la estructura de canalización en JSON y YAML. El ejemplo muestra dos etapas denominadas `Source` y `Build`. El ejemplo contiene dos condiciones, una para `onSuccess` y otra 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`
El nombre de la etapa de .
## `actions`
El nivel de acción de una canalización tiene una estructura básica que incluye los siguientes parámetros y sintaxis. Para ver los parámetros y ejemplos, consulte [Declaración de acciones](action-requirements.md).
## `conditions`
Las condiciones contienen una o más reglas que están disponibles en una lista de reglas en CodePipeline. Si todas las reglas de una condición se realizan correctamente, se cumple la condición. Puede configurar las condiciones para que, cuando no se cumplan los criterios, se active el resultado especificado.
Es posible configurar los siguientes tipos de condiciones:
+ `beforeEntry`
+ `onFailure`
+ `onSuccess`
Para obtener más información y ejemplos, consulta [Configuración de las condiciones de una etapa](stage-conditions.md).
## `rules`
Cada condición tiene un conjunto de reglas, en el que las reglas se ordenan y se evalúan juntas. Por lo tanto, si una regla falla en la condición, la condición también fallará. Puede anular las condiciones de la regla en el tiempo de ejecución de la canalización.
Las reglas disponibles se proporcionan en la Referencia de reglas. Para obtener más información, consulte la Referencia de la estructura de reglas en [Referencia de estructura de las reglas](rule-reference.md).
# Declaración de acciones
El nivel de acción de una canalización tiene una estructura básica que incluye los siguientes parámetros y sintaxis. Para obtener más información, consulta el [ActionDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionDeclaration.html)objeto en la *Guía de la CodePipeline API*.
En el siguiente ejemplo se muestra el nivel de acción de la estructura de canalización tanto en JSON como en 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 obtener una lista de ejemplos de detalles de `configuration` apropiados para el tipo de proveedor, consulte [Parámetros de configuración válidos para cada tipo de proveedor](structure-configuration-examples.md).
La estructura de la acción debe cumplir estos requisitos:
+ Los nombres de las acciones de una etapa deben ser diferentes.
+ Se requiere una acción de origen para cada canalización.
+ Las acciones de origen que no utilizan una conexión se pueden configurar para que detecten los cambios, o bien para desactivar la opción de detección de cambios. Consulte [Métodos de detección de cambios](change-detection-methods.md).
+ Esto es así para todas las acciones, ya estén en la misma etapa o en etapas posteriores, pero el artefacto de entrada no debe ser necesariamente la siguiente acción en de una secuencia estricta cuyo origen es la acción que proporcionó el artefacto de salida. Las acciones en paralelo pueden declarar distintos paquetes de artefactos de salida que, a su vez, consumen las siguientes y distintas acciones.
+ Cuando se utiliza un bucket de Amazon S3 como ubicación de implementación, también se especifica una clave de objeto. Una clave de objeto puede ser un nombre de archivo (objeto) o una combinación de un prefijo (ruta de carpeta) y el nombre del archivo. Puede utilizar variables para especificar el nombre de la ubicación que desea que utilice la canalización. Las acciones de implementación de Amazon S3 admiten el uso de las siguientes variables en las claves de objeto de Amazon S3.
**Uso de variables en Amazon S3**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/codepipeline/latest/userguide/action-requirements.html)
## `name`
El nombre de la acción.
## `region`
Para las acciones en las que el proveedor es un Servicio de AWS, el Región de AWS del recurso.
Las acciones entre regiones utilizan el campo `Region` para designar la Región de AWS en la que se van a crear las acciones. Los AWS recursos creados para esta acción deben crearse en la misma región proporcionada en el `region` campo. No puede crear acciones entre regiones para los siguientes tipos de acciones:
+ Acciones de código fuente
+ Acciones de proveedores de terceros
+ Acciones de proveedores personalizados
## `roleArn`
El ARN del rol de servicio de IAM que realizará la acción declarada. Esto se asume a través del roleArn que se especifica a nivel de la canalización.
## `namespace`
Las acciones se pueden configurar con variables. Utilice el campo `namespace` para establecer el espacio de nombres y la información de variables para las variables de ejecución. Para obtener información de referencia acerca de las variables de ejecución y las variables de salida de acción, consulte [Referencia de variables](reference-variables.md).
**nota**
Para Amazon ECR, Amazon S3 o CodeCommit Sources, también puedes crear una anulación de fuente mediante la entrada input transform para usar la entrada `revisionValue` in EventBridge para tu evento de canalización, donde `revisionValue` se deriva de la variable de evento de origen para tu clave de objeto, confirmación o ID de imagen. Para obtener más información, consulte el paso opcional para la entrada de transformación de entrada, que se incluye en los procedimientos de [Acciones y recursos fuente de Amazon ECR EventBridge](create-cwe-ecr-source.md), [Conexión a acciones de origen de Amazon S3 con un origen habilitado para eventos](create-S3-source-events.md) o [CodeCommit acciones de origen y EventBridge](triggering.md).
## `actionTypeId`
El ID del tipo de acción se identifica como una combinación de los cuatro campos siguientes.
### `category`
El tipo de acción o paso de la canalización, como una acción de origen. Cada tipo de acción tiene un conjunto específico de proveedores de acción válidos. Para obtener una lista de los proveedores válidos según el tipo de acción, consulte la [Referencia de la estructura de acciones](action-reference.md).
Estas son las `actionTypeId` categorías (tipos de acciones) válidas para: CodePipeline
+ `Source`
+ `Build`
+ `Approval`
+ `Deploy`
+ `Test`
+ `Invoke`
+ `Compute`
### `owner`
La única cadena de versión válida para todos los tipos de acción admitidos actualmente es `AWS`, `ThirdParty` o `Custom`. Para ver la cadena de propietario válida para una acción específica, consulte la [Referencia de la estructura de acciones](action-reference.md).
Para obtener más información, consulte la [Referencia de la API de CodePipeline ](https://docs.aws.amazon.com/codepipeline/latest/APIReference).
### `version`
La versión de la acción.
### `provider`
El proveedor de acciones, como CodeBuild.
+ Los tipos de proveedor válidos para una categoría de acción dependen de la categoría. Por ejemplo, para una categoría de acción de origen, un tipo de proveedor válido sería `S3`, `CodeStarSourceConnection`, `CodeCommit` o `Amazon ECR`. Este ejemplo muestra la estructura de una acción de código fuente con `S3` como proveedor:
```
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"},
```
## `InputArtifacts`
Este campo contiene la estructura de artefactos de entrada, si es compatible con la categoría de acción. El artefacto de entrada de una acción debe coincidir exactamente con el artefacto de salida declarado en una acción anterior. Por ejemplo, si una acción anterior incluye la siguiente declaración:
```
"outputArtifacts": [
{
"MyApp"
}
],
```
y no hay otros artefactos de salida, el artefacto de entrada de una acción posterior debe ser:
```
"inputArtifacts": [
{
"MyApp"
}
],
```
Por ejemplo, una acción de origen no puede tener artefactos de entrada porque es la primera acción de la canalización. Sin embargo, una acción de origen siempre tendrá artefactos de salida que se procesen mediante la siguiente acción. Los artefactos de salida de una acción de origen son los archivos de la aplicación del repositorio de origen, comprimidos y proporcionados a través del depósito de artefactos, que se procesan mediante la siguiente acción, por ejemplo, una CodeBuild acción que actúa sobre los archivos de la aplicación con comandos de compilación.
Las acciones de implementación son un claro ejemplo de acciones que no pueden tener artefactos de salida, ya que estas acciones suelen ser la última acción de una canalización.
### `name`
El nombre de artefacto para los artefactos de entrada de la acción.
## `outputArtifacts`
Los nombres de los artefactos de salida deben ser diferentes en una canalización. Por ejemplo, una canalización puede incluir una acción con un artefacto de salida que se llame `"MyApp"` y otra acción con un artefacto de salida llamado `"MyBuiltApp"`. Sin embargo, una canalización no puede incluir dos acciones que tengan un artefacto de salida denominado `"MyApp"`.
Este campo contiene la estructura del artefacto de salida, si es compatible con la categoría de acción. El artefacto de salida de una acción debe coincidir exactamente con el artefacto de salida declarado en una acción anterior. Por ejemplo, si una acción anterior incluye la siguiente declaración:
```
"outputArtifacts": [
{
"MyApp"
}
],
```
y no hay otros artefactos de salida, el artefacto de entrada de una acción posterior debe ser:
```
"inputArtifacts": [
{
"MyApp"
}
],
```
Por ejemplo, una acción de origen no puede tener artefactos de entrada porque es la primera acción de la canalización. Sin embargo, una acción de origen siempre tendrá artefactos de salida que se procesen mediante la siguiente acción. Los artefactos de salida de una acción de origen son los archivos de aplicación del repositorio de origen, comprimidos y proporcionados a través del depósito de artefactos, que se procesan mediante la siguiente acción, como una CodeBuild acción que actúa en los archivos de la aplicación con comandos de compilación.
Las acciones de implementación son un claro ejemplo de acciones que no pueden tener artefactos de salida, ya que estas acciones suelen ser la última acción de una canalización.
### `name`
El nombre de artefacto para los artefactos de salida de la acción.
## `configuration` (según el proveedor de acción)
La configuración de la acción contiene detalles y parámetros adecuados para el tipo de proveedor. En la siguiente sección, los parámetros de configuración de la acción de ejemplo son específicos de la acción de origen de S3.
La configuración de la acción y los límites de los input/output artefactos pueden variar según el proveedor de la acción. Para ver una lista de ejemplos de configuración de acciones según el proveedor de acción, consulte [Referencia de la estructura de acciones](action-reference.md) y la tabla en [Parámetros de configuración válidos para cada tipo de proveedor](structure-configuration-examples.md). La tabla proporciona un enlace a la referencia de acción para cada tipo de proveedor, en la que se enumeran los parámetros de configuración de cada acción en detalle. Para ver una tabla con los límites de artefactos de entrada y salida para cada proveedor de acción, consulte [Artefactos de entrada y salida para cada tipo de acción](reference-action-artifacts.md).
Al trabajar con acciones se deben tener en cuenta los siguientes aspectos:
+ Las acciones de origen no tienen artefactos de entrada, y las acciones de implementación no tienen artefactos de salida.
+ En el caso de los proveedores de acciones de origen que no utilizan ninguna conexión, como S3, debe usar el parámetro `PollForSourceChanges` para especificar si desea que la canalización se inicie automáticamente cuando se detecte algún cambio. Consulte [Configuración válida para el parámetro `PollForSourceChanges`](PollForSourceChanges-defaults.md).
+ Para configurar la detección de cambios automática a fin de iniciar la canalización o deshabilitar la detección de cambios, consulte [Acciones de origen y métodos de detección de cambios](change-detection-methods.md).
+ Para configurar los desencadenadores con filtrado, utilice la acción de origen para las conexiones y, a continuación, consulte [Automatización del inicio de las canalizaciones mediante desencadenadores y filtrado](pipelines-triggers.md).
+ Para ver las variables de salida de cada acción, consulte [Referencia de variables](reference-variables.md).
**nota**
Para Amazon ECR, Amazon S3 o CodeCommit Sources, también puedes crear una anulación de fuente mediante la entrada input transform para usar la entrada `revisionValue` in EventBridge para tu evento de canalización, donde `revisionValue` se deriva de la variable de evento de origen para tu clave de objeto, confirmación o ID de imagen. Para obtener más información, consulte el paso opcional para la entrada de transformación de entrada, que se incluye en los procedimientos de [Acciones y recursos fuente de Amazon ECR EventBridge](create-cwe-ecr-source.md), [Conexión a acciones de origen de Amazon S3 con un origen habilitado para eventos](create-S3-source-events.md) o [CodeCommit acciones de origen y EventBridge](triggering.md).
**importante**
Las canalizaciones que estén inactivas durante más de 30 días tendrán deshabilitado el sondeo para la canalización. Para obtener más información, consulte la referencia sobre [pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)la estructura de la canalización. Consulte los pasos para migrar una canalización que usa sondeos para que use la detección de cambios basada en eventos en [Métodos de detección de cambios](change-detection-methods.md).
**nota**
Las acciones de origen CodeCommit y de S3 requieren un recurso de detección de cambios configurado (una EventBridge regla) o utilizar la opción de sondear el repositorio en busca de cambios de origen. En el caso de las canalizaciones con una acción fuente de Bitbucket o GitHub Enterprise Server, no es necesario configurar un webhook ni utilizar el sondeo de forma predeterminada. GitHub La acción de conexiones administra la detección de cambios por usted.
## `runOrder`
Un entero positivo que indica el orden de ejecución de la acción en la etapa. Las acciones en paralelo de la etapa se muestran con el mismo número entero. Por ejemplo, dos acciones con un orden de ejecución de dos se ejecutarán en paralelo después de que se ejecute la primera acción de la etapa.
El valor predeterminado `runOrder` para una acción es 1. El valor deber ser un entero positivo (número natural). No se pueden usar fracciones, decimales, números negativos ni el número cero Para especificar una secuencia de acciones en serie, utilice el número más pequeño para la primera acción y números mayores para las acciones subsiguientes. Para especificar acciones en paralelo, utilice el mismo entero para cada acción que quiera ejecutar en paralelo. En la consola, puede especificar una secuencia en serie para una acción seleccionando **Añadir grupo de acciones** en el nivel de la etapa en la que desea que se ejecute, o puede especificar una secuencia paralela seleccionando **Añadir acción**. *Grupo de acciones* hace referencia al orden de ejecución de una o más acciones en el mismo nivel.
Por ejemplo, para que tres acciones se ejecuten en secuencia en una etapa, asigne a la primera acción el valor `runOrder` 1, a la segunda acción el valor `runOrder` 2 y a la tercera el valor `runOrder` 3. Si quiere que la segunda y tercera acciones se ejecuten en paralelo, asigne a la primera acción el valor `runOrder` 1 y a la segunda y tercera el valor `runOrder` 2.
**nota**
La numeración de las acciones en serie no tiene que seguir un orden estricto. Por ejemplo, si tiene tres acciones en una secuencia y decide eliminar la segunda, no tiene que reasignar el número del valor `runOrder` de la tercera. Como el valor `runOrder` de dicha acción (3) es mayor que el valor `runOrder` de la primera acción (1), se ejecuta en serie después de la primera acción de la etapa.
# Proveedores de acciones válidos en CodePipeline
El formato de la estructura de la canalización se utiliza para compilar acciones y etapas en una canalización. Un tipo de acción consta de una categoría de acción y un tipo de proveedor.
Cada categoría de acción tiene una lista válida de proveedores de acción. Para hacer referencia a los proveedores de acción válidos para cada categoría de acción, consulte la [Referencia de la estructura de acciones](action-reference.md).
Cada categoría de acción tiene un conjunto de proveedores designado. Cada proveedor de acción, como Amazon S3, tiene un nombre de proveedor, por ejemplo `S3`, que debe utilizarse en el campo `Provider` en la categoría de acción de la estructura de la canalización.
Hay tres valores válidos para el campo `Owner` en la sección de categoría de acción de la estructura de canalización: `AWS`, `ThirdParty` y `Custom`.
Para encontrar el nombre del proveedor y la información del propietario de su proveedor de acción, consulte la [Referencia de la estructura de acciones](action-reference.md) o [Artefactos de entrada y salida para cada tipo de acción](reference-action-artifacts.md).
En esta tabla, se muestran los proveedores válidos para cada tipo de acción.
**nota**
Para ver las acciones de Bitbucket o GitHub Enterprise Server, consulta el tema de referencia de las [CodeStarSourceConnection para Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com y acciones GitLab autogestionadas](action-reference-CodestarConnectionSource.md) acciones. GitHub
**Proveedores de acciones válidos por tipo de acción**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/codepipeline/latest/userguide/actions-valid-providers.html)
Algunos tipos de acciones solo CodePipeline están disponibles en determinadas AWS regiones. Es posible que un tipo de acción esté disponible en una AWS región, pero no AWS haya un proveedor para ese tipo de acción.
Para obtener más información sobre cada uno de los proveedores de acciones, consulte [Integraciones con tipos de CodePipeline acciones](integrations-action-type.md).
# Configuración válida para el parámetro `PollForSourceChanges`
El valor predeterminado del parámetro `PollForSourceChanges` lo determina el método utilizado para crear la canalización, tal y como se describe en la tabla siguiente. En muchos casos, el valor predeterminado del parámetro `PollForSourceChanges` es true y se debe deshabilitar.
Si el valor predeterminado del parámetro `PollForSourceChanges` es true, haga lo siguiente:
+ Agregue el parámetro `PollForSourceChanges` al archivo JSON o la plantilla de CloudFormation .
+ Cree recursos de detección de cambios (regla de CloudWatch eventos, según corresponda).
+ Establecer el parámetro `PollForSourceChanges` en false.
**nota**
Si creas una regla de CloudWatch eventos o un webhook, debes establecer el parámetro en false para evitar que se active la canalización más de una vez.
El parámetro `PollForSourceChanges` no se utiliza para las acciones de origen de Amazon ECR.
+
**Valores predeterminados del parámetro `PollForSourceChanges`**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/codepipeline/latest/userguide/PollForSourceChanges-defaults.html)
# Artefactos de entrada y salida para cada tipo de acción
Según el proveedor y el tipo de acción, puede tener la cantidad de artefactos de entrada y salida que se indican a continuación.
**Restricciones de artefactos por tipo de acción**
| Propietario | Tipo de acción | Proveedor | Número válido de artefactos de entrada | Número válido de artefactos de salida |
| --- | --- | --- | --- | --- |
| AWS | origen | S3 | 0 | 1 |
| AWS | origen | CodeCommit | 0 | 1 |
| AWS | origen | ECR | 0 | 1 |
| ThirdParty | origen | CodeStarSourceConnection | 0 | 1 |
| AWS | Build | CodeBuild | De 1 a 5 | De 0 a 5 |
| AWS | Test | CodeBuild | De 1 a 5 | De 0 a 5 |
| AWS | Test | DeviceFarm | 1 | 0 |
| AWS | Aprobación | ThirdParty | 0 | 0 |
| AWS | Implementación | S3 | 1 | 0 |
| AWS | Implementación | CloudFormation | De 0 a 10 | De 0 a 1 |
| AWS | Implementación | CodeDeploy | 1 | 0 |
| AWS | Implementación | ElasticBeanstalk | 1 | 0 |
| AWS | Implementación | OpsWorks | 1 | 0 |
| AWS | Implementación | ECS | 1 | 0 |
| AWS | Implementación | ServiceCatalog | 1 | 0 |
| AWS | Invocación | Lambda | De 0 a 5 | De 0 a 5 |
| ThirdParty | Implementación | AlexaSkillsKit | De 1 a 2 | 0 |
| Custom | Build | Jenkins | De 0 a 5 | De 0 a 5 |
| Custom | Test | Jenkins | De 0 a 5 | De 0 a 5 |
| Custom | Cualquier categoría compatible | Según se indique en la acción personalizada | De 0 a 5 | De 0 a 5 |
# Parámetros de configuración válidos para cada tipo de proveedor
En esta sección, se incluyen los parámetros de la sección `configuration` válidos para cada proveedor de acción.
Cada acción debe tener una configuración de acción válida que depende del tipo de proveedor de dicha acción. En la tabla siguiente se incluyen los elementos de configuración de acción necesarios para cada tipo de proveedor válido:
**Propiedades de configuración de la acción de los tipos de proveedores**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/codepipeline/latest/userguide/structure-configuration-examples.html)
En el ejemplo siguiente, se muestra una configuración válida para una acción de implementación que utiliza Alexa Skills Kit:
```
"configuration": {
"ClientId": "amzn1.application-oa2-client.aadEXAMPLE",
"ClientSecret": "****",
"RefreshToken": "****",
"SkillId": "amzn1.ask.skill.22649d8f-0451-4b4b-9ed9-bfb6cEXAMPLE"
}
```
En el siguiente ejemplo, se muestra una configuración válida para una aprobación manual:
```
"configuration": {
"CustomData": "Comments on the manual approval",
"ExternalEntityLink": "http://my-url.com",
"NotificationArn": "arn:aws:sns:us-west-2:12345EXAMPLE:Notification"
}
```