Referencia de estructura de canalización de CodePipeline - AWS CodePipeline

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.

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.

Proveedores de acciones válidos por tipo de acción
Categoría de la acción Proveedores válidos de la acción Referencia de la acción
Origen Amazon S3 Acción de código fuente de Amazon S3
Amazon ECR Amazon ECR
CodeCommit CodeCommit
CodestarSourceConnection (para acciones Bitbucket Cloud, GitHub, GitHub Enterprise Server y Gitlab.com) CodeStarSourceConnection para Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com y acciones GitLab autogestionadas
Compilación CodeBuild AWS CodeBuild
Custom CloudBees Número de artefactos de entrada y salida para cada tipo de acción
Custom Jenkins Número de artefactos de entrada y salida para cada tipo de acción
Custom TeamCity Número de artefactos de entrada y salida para cada tipo de acción
Pruebas CodeBuild AWS CodeBuild
AWS Device Farm Número de artefactos de entrada y salida para cada tipo de acción
ThirdParty GhostInspector Número de artefactos de entrada y salida para cada tipo de acción
Custom Jenkins Número de artefactos de entrada y salida para cada tipo de acción
ThirdParty Micro Focus StormRunner Load Número de artefactos de entrada y salida para cada tipo de acción
ThirdParty Nouvola Número de artefactos de entrada y salida para cada tipo de acción
Implementación Amazon S3 Acción de implementación de Amazon S3
AWS CloudFormation AWS CloudFormation
AWS CloudFormation StackSets (incluye las acciones CloudFormationStackSet y CloudFormationStackInstances) AWS CloudFormation StackSets
CodeDeploy Número de artefactos de entrada y salida para cada tipo de acción
Amazon ECS Número de artefactos de entrada y salida para cada tipo de acción
Amazon ECS (Blue/Green) (esta es la acción CodeDeployToECS) Número de artefactos de entrada y salida para cada tipo de acción
Elastic Beanstalk Número de artefactos de entrada y salida para cada tipo de acción
AWS AppConfig AWS AppConfig
AWS OpsWorks Número de artefactos de entrada y salida para cada tipo de acción
Service Catalog Número de artefactos de entrada y salida para cada tipo de acción
Amazon Alexa Número de artefactos de entrada y salida para cada tipo de acción
Custom XebiaLabs Número de artefactos de entrada y salida para cada tipo de acción
Aprobación Manual Número de artefactos de entrada y salida para cada tipo de acción
Invoke AWS Lambda AWS Lambda
AWS Step Functions AWS Step Functions

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 de artifactStores 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 comando create-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 campo region. 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 o Custom. 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 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.

  • 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
    Variable 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 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"},
  • 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
    Nombre 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

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 en true
    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 en true
    "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 en true
    "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.jsondistinto:

"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" }