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