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.
Referencia de estructura de canalización de CodePipeline
De forma predeterminada, las canalizaciones que cree correctamente en AWS CodePipeline tienen una estructura válida. No obstante, si crea o modifica manualmente un archivo JSON para crear o actualizar una canalización desde la AWS CLI, podría crear una estructura no válida sin darse cuenta. 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, que se aplican a todas las canalizaciones.
Temas
Proveedores y tipos 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.
A continuación se indican las categorías de acciones válidas en CodePipeline:
-
Origen
-
Compilación
-
Pruebas
-
Implementación
-
Aprobación
-
Invoke
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 Referencia de la estructura de acciones o Número de artefactos de entrada y salida para cada tipo de acción.
En esta tabla, se muestran los proveedores válidos para cada tipo de acción.
nota
Para ver las acciones de Bitbucket Cloud, GitHub, GitHub Enterprise Server o Gitlab.com, consulta el tema de referencia de acciones CodeStarSourceConnection para Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com y acciones GitLab autogestionadas.
Algunos tipos de acciones de AWS están disponibles únicamente en regiones de específicas. Es posible que un tipo de acción esté disponible en una región de AWS, pero que no haya un proveedor de AWS disponible 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.
En las secciones siguientes, se proporcionan ejemplos con información sobre los proveedores y las propiedades de configuración para cada tipo de acción.
Requisitos de la estructura de las canalizaciones y las etapas de CodePipeline
Esta es la estructura básica de una canalización de dos etapas:
{ "roleArn": "
An IAM ARN for a service role, such as arn:aws:iam::80398EXAMPLE:role/CodePipeline_Service_Role
", "stages": [ { "name": "SourceStageName
", "actions": [ ... See Requisitos de la estructura de las acciones de CodePipeline ... ] }, { "name": "NextStageName
", "actions": [ ... See Requisitos de la estructura de las acciones de CodePipeline ... ] } ], "artifactStore": { "type": "S3", "location": "The name of the Amazon S3 bucket automatically generated for you the first time you create a pipeline using the console, such as codepipeline-us-east-2-1234567890, or any Amazon S3 bucket you provision for this purpose
" }, "name": "YourPipelineName
", "version": 1 }
La estructura de la canalización 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 pueden editarse en la consola de CodePipeline. Si edita el nombre de una etapa mediante el uso de AWS CLI y la etapa incluye una acción con uno o más parámetros secretos (como, por ejemplo, un token de OAuth), no se conservará el valor de dichos parámetros. 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.
-
El campo
artifactStore
contiene el tipo de bucket de artefactos y la ubicación de una canalización con todas las acciones en la misma región de AWS. Si añade acciones en una región diferente a la de la canalización, se utiliza la asignación deartifactStores
para obtener una lista de los buckets de artefactos de cada región de AWS donde 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.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 codepipeline-us-east-1-1234567890
" }, "us-west-2": { "type": "S3", "location": "S3 artifact bucket name, such as codepipeline-us-west-2-1234567890
" } }, "stages": [ { ... -
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. -
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 comandocreate-pipeline
de la CLI para crear una canalización con esa estructura y asignarla un nombre nuevo.
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.
Requisitos de la estructura de las acciones de CodePipeline
Las acciones tienen esta estructura general:
[ { "inputArtifacts": [
An input artifact structure, if supported for the action category
], "name": "ActionName
", "region": "Region
", "namespace": "source_namespace", "actionTypeId": { "category": "An action category", "owner": "AWS", "version": "1" "provider": "A provider type for the action category
", }, "outputArtifacts": [An output artifact structure, if supported for the action category
], "configuration": {Configuration details appropriate to the provider type
}, "runOrder":A positive integer that indicates the run order within the stage
, } ]
Para obtener una lista de ejemplos de detalles de configuration
apropiados para el tipo de proveedor, consulte Detalles de configuración por tipo de proveedor.
La estructura de la acción debe cumplir estos requisitos:
-
Los nombres de las acciones de una etapa deben ser diferentes.
-
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" } ],
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.
-
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"
. -
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 recursos de AWS creados para esta acción deben crearse en la misma región que se proporciona en el camporegion
. 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
-
-
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 Variables. -
La única cadena de versión válida para todos los tipos de acción admitidos actualmente es
AWS
,ThirdParty
oCustom
. Para obtener más información, consulte la CodePipeline API Reference. -
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 valorrunOrder
2 y a la tercera el valorrunOrder
3. Si quiere que la segunda y tercera acciones se ejecuten en paralelo, asigne a la primera acción el valorrunOrder
1 y a la segunda y tercera el valorrunOrder
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 valorrunOrder
de dicha acción (3) es mayor que el valorrunOrder
de la primera acción (1), se ejecuta en serie después de la primera acción de la etapa. -
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 S3Variable Ejemplo de entrada de la consola Output datetime js-application/{datetime}.zip Marca temporal UTC con este formato: <AAAA>-<MM>-<DD>_<HH>-<MM>-<SS> Ejemplo:
js-application/2019-01-10_07-39-57.zip
uuid js-application/{uuid}.zip El UUID es un identificador único global diferente de cualquier otro identificador. El UUID tiene este formato (todos los dígitos en formato hexadecimal): <8 dígitos>-<4 dígitos>-<4 dígitos>-<4 dígitos>-<12 dígitos> Ejemplo:
js-application/54a60075-b96a-4bf3-9013-db3a9EXAMPLE.zip
-
Estas son las categorías de
actionTypeId
válidas para CodePipeline:-
Source
-
Build
-
Approval
-
Deploy
-
Test
-
Invoke
Aquí se proporcionan algunos tipos de proveedores y opciones de configuración.
-
-
Los tipos de proveedor válidos para una categoría de acción dependen de la categoría. Por ejemplo, para un tipo de acción de código fuente, un tipo de proveedor válido sería
S3
,GitHub
,CodeCommit
oAmazon ECR
. Este ejemplo muestra la estructura de una acción de código fuente conS3
como proveedor:"actionTypeId": { "category": "Source", "owner": "AWS", "version": "1", "provider": "S3"},
-
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 proveedoresNombre del proveedor Nombre del proveedor del tipo de acción Propiedades de configuración ¿Es necesaria la propiedad? Amazon S3 (proveedor de acciones de implementación) Para obtener más información, incluidos ejemplos relacionados con los parámetros de acción de implementación de Amazon S3, consulte Acción de implementación de Amazon S3. Amazon S3 (proveedor de acciones de fuente) Para obtener más información, incluidos ejemplos relacionados con los parámetros de acción de fuente de Amazon S3, consulte Acción de código fuente de Amazon S3. Amazon ECR Para obtener más información, incluidos ejemplos relacionados con los parámetros de Amazon ECR, consulte Amazon ECR. CodeCommit Para obtener más información, incluidos ejemplos relacionados con los parámetros de CodeCommit, consulte CodeCommit. GitHub Para obtener más información, incluidos ejemplos relacionados con los parámetros de GitHub, consulte GitHub versión 1, fuente, estructura de acciones (referencia). AWS CloudFormation Para obtener más información, incluidos ejemplos relacionados con los parámetros AWS CloudFormation, consulte AWS CloudFormation. CodeBuild Para ver más descripciones y ejemplos relacionados con los parámetros de CodeBuild, consulte AWS CodeBuild. CodeDeploy Para ver más descripciones y ejemplos relacionados con los parámetros de CodeDeploy, consulte AWS CodeDeploy. AWS Device Farm Para ver más descripciones y ejemplos relacionados con los parámetros AWS Device Farm, consulte AWS Device Farm. AWS Elastic Beanstalk ElasticBeanstalk
ApplicationName
Obligatorio EnvironmentName
Obligatorio AWS Lambda Para obtener más información, incluidos ejemplos relacionados con los parámetros AWS Lambda, consulte AWS Lambda. AWS OpsWorks Stacks OpsWorks
Stack
Obligatorio Layer
Opcional App
Obligatorio Amazon ECS Para ver más descripciones y ejemplos relacionados con los parámetros de Amazon ECS, consulte Amazon Elastic Container Service. Amazon ECS and CodeDeploy(azul/verde) Para ver más descripciones y ejemplos relacionados con los parámetros de Amazon ECS y CodeDeploy azul/verde, consulte Amazon Elastic Container Service y CodeDeploy azul-verde. Service Catalog ServiceCatalog
TemplateFilePath
Obligatorio ProductVersionName
Obligatorio ProductType
Obligatorio ProductVersionDescription
Opcional ProductId
Obligatorio Alexa Skills Kit AlexaSkillsKit
ClientId
Obligatorio ClientSecret
Obligatorio RefreshToken
Obligatorio SkillId
Obligatorio Jenkins El nombre de la acción que ha proporcionado en CodePipeline Plugin for Jenkins (por ejemplo, MyJenkinsProviderName
)ProjectName
Obligatorio Aprobación manual Manual
CustomData
Opcional ExternalEntityLink
Opcional NotificationArn
Opcional
Temas
Número de artefactos de entrada y salida para cada tipo de acción
Según el tipo de acción, puede tener la cantidad de artefactos de entrada y de 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 | Amazon S3 | 0 | 1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Origen | CodeCommit | 0 | 1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Origen | Amazon ECR | 0 | 1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ThirdParty |
Origen | GitHub | 0 | 1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Compilación | CodeBuild | De 1 a 5 | De 0 a 5 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Pruebas | CodeBuild | De 1 a 5 | De 0 a 5 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Pruebas | AWS Device Farm | 1 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Aprobación | Manual | 0 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Implementación | Amazon S3 | 1 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Implementación | AWS CloudFormation | De 0 a 10 | De 0 a 1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Implementación | CodeDeploy | 1 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Implementación | AWS Elastic Beanstalk | 1 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Implementación | AWS OpsWorks Stacks | 1 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Implementación | Amazon ECS | 1 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Implementación | Service Catalog | 1 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS |
Invoke | AWS Lambda | De 0 a 5 | De 0 a 5 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ThirdParty |
Implementación | Alexa Skills Kit | De 1 a 2 | 0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Custom |
Compilación | Jenkins | De 0 a 5 | De 0 a 5 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Custom |
Pruebas | 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 |
Configuración predeterminada del 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 AWS CloudFormation. -
Cree recursos de detección de cambios (regla de Eventos de CloudWatch, según corresponda).
-
Establecer el parámetro
PollForSourceChanges
en false.nota
Si crea una regla de CloudWatch Events o un webhook, debe establecer el parámetro en false para evitar desencadenar la canalización más de una vez.
El parámetro
PollForSourceChanges
no se utiliza para las acciones de código fuente de Amazon ECR.
-
Valores predeterminados del parámetro PollForSourceChanges
Origen Método de creación Ejemplo de salida de la estructura JSON de "configuration" CodeCommit La canalización se crea con la consola (y los recursos de detección de cambios los crea la consola). El parámetro se muestra en la salida de la estructura de la canalización y tiene el valor predeterminado false
.BranchName": "main", "PollForSourceChanges": "false", "RepositoryName": "my-repo"
La canalización se crea con la CLI o con AWS CloudFormation y el parámetro PollForSourceChanges
no aparece en la salida JSON, pero se establece entrue
.²BranchName": "main", "RepositoryName": "my-repo"
Amazon S3 La canalización se crea con la consola (y los recursos de detección de cambios los crea la consola). El parámetro se muestra en la salida de la estructura de la canalización y tiene el valor predeterminado false
."S3Bucket": "my-bucket", "S3ObjectKey": "object.zip", "PollForSourceChanges": "false"
La canalización se crea con la CLI o con AWS CloudFormation y el parámetro PollForSourceChanges
no aparece en la salida JSON, pero se establece entrue
.²"S3Bucket": "my-bucket", "S3ObjectKey": "object.zip"
GitHub La canalización se crea con la consola (y los recursos de detección de cambios los crea la consola). El parámetro se muestra en la salida de la estructura de la canalización y tiene el valor predeterminado false
."Owner": "
MyGitHubAccountName
", "Repo": "MyGitHubRepositoryName
" "PollForSourceChanges": "false", "Branch": "main
" "OAuthToken": "****
"La canalización se crea con la CLI o con AWS CloudFormation y el parámetro PollForSourceChanges
no aparece en la salida JSON, pero se establece entrue
.²"Owner": "
MyGitHubAccountName
", "Repo": "MyGitHubRepositoryName
", "Branch": "main
", "OAuthToken": "****
"² Si se ha añadido
PollForSourceChanges
en algún momento a la estructura JSON o a la plantilla de AWS CloudFormation, se muestra como se indica a continuación:"PollForSourceChanges": "true",
Para obtener más información sobre los recursos de detección de cambios que se aplican a cada proveedor de código fuente, consulte Métodos de detección de cambios.
Detalles de configuración por 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.
En el ejemplo siguiente se muestra una configuración válida para una acción de implementación que utiliza Service Catalog, para una canalización creada en la consola sin un archivo de configuración distinto:
"configuration": { "TemplateFilePath": "S3_template.json", "ProductVersionName": "devops S3 v2", "ProductType": "CLOUD_FORMATION_TEMPLATE", "ProductVersionDescription": "Product version description", "ProductId": "prod-example123456" }
En el ejemplo siguiente se muestra una configuración válida para una acción de implementación que utiliza Service Catalog, para una canalización creada en la consola con un archivo de configuración de sample_config.json
distinto:
"configuration": { "ConfigurationFilePath": "sample_config.json", "ProductId": "prod-example123456" }
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" }