CodePipeline referencia de estructura de tubería - 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.

CodePipeline referencia de estructura de tubería

De forma predeterminada, cualquier canalización en la 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, que se aplican a todas las canalizaciones.

Tipos de acciones y proveedores 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.

Las siguientes son las categorías de acciones válidas en CodePipeline:

  • origen

  • Compilación

  • Prueba

  • Implementación

  • Aprobación

  • Invocación

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 CodeStarSourceConnection para Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com y acciones GitLab autogestionadas tema de referencia de acciones.

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 origen de Amazon S3
Amazon ECR Amazon ECR
CodeCommit CodeCommit
CodeStarSourceConnection (para las acciones de Bitbucket Cloud GitHub, GitHub Enterprise Server o GitLab .com) CodeStarSourceConnection para Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com y acciones GitLab autogestionadas
Compilación CodeBuild AWS CodeBuild
Personalizado 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
Personalizado TeamCity Número de artefactos de entrada y salida para cada tipo de acción
Prueba 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 yCloudFormationStackInstances) 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
Personalizado 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
Invocación AWS Lambda AWS Lambda
AWS Step Functions AWS Step Functions

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.

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 estructura de oleoductos y etapas en 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 estructura de acciones en CodePipeline ... ] }, { "name": "NextStageName", "actions": [ ... See Requisitos de estructura de acciones en 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 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 token de OAuth), el valor de esos parámetros secretos no se conserva. Debes introducir manualmente el valor de los parámetros (que están enmascarados por cuatro asteriscos en el JSON devuelto por el AWS CLI) e incluirlos en la estructura JSON.

  • 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.

    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 estructura de acciones en 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 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

  • 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, consulta la referencia CodePipeline de la API.

  • 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 Salida
    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 actionTypeId categorías 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 origen 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 CodeCommit los parámetros, consulteCodeCommit.
    GitHub Para obtener más información, incluidos ejemplos relacionados con GitHub los parámetros, consulteGitHub versión 1, fuente, estructura de acciones (referencia).
    AWS CloudFormation Para obtener más información, incluidos ejemplos relacionados con AWS CloudFormation los parámetros, consulteAWS CloudFormation.
    CodeBuild Para obtener más descripción y ejemplos relacionados con CodeBuild los parámetros, consulteAWS CodeBuild.
    CodeDeploy Para obtener más descripción y ejemplos relacionados con CodeDeploy los parámetros, consulteAWS CodeDeploy.
    AWS Device Farm Para obtener más descripción y ejemplos relacionados con AWS Device Farm los parámetros, consulteAWS Device Farm.
    AWS Elastic Beanstalk ElasticBeanstalk ApplicationName Obligatoria
    EnvironmentName Obligatoria
    AWS Lambda Para obtener más información, incluidos ejemplos relacionados con AWS Lambda los parámetros, consulteAWS Lambda.
    AWS OpsWorks Stacks OpsWorks Stack Obligatoria
    Layer Opcional
    App Obligatoria
    Amazon ECS Para ver más descripciones y ejemplos relacionados con los parámetros de Amazon ECS, consulte Amazon Elastic Container Service.
    Amazon ECS y CodeDeploy (azul/verde) Para obtener más descripción y ejemplos relacionados con Amazon ECS y los parámetros CodeDeploy azul/verde, consulte. Amazon Elastic Container Service y CodeDeploy azul-verde
    Service Catalog ServiceCatalog TemplateFilePath Obligatoria
    ProductVersionName Obligatoria
    ProductType Obligatoria
    ProductVersionDescription Opcional
    ProductId Obligatoria
    Alexa Skills Kit AlexaSkillsKit ClientId Obligatoria
    ClientSecret Obligatoria
    RefreshToken Obligatoria
    SkillId Obligatoria
    Jenkins El nombre de la acción que proporcionó en el CodePipeline complemento de Jenkins (por ejemplo,) MyJenkinsProviderName ProjectName Obligatoria
    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 Prueba CodeBuild De 1 a 5 De 0 a 5
AWS Prueba 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 Invocación 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 Prueba 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 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 AWS 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.

  • PollForSourceChanges los valores predeterminados del parámetro
    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 AWS CloudFormation, y el PollForSourceChanges parámetro no se muestra en la salida de 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 AWS CloudFormation, y el PollForSourceChanges parámetro no se muestra en la salida de 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 AWS CloudFormation, y el PollForSourceChanges parámetro no se muestra en la salida de 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 origen, 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" }