Amazon ya no CodeCatalyst está abierto a nuevos clientes. Los clientes existentes pueden seguir utilizando el servicio con normalidad. Para obtener más información, consulte [Cómo migrar desde CodeCatalyst](migration.md).
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.
# Ejecución de un flujo de trabajo
Una *ejecución* es una iteración única de un flujo de trabajo. Durante una ejecución, CodeCatalyst realiza las acciones definidas en el archivo de configuración del flujo de trabajo y genera los registros, artefactos y variables asociados.
Puede iniciar una ejecución manualmente o puede iniciarla automáticamente mediante un *desencadenador de flujo de trabajo*. Un ejemplo de desencadenador de flujo de trabajo podría ser un desarrollador de software que inserte una confirmación a la ramificación principal.
También puede detener manualmente la ejecución de un flujo de trabajo a mitad de su procesamiento si lo ha iniciado por error.
Si se inician varias ejecuciones de flujo de trabajo aproximadamente al mismo tiempo, puede configurar la forma en que desee que se pongan en cola estas ejecuciones. Puede utilizar el comportamiento de cola predeterminado, en el que las ejecuciones se ponen en cola una tras otra en el orden en que se iniciaron, o bien puede hacer que una ejecución posterior sustituya (o reemplace) a una anterior para acelerar la ejecución. También es posible configurar las ejecuciones del flujo de trabajo para que se produzcan en paralelo, de modo que ninguna ejecución espere a otra.
Después de iniciar una ejecución del flujo de trabajo, de forma manual o automática, puede ver el estado de la ejecución y otros detalles. Por ejemplo, puede ver cuándo se inició, quién lo inició y si aún se está ejecutando.
**Topics**
+ [Inicio manual de la ejecución de un flujo de trabajo](workflows-manually-start.md)
+ [Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores](workflows-add-trigger.md)
+ [Configuración de desencadenadores exclusivamente manuales](workflows-manual-only.md)
+ [Detención de una ejecución de flujo de trabajo](workflows-stop.md)
+ [Uso de puertas en una ejecución de flujo de trabajo](workflows-gates.md)
+ [Exigencia de aprobaciones en ejecuciones de flujos de trabajo](workflows-approval.md)
+ [Configuración del comportamiento de puesta en cola de las ejecuciones](workflows-configure-runs.md)
+ [Almacenamiento en caché de archivos entre ejecuciones de flujos de trabajo](workflows-caching.md)
+ [Visualización del estado y los detalles de la ejecución de un flujo de trabajo](workflows-view-run.md)
# Inicio manual de la ejecución de un flujo de trabajo
En Amazon CodeCatalyst, puedes iniciar un flujo de trabajo que se ejecute manualmente desde la CodeCatalyst consola.
Para obtener más información acerca de las ejecuciones de flujos de trabajo, consulte [Ejecución de un flujo de trabajo](workflows-working-runs.md).
**nota**
También puede iniciar la ejecución de un flujo de trabajo automáticamente mediante la [configuración de un desencadenador](workflows-add-trigger.md).
**Inicio de una ejecución de flujo de trabajo manualmente**
1. Abre la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Seleccione **Ejecutar**.
# Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores
Puedes iniciar la ejecución automática de un CodeCatalyst flujo de trabajo de Amazon con un activador de flujo de trabajo.
Un *desencadenador de flujo de trabajo*, o simplemente un *desencadenador*, permite iniciar la ejecución automática de un flujo de trabajo cuando se producen determinados eventos, como una inserción de código. Es posible que desee configurar los activadores para que sus desarrolladores de software no tengan que iniciar manualmente las ejecuciones del flujo de trabajo a través de la CodeCatalyst consola.
Puede utilizar tres tipos de desencadenadores:
+ **Inserción**: un desencadenador de inserción de código hace que se inicie la ejecución de un flujo de trabajo cada vez que se ejecute una confirmación.
+ **Solicitud de extracción**: un desencadenador de solicitud de extracción hace que se inicie la ejecución de un flujo de trabajo cada vez que se cree, revise o cierre una solicitud de extracción.
+ **Programación**: un desencadenador de programación hace que la ejecución de un flujo de trabajo comience según los plazos que defina. Plantéese la posibilidad de utilizar un desencadenador de programación para ejecutar compilaciones nocturnas de su software, de modo que la última versión esté lista para que los desarrolladores de software puedan trabajar en ella a la mañana siguiente.
Puede usar los desencadenadores de inserción, solicitud de extracción y programación solos o combinados en el mismo flujo de trabajo.
Los desencadenadores son opcionales; si no se configura ninguno, solo se puede iniciar un flujo de trabajo manualmente.
**sugerencia**
Para ver un desencadenador en acción, lance un proyecto con un esquema. La mayoría de los esquemas contienen un flujo de trabajo con un desencadenador. Busque la propiedad `Trigger` en el archivo de definición del flujo de trabajo del esquema. Para obtener más información acerca de los esquemas, consulte [Creación de un proyecto con un esquema](projects-create.md#projects-create-console-template).
**Topics**
+ [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md)
+ [Directrices de uso para activadores y ramificaciones](workflows-add-trigger-considerations.md)
+ [Adición de desencadenadores a flujos de trabajo](workflows-add-trigger-add.md)
# Ejemplos: Desencadenadores en flujos de trabajo
Los siguientes ejemplos muestran cómo añadir distintos tipos de activadores en un archivo de definición de CodeCatalyst flujo de trabajo de Amazon.
Para obtener más información acerca de los desencadenadores, consulte [Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores](workflows-add-trigger.md).
**Topics**
+ [Ejemplo: Desencadenador de inserción de código sencillo](#workflows-add-trigger-examples-push-simple)
+ [Ejemplo: Desencadenador de inserción en main sencillo](#workflows-add-trigger-examples-push-main)
+ [Ejemplo: Desencadenador de solicitud de extracción sencillo](#workflows-add-trigger-examples-pull-simple)
+ [Ejemplo: Desencadenador de programación sencillo](#workflows-add-trigger-examples-schedule-simple)
+ [Ejemplo: Desencadenador con programación y ramificaciones](#workflows-add-trigger-examples-schedule-branches)
+ [Ejemplo: Desencadenador con una programación, una inserción y ramificaciones](#workflows-add-trigger-examples-schedule-push-branches)
+ [Ejemplo: Desencadenador con una extracción y ramificaciones](#workflows-add-trigger-examples-pull-branches)
+ [Ejemplo: Desencadenador con una extracción, ramificaciones y un evento CLOSED](#workflows-add-trigger-examples-push-pull-close)
+ [Ejemplo: Desencadenador con inserción, ramificaciones y archivos](#workflows-add-trigger-examples-push-multi)
+ [Ejemplo: Disparador manual](#workflows-add-trigger-examples-manual)
+ [Ejemplo: activadores en una configuración de CI/CD flujo de trabajo múltiple](#workflows-add-trigger-usecases)
## Ejemplo: Desencadenador de inserción de código sencillo
El siguiente ejemplo muestra un desencadenador que inicia la ejecución de un flujo de trabajo cada vez que se envía código a *cualquier* ramificación del repositorio de código fuente.
Cuando se activa este activador, se CodeCatalyst inicia una ejecución de flujo de trabajo con los archivos de la rama *a la que estás accediendo* (es decir, la rama de destino).
Por ejemplo, si presionas una confirmación a`main`, se CodeCatalyst inicia una ejecución de flujo de trabajo utilizando el archivo de definición del flujo de trabajo y otros archivos fuente. `main`
Como otro ejemplo, si se envía una confirmación a`feature-branch-123`, se CodeCatalyst inicia una ejecución de flujo de trabajo utilizando el archivo de definición del flujo de trabajo y otros archivos fuente activados. `feature-branch-123`
```
Triggers:
- Type: PUSH
```
**nota**
Si desea que la ejecución de un flujo de trabajo se inicie solo cuando realice inserciones en `main`, consulte [Ejemplo: Desencadenador de inserción en main sencillo](#workflows-add-trigger-examples-push-main).
## Ejemplo: Desencadenador de inserción en main sencillo
El siguiente ejemplo muestra un desencadenador que inicia la ejecución de un flujo de trabajo cada vez que se inserta código en la ramificación `main` (y *solo* en la ramificación `main`) en el repositorio de código fuente.
```
Triggers:
- Type: PUSH
Branches:
- main
```
## Ejemplo: Desencadenador de solicitud de extracción sencillo
El siguiente ejemplo muestra un desencadenador que inicia la ejecución de un flujo de trabajo cada vez que se crea o revisa una solicitud de extracción en el repositorio de código fuente.
Cuando se activa este activador, CodeCatalyst inicia una ejecución de flujo de trabajo con el archivo de definición del flujo de trabajo y otros archivos fuente de la rama de la que se *extrae* (es decir, la rama de origen).
Por ejemplo, si creas una solicitud de extracción con una rama de origen llamada `feature-123` y una rama de destino llamada`main`, CodeCatalyst inicia una ejecución de flujo de trabajo utilizando el archivo de definición del flujo de trabajo y otros archivos de origen. `feature-123`
```
Triggers:
- Type: PULLREQUEST
Events:
- OPEN
- REVISION
```
## Ejemplo: Desencadenador de programación sencillo
El siguiente ejemplo muestra un desencadenador que inicia una ejecución de flujo de trabajo a medianoche (UTC\$10) de lunes a viernes.
Cuando se activa este activador, se CodeCatalyst inicia una sola ejecución de flujo de trabajo para cada rama del repositorio de origen que contenga un archivo de definición de flujo de trabajo con este activador.
Por ejemplo, si tienes tres ramas en tu repositorio de origen, `main` `release-v1``feature-123`, y cada una de estas ramas contiene un archivo de definición de flujo de trabajo con el siguiente desencadenante, CodeCatalyst inicia tres ejecuciones de flujo de trabajo: una con los archivos de dentro`main`, otra con los archivos de y otra con los archivos de`feature-123`. `release-v1`
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 ? * MON-FRI *"
```
Para ver más ejemplos de expresiones cron que puede utilizar en la propiedad `Expression`, consulte [Expression](workflow-reference.md#workflow.triggers.expression).
## Ejemplo: Desencadenador con programación y ramificaciones
El siguiente ejemplo muestra un desencadenador que inicia una ejecución de flujo de trabajo a las 18:15 h (UTC\$10) cada día.
Cuando se activa este activador, CodeCatalyst inicia una ejecución de flujo de trabajo con los archivos de la `main` rama e inicia ejecuciones adicionales para cada rama que comience con`release-`.
Por ejemplo, si tiene ramas denominadas`main`, `release-v1``bugfix-1`, y `bugfix-2` en el repositorio de origen, CodeCatalyst inicia dos ejecuciones de flujo de trabajo: una con los archivos de y otra con los archivos de`release-v1`. `main` *No* inicia ejecuciones del flujo de trabajo para las ramificaciones `bugfix-1` y `bugfix-1`.
```
Triggers:
- Type: SCHEDULE
Expression: "15 18 * * ? *"
Branches:
- main
- release\-.*
```
Para ver más ejemplos de expresiones cron que puede utilizar en la propiedad `Expression`, consulte [Expression](workflow-reference.md#workflow.triggers.expression).
## Ejemplo: Desencadenador con una programación, una inserción y ramificaciones
El siguiente ejemplo muestra un desencadenador que inicia una ejecución de flujo de trabajo a medianoche (UTC\$10) todos los días y siempre que se inserte código a la ramificación `main`.
En este ejemplo:
+ La ejecución de un flujo de trabajo comienza todos los días a medianoche. La ejecución del flujo de trabajo utiliza el archivo de definición del flujo de trabajo y otros archivos de origen en la ramificación `main`.
+ Una ejecución de flujo de trabajo también se inicia cada vez que se inserta una confirmación a la ramificación `main`. La ejecución del flujo de trabajo utiliza el archivo de definición del flujo de trabajo y otros archivos de origen en la ramificación de destino (`main`).
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 * * ? *"
Branches:
- main
- Type: PUSH
Branches:
- main
```
Para ver más ejemplos de expresiones cron que puede utilizar en la propiedad `Expression`, consulte [Expression](workflow-reference.md#workflow.triggers.expression).
## Ejemplo: Desencadenador con una extracción y ramificaciones
En el siguiente ejemplo, se muestra un desencadenador que inicia una ejecución de flujo de trabajo cada vez que alguien abre o modifica una solicitud de extracción con una ramificación de destino llamada `main`. Aunque la ramificación especificada en la configuración de `Triggers` sea `main`, la ejecución del flujo de trabajo utilizará el archivo de definición del flujo de trabajo y otros archivos de origen de la ramificación de *origen* (que es la ramificación *desde* la que se extrae).
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
## Ejemplo: Desencadenador con una extracción, ramificaciones y un evento CLOSED
En el siguiente ejemplo, se muestra un desencadenador que inicia una ejecución de flujo de trabajo cada vez que se cierra una solicitud de extracción en una ramificación que comience por `main`.
En este ejemplo:
+ Cuando se cierras una solicitud de extracción con una ramificación de destino que comience por `main`, se inicia automáticamente una ejecución de flujo de trabajo con el archivo de definición del flujo de trabajo y otros archivos de origen de la ramificación de origen (ahora cerrada).
+ Si ha configurado el repositorio de código fuente para que elimine las ramificaciones automáticamente después de combinar una solicitud de extracción, estas ramificaciones nunca tendrán la oportunidad de entrar en el estado `CLOSED`. Esto significa que las ramificaciones combinadas no activarán el desencadenador de la solicitud de extracción `CLOSED`. La única forma de activar el desencadenador `CLOSED` en este escenario es cerrar la solicitud de extracción sin combinarla.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- CLOSED
```
## Ejemplo: Desencadenador con inserción, ramificaciones y archivos
El siguiente ejemplo muestra un desencadenador que inicia la ejecución de un flujo de trabajo cada vez que se realiza un cambio en el archivo `filename.txt` o en cualquier archivo del directorio `src` en la ramificación `main`.
Cuando se activa este activador, CodeCatalyst inicia una ejecución de flujo de trabajo con el archivo de definición del flujo de trabajo y otros archivos fuente de la `main` rama.
```
Triggers:
- Type: PUSH
Branches:
- main
FilesChanged:
- filename.txt
- src\/.*
```
## Ejemplo: Disparador manual
Para configurar un disparador manual, omita la sección `Triggers` del archivo de definición del flujo de trabajo. Sin esta sección, los usuarios se ven obligados a iniciar el flujo de trabajo manualmente pulsando el botón **Ejecutar** de la CodeCatalyst consola. Para obtener más información, consulte [Inicio manual de la ejecución de un flujo de trabajo](workflows-manually-start.md).
## Ejemplo: activadores en una configuración de CI/CD flujo de trabajo múltiple
En este ejemplo, se describe cómo configurar los activadores cuando se desean utilizar CodeCatalyst flujos de trabajo de Amazon independientes para la integración continua (CI) y el despliegue continuo (CD).
En este escenario, debe configurar dos flujos de trabajo:
+ un **flujo de trabajo de CI**: este flujo de trabajo crea y prueba la aplicación cuando se crea o revisa una solicitud de extracción;
+ un **flujo de trabajo de CD**: este flujo de trabajo crea e implementa la aplicación cuando se combina una solicitud de extracción.
El archivo de definición del **flujo de trabajo de CI** tendría un aspecto similar al siguiente:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
Actions:
BuildAction:
instructions-for-building-the-app
TestAction:
instructions-for-test-the-app
```
El `Triggers` código indica que hay que iniciar automáticamente un flujo de trabajo cada vez que un desarrollador de software cree una solicitud de cambios (o [modifique una](pull-requests-update.md)) solicitando la fusión de su rama de funciones con la `main` rama. CodeCatalyst inicia la ejecución del flujo de trabajo utilizando el código fuente de la rama fuente (que es la rama de funciones).
El archivo de definición del **flujo de trabajo de CD** tendría un aspecto similar al siguiente:
```
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildAction:
instructions-for-building-the-app
DeployAction:
instructions-for-deploying-the-app
```
El `Triggers` código indica que el flujo de trabajo se inicie automáticamente cuando `main` se produzca una fusión. CodeCatalyst inicia la ejecución del flujo de trabajo utilizando el código fuente de la `main` rama.
# Directrices de uso para activadores y ramificaciones
En esta sección se describen algunas de las principales pautas a la hora de configurar los CodeCatalyst activadores de Amazon que incluyen sucursales.
Para obtener más información acerca de los desencadenadores, consulte [Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores](workflows-add-trigger.md).
+ **Directriz 1:** para los activadores de solicitudes de extracción e inserción, si va a especificar una ramificación, debe especificar la ramificación de destino (o “a”) en la configuración del desencadenador. Nunca especifiques la ramificación de origen (o “desde”).
En el siguiente ejemplo, una inserción desde cualquier ramificación a `main` activa el flujo de trabajo.
```
Triggers:
- Type: PUSH
Branches:
- main
```
En el siguiente ejemplo, una solicitud de extracción desde cualquier ramificación a `main` activa el flujo de trabajo.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
+ **Directriz 2:** para los desencadenadores de inserción, una vez activado el flujo de trabajo, este se ejecutará utilizando el archivo de definición del flujo de trabajo y los archivos de origen de la ramificación de *destino*.
+ **Directriz 3:** para los desencadenadores de solicitud de extracción, una vez activado el flujo de trabajo, este se ejecutará utilizando el archivo de definición del flujo de trabajo y los archivos de origen de la ramificación de *origen* (aunque haya especificado la ramificación de destino en la configuración del desencadenador).
+ **Directriz 4:** es posible que el mismo activador exacto en una ramificación no se ejecute en otra ramificación.
Considere el siguiente desencadenador de inserción:
```
Triggers:
- Type: PUSH
Branches:
- main
```
Si el archivo de definición del flujo de trabajo que contiene este activador existe en `main` y se clona en `test`, el flujo de trabajo nunca empezará automáticamente a utilizar los archivos en `test` (aunque puede iniciar el flujo de trabajo *manualmente* para que utilice los archivos en `test`). Consulte la **directriz 2** para entender por qué el flujo de trabajo nunca se ejecutará automáticamente con los archivos en `test`.
Piense también en el siguiente desencadenador de solicitud de extracción:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
Si el archivo de definición del flujo de trabajo que contiene este desencadenador existe en `main`, el flujo de trabajo nunca se ejecutará con los archivos en `main`. (Sin embargo, si crea una ramificación `test` a partir de `main`, el flujo de trabajo se ejecutará con los archivos en `test`). Revise la **directriz 3** para entender por qué.
# Adición de desencadenadores a flujos de trabajo
Sigue las siguientes instrucciones para añadir un activador de inserción, extracción o programación a tu CodeCatalyst flujo de trabajo de Amazon.
Para obtener más información acerca de los desencadenadores, consulte [Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores](workflows-add-trigger.md).
------
#### [ Visual ]
**Adición de un desencadenador (editor visual)**
1. Abre la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **Visual**.
1. En el diagrama de flujo de trabajo, seleccione las casillas **Origen** y **Desencadenadores**.
1. En el panel de configuración, seleccione **Agregar desencadenador**.
1. En el cuadro de diálogo **Agregar desencadenador**, introduzca la información en los campos, de la siguiente manera.
**Tipo de desencadenador**
Especifique el tipo de desencadenador. Puede utilizar uno de los siguientes valores:
+ **Insertar** (editor visual) o `PUSH` (editor de YAML)
Un desencadenador de inserción inicia la ejecución de un flujo de trabajo cuando se envía un cambio al repositorio de código fuente. La ejecución del flujo de trabajo utilizará los archivos de la ramificación *a* la que realiza la inserción (es decir, la ramificación de destino).
+ **Solicitud de extracción** (editor visual) o `PULLREQUEST` (editor de YAML)
Un desencadenador de este tipo inicia la ejecución de un flujo de trabajo cuando se abre, actualiza o cierra una solicitud de extracción en el repositorio de código fuente. La ejecución del flujo de trabajo utilizará los archivos de la ramificación *desde* la que realiza la extracción (es decir, la ramificación de origen).
+ **Programación** (editor visual) o `SCHEDULE` (editor de YAML)
Un desencadenador de tipo programación inicia las ejecuciones del flujo de trabajo según una programación definida por una expresión cron que especifique. Se iniciará una ejecución de flujo de trabajo independiente para cada ramificación del repositorio de código fuente utilizando los archivos de la ramificación. (Para limitar las ramificaciones en las que se activa el desencadenador, use el campo **Ramificaciones** (editor visual) o la propiedad `Branches` (editor de YAML)).
Cuando configure un desencadenador de programación, siga estas directrices:
+ Utilice solo un desencadenador de programación por flujo de trabajo.
+ Si ha definido varios flujos de trabajo en su CodeCatalyst espacio, le recomendamos que no programe más de 10 de ellos para que se inicien simultáneamente.
+ Asegúrese de configurar la expresión cron del desencadenador con el tiempo adecuado entre ejecuciones. Para obtener más información, consulte [Expression](workflow-reference.md#workflow.triggers.expression).
Para ver ejemplos, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md).
**Eventos para solicitud de extracción**
Este campo solo aparece si ha seleccionado el tipo de desencadenador **Solicitud de extracción**.
Especifica el tipo de eventos de solicitud de extracción que iniciarán la ejecución de un flujo de trabajo. Los siguientes valores son los válidos:
+ **Se crea una solicitud de extracción** (editor visual) o `OPEN` (editor de YAML)
La ejecución del flujo de trabajo se inicia cuando se crea una solicitud de extracción.
+ **La solicitud de extracción está cerrada** (editor visual) o `CLOSED` (editor de YAML)
La ejecución del flujo de trabajo se inicia cuando se cierra una solicitud de extracción. El comportamiento del evento `CLOSED` es complejo y se entiende mejor con un ejemplo. Para obtener más información, consulte [Ejemplo: Desencadenador con una extracción, ramificaciones y un evento CLOSED](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close).
+ **Se realiza una nueva revisión para la solicitud de extracción** (editor visual) o `REVISION` (editor de YAML)
La ejecución del flujo de trabajo se inicia cuando se crea una revisión de una solicitud de extracción. La primera revisión se crea cuando se crea la solicitud de extracción. Después se crea una nueva revisión cada vez que alguien envía una nueva confirmación a la ramificación de origen especificada en la solicitud de extracción. Si incluye el evento `REVISION` en el desencadenador de la solicitud de extracción, puede omitir el evento `OPEN`, ya que `REVISION` es un superconjunto de `OPEN`.
Puede especificar varios eventos en el mismo desencadenador de la solicitud de extracción.
Para ver ejemplos, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md).
**Programación**
Este campo solo aparece si ha seleccionado el tipo de desencadenador **Programación**.
Especifique la expresión cron que describe cuándo desea que se ejecuten sus flujos de trabajo programados.
Las expresiones cron CodeCatalyst utilizan la siguiente sintaxis de seis campos, en la que cada campo está separado por un espacio:
*minutes* *hours* *days-of-month* *month* *days-of-week* *year*
**Ejemplos de expresiones cron**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/workflows-add-trigger-add.html)
Al especificar las expresiones cron CodeCatalyst, asegúrese de seguir estas pautas:
+ Especifique una sola expresión cron por desencadenador `SCHEDULE`.
+ Escriba la expresión cron entre comillas dobles (`"`) en el editor de YAML.
+ Especifique la hora en tiempo universal coordinado (UTC). El resto de zonas horarias no son compatibles.
+ Configure al menos 30 minutos entre ejecuciones. Una cadencia más rápida no es compatible.
+ Especifique el *days-of-week* campo *days-of-month* o, pero no ambos. Si especifica un valor o un asterisco (`*`) en uno de los campos, debe utilizar un signo de interrogación (`?`) en el otro. El asterisco significa todos y el signo de interrogación significa cualquiera.
Para obtener más ejemplos de expresiones cron e información sobre caracteres comodín`?`, como, y `*``L`, consulte la [referencia sobre expresiones cron en](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html) la Guía del usuario de *Amazon EventBridge *. Las expresiones cron CodeCatalyst funcionan EventBridge y funcionan exactamente de la misma manera.
Para ver ejemplos de desencadenadores de programación, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md).
**Ramificaciones** y **Patrón de ramificación**
(Opcional)
Especifica las ramificaciones del repositorio de código fuente que supervisa el desencadenador para saber cuándo iniciar la ejecución de un flujo de trabajo. Puede usar patrones de expresiones regulares para definir los nombres de las ramificaciones. Por ejemplo, use `main.*` para hacer coincidir todas las ramificaciones que comiencen por `main`.
Las ramificaciones que se deben especificar son diferentes en función del tipo de desencadenador:
+ En el caso de un desencadenador de inserción, especifique las ramificaciones *en* las que va a realizar la inserción, es decir, las ramificaciones de *destino*. Se iniciará una ejecución de flujo de trabajo por cada ramificación coincidente, utilizando los archivos de la ramificación coincidente.
Ejemplos: `main.*`, `mainline`
+ En el caso de un desencadenador de solicitud de extracción, especifique las ramificaciones *en* las que va a realizar la inserción, es decir, las ramificaciones de *destino*. Se iniciará una ejecución de flujo de trabajo por cada ramificación coincidente, utilizando el archivo de definición del flujo de trabajo y los archivos de origen de la ramificación de **origen** (*no* de la ramificación coincidente).
Ejemplos: `main.*`, `mainline`, `v1\-.*` (busca coincidencias con las ramificaciones que comiencen por `v1-`)
+ Para un desencadenador de programación, especifique las ramificaciones que contengan los archivos que quiera que utilice la ejecución programada. Se iniciará una ejecución de flujo de trabajo por cada ramificación coincidente, utilizando el archivo de definición del flujo de trabajo y los archivos de origen en la ramificación coincidente.
Ejemplos: `main.*`, `version\-1\.0`
**nota**
Si *no* especifica ninguna ramificación, el activador supervisa todas las ramificaciones del repositorio de código fuente e iniciará una ejecución de flujo de trabajo con el archivo de definición del flujo de trabajo y los archivos de código fuente en:
La ramificación *en* la que realiza la inserción (para desencadenadores de inserción). Para obtener más información, consulte [Ejemplo: Desencadenador de inserción de código sencillo](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple).
La ramificación *desde* la que realiza la extracción (para desencadenadores de solicitudes de extracción). Para obtener más información, consulte [Ejemplo: Desencadenador de solicitud de extracción sencillo](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple).
Todas las ramificaciones (para desencadenadores de programación). Se iniciará una ejecución de flujo de trabajo por cada ramificación del repositorio de código fuente. Para obtener más información, consulte [Ejemplo: Desencadenador de programación sencillo](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple).
Para obtener más información acerca de las ramificaciones y los desencadenadores, consulte [Directrices de uso para activadores y ramificaciones](workflows-add-trigger-considerations.md).
Para obtener más ejemplos, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md).
**Archivos cambiados**
Este campo solo aparece si ha seleccionado el tipo de desencadenador **Inserción** o **Solicitud de extracción**.
Especifica los archivos o carpetas del repositorio de código fuente que supervisa el desencadenador para saber cuándo iniciar la ejecución de un flujo de trabajo. Puede utilizar expresiones regulares para hacer coincidir los nombres o las rutas de los archivos.
Para ver ejemplos, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md).
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
#### [ YAML ]
**Adición de un desencadenador (editor de YAML)**
1. Abre la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **YAML**.
1. Añada una sección `Triggers` y las propiedades subyacentes utilizando el siguiente ejemplo como guía. Para obtener más información, consulte [Triggers](workflow-reference.md#triggers-reference) en la [Definición de flujo de trabajo en YAML](workflow-reference.md).
Un desencadenador de inserción de código podría tener este aspecto:
```
Triggers:
- Type: PUSH
Branches:
- main
```
Un desencadenador de solicitud de extracción podría tener este aspecto:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- OPEN
- REVISION
- CLOSED
```
Un desencadenador de programación podría tener este aspecto:
```
Triggers:
- Type: SCHEDULE
Branches:
- main.*
# Run the workflow at 1:15 am (UTC+0) every Friday until the end of 2023
Expression: "15 1 ? * FRI 2022-2023"
```
Para ver más ejemplos de expresiones cron que puede utilizar en la propiedad `Expression`, consulte [Expression](workflow-reference.md#workflow.triggers.expression).
Para ver más ejemplos de desencadenadores de inserción, solicitud de extracción y programación, consulte [Ejemplos: Desencadenadores en flujos de trabajo](workflows-add-trigger-examples.md).
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
# Configuración de desencadenadores exclusivamente manuales
Puedes limitar un flujo de trabajo para que tu equipo solo pueda iniciarlo manualmente mediante el botón **Ejecutar** de la CodeCatalyst consola. Para configurar esta funcionalidad, debe eliminar la sección `Triggers` del archivo de definición del flujo de trabajo. La sección `Triggers` se incluye de forma predeterminada al crear un flujo de trabajo, pero es opcional y se puede eliminar.
Siga estas instrucciones para eliminar la sección `Triggers` del archivo de definición del flujo de trabajo, de modo que el flujo de trabajo solo se pueda iniciar manualmente.
Para obtener más información acerca de los desencadenadores, consulte [Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores](workflows-add-trigger.md).
Para obtener más información acerca de la ejecución de flujos de trabajo, consulte [Ejecución de un flujo de trabajo](workflows-working-runs.md).
------
#### [ Visual ]
**Eliminación de la sección “Desencadenadores” (editor visual)**
1. Abre la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **Visual**.
1. Seleccione la casilla **Origen** en el diagrama de flujo de trabajo.
1. En **Desencadenadores**, seleccione el icono de la papelera para eliminar la sección `Triggers` del flujo de trabajo.
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
#### [ YAML ]
**Eliminación de la sección “Desencadenadores” (editor de YAML)**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **YAML**.
1. Busque la sección `Triggers` y elimínela.
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
# Detención de una ejecución de flujo de trabajo
Utilice el siguiente procedimiento para detener una ejecución de un flujo de trabajo en curso. Es posible que desee detener una ejecución si se ha iniciado por accidente.
Al detener la ejecución de un flujo de trabajo, CodeCatalyst espera a que se completen las acciones en curso antes de marcar la ejecución como **detenida** en la consola. CodeCatalyst Las acciones que no hayan podido iniciarse no se iniciarán y se marcarán con el estado **Abandonado**.
**nota**
Si una ejecución está en cola (es decir, no tiene ninguna acción en curso), la ejecución se detiene inmediatamente.
Para obtener más información acerca de las ejecuciones de flujos de trabajo, consulte [Ejecución de un flujo de trabajo](workflows-working-runs.md).
**Detención de una ejecución de flujo de trabajo**
1. [Abre la CodeCatalyst consola en https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. En **Flujos de trabajo**, seleccione **Ejecuciones** y elija la ejecución en curso de la lista.
1. Elija **Detener**.
# Uso de puertas en una ejecución de flujo de trabajo
Una *puerta* es un componente de flujo de trabajo que se puede utilizar para impedir que la ejecución de un flujo de trabajo continúe a menos que se cumplan determinadas condiciones. Un ejemplo de puerta es la puerta de **aprobación**, en la que los usuarios deben enviar una aprobación en la CodeCatalyst consola antes de permitir que continúe la ejecución del flujo de trabajo.
Puede añadir puertas entre las secuencias de acciones de un flujo de trabajo o antes de la primera acción (que se ejecuta inmediatamente después de descargar el **Origen**). También puede agregar puertas después de la última acción, si es necesario.
Para obtener más información acerca de las ejecuciones de flujos de trabajo, consulte [Ejecución de un flujo de trabajo](workflows-working-runs.md).
**Topics**
+ [Tipos de puertas](#workflows-gates-types)
+ [¿Puedo configurar una puerta para que se ejecute en paralelo a otra acción?](#workflows-approval-parallel)
+ [¿Puedo usar una puerta para impedir que se inicie la ejecución de un flujo de trabajo?](#workflows-gates-prevent)
+ [Limitaciones de puertas](#workflows-gate-limitations)
+ [Cómo añadir una puerta a un flujo de trabajo](workflows-gates-add.md)
+ [Secuenciación de puertas y acciones](workflows-gates-depends-on.md)
+ [Especificación de la versión de una puerta](workflows-gates-version.md)
## Tipos de puertas
Actualmente, Amazon CodeCatalyst admite un tipo de puerta: la puerta de **aprobación**. Para obtener más información, consulte [Exigencia de aprobaciones en ejecuciones de flujos de trabajo](workflows-approval.md).
## ¿Puedo configurar una puerta para que se ejecute en paralelo a otra acción?
No. Las puertas solo pueden ejecutarse antes o después de una acción. Para obtener más información, consulte [Secuenciación de puertas y acciones](workflows-gates-depends-on.md).
## ¿Puedo usar una puerta para impedir que se inicie la ejecución de un flujo de trabajo?
Sí, con cualificaciones.
Puede impedir que la ejecución de un flujo de trabajo *realice tareas*, lo que es ligeramente diferente de impedir que se *inicie*.
Para evitar que un flujo de trabajo realice tareas, agregue una puerta antes de la primera acción del flujo de trabajo. En este escenario, *se iniciará* la ejecución de un flujo de trabajo (es decir, se descargarán los archivos del repositorio de código fuente), pero no podrá realizar tareas hasta que se desbloquee la puerta.
**nota**
Los flujos de trabajo que se inician y después se bloquean mediante una puerta se siguen teniendo en cuenta para la cuota de *Máximo de ejecuciones simultáneas del flujo de trabajo por espacio* y también para otras cuotas. Para asegurarse de no superar las cuotas de flujo de trabajo, considere la posibilidad de utilizar un desencadenante de flujo de trabajo para iniciar un flujo de trabajo de forma condicional en lugar de utilizar una puerta. Plantéese también la posibilidad de utilizar una regla de aprobación de solicitudes de extracción en lugar de una puerta. Para obtener más información sobre las cuotas, los desencadenadores y las reglas de aprobación de solicitudes de extracción, consulte [Cuotas para flujos de trabajo en CodeCatalyst](workflows-quotas.md), [Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores](workflows-add-trigger.md) y [Administración de los requisitos para combinar una solicitud de extracción con reglas de aprobación](source-pull-requests-approval-rules.md).
## Limitaciones de puertas
Las puertas presentan las siguientes limitaciones:
+ Las puertas no se pueden utilizar junto con las característica de computación compartida. Para obtener más información acerca de esta característica, consulte [Uso compartido de recursos de computación entre acciones](compute-sharing.md).
+ Las puertas no se pueden usar dentro de grupos de acciones. Para obtener más información sobre los grupos de acciones, consulte [Agrupación de acciones en grupos de acciones](workflows-group-actions.md).
# Cómo añadir una puerta a un flujo de trabajo
En Amazon CodeCatalyst, puede añadir una puerta a un flujo de trabajo para impedir que continúe a menos que se cumplan determinadas condiciones. Siga estas instrucciones para añadir una puerta a un flujo de trabajo.
Para obtener más información acerca de las puertas, consulte [Uso de puertas en una ejecución de flujo de trabajo](workflows-gates.md).
**Cómo añadir y configurar una puerta**
1. Abra la consola de CodeCatalyst en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Seleccione **Editar**.
1. Elija **Visual**.
1. A la izquierda, seleccione **Puertas**.
1. En el catálogo de puertas, busque una puerta y seleccione el signo más (**\$1**) para añadir la puerta a su flujo de trabajo.
1. Configure la puerta. Seleccione **Visual** para usar el editor visual o **YAML** para usar el editor de YAML. Para obtener instrucciones detalladas, consulte:
+ [Adición de una puerta de Aprobación](workflows-approval-add.md)
1. (Opcional) Seleccione **Validar** para asegurarse de que el código de YAML sea válido.
1. Seleccione **Confirmar** para confirmar los cambios.
# Secuenciación de puertas y acciones
En Amazon CodeCatalyst, puede configurar una puerta para que se ejecute antes o después de una acción, grupo de acciones o puerta del flujo de trabajo. Por ejemplo, puede configurar una puerta de `Approval` para que se ejecute antes de una acción `Deploy`. En este caso, se dice que la acción `Deploy` *depende de* la puerta de `Approval`.
Para configurar las dependencias entre las puertas y las acciones, configure la propiedad **Depends on** de la acción. Para obtener instrucciones, consulte [Configuración de dependencias entre acciones](workflows-depends-on-set-up.md). Las instrucciones a las que se hace referencia se refieren a las *acciones* del flujo de trabajo, pero se aplican igualmente a las puertas.
Para ver un ejemplo de cómo configurar la propiedad **Depends on** con una puerta, consulte[Ejemplo: Una puerta de Aprobación](workflows-approval-example.md).
Para obtener más información acerca de las puertas, consulte [Uso de puertas en una ejecución de flujo de trabajo](workflows-gates.md).
Para obtener más información acerca de las acciones de flujos de trabajo, consulte [Configuración de acciones de flujo de trabajo](workflows-actions.md).
# Especificación de la versión de una puerta
De forma predeterminada, al agregar una puerta a un flujo de trabajo, CodeCatalyst añade la versión completa al archivo de definición del flujo de trabajo con el formato:
`vmajor.minor.patch`
Por ejemplo:
```
My-Gate:
Identifier: aws/approval@v1
```
Puede alargar la versión para que el flujo de trabajo utilice una versión principal o secundaria específica de la puerta. Para obtener instrucciones, consulte [Especificación de la versión de la acción que se va a utilizar](workflows-action-versions.md). El tema al que se hace referencia tiene que ver con las acciones del flujo de trabajo, pero se aplica igualmente a las puertas.
Para obtener más información acerca de las puertas en CodeCatalyst, consulte [Uso de puertas en una ejecución de flujo de trabajo](workflows-gates.md).
# Exigencia de aprobaciones en ejecuciones de flujos de trabajo
Puede configurar una ejecución de un flujo de trabajo para que requiera una aprobación antes de continuar. Para ello, debe añadir una [puerta](workflows-gates.md) de **Aprobación** al flujo de trabajo. Una *puerta de aprobación* impide que un flujo de trabajo continúe hasta que un usuario o un conjunto de usuarios envíen una o más aprobaciones en la CodeCatalyst consola. Una vez concedidas todas las aprobaciones, se desbloquea la puerta y se permite reanudar la ejecución del flujo de trabajo.
Utilice una puerta de **Aprobación** en su flujo de trabajo para que sus equipos de desarrollo, operaciones y liderazgo tengan la oportunidad de revisar los cambios antes de implementarlos entre un público más amplio.
Para obtener más información acerca de las ejecuciones de flujos de trabajo, consulte [Ejecución de un flujo de trabajo](workflows-working-runs.md).
**Topics**
+ [¿Cómo puedo desbloquear una puerta de aprobación?](#workflows-approval-conditions)
+ [Cuándo usar la puerta de Aprobación](#workflows-approval-when)
+ [¿Quién puede proporcionar una aprobación?](#workflows-approval-who)
+ [¿Cómo notifico a los usuarios que se requiere una aprobación?](#workflows-approval-notify-methods)
+ [¿Puedo usar una puerta de Aprobación para impedir que se inicie la ejecución de un flujo de trabajo?](#workflows-approval-prevent)
+ [¿Cómo funcionan las aprobaciones de flujos de trabajo con los modos de ejecución en cola, reemplazado y en paralelo?](#workflows-approval-run-mode)
+ [Ejemplo: Una puerta de Aprobación](workflows-approval-example.md)
+ [Adición de una puerta de Aprobación](workflows-approval-add.md)
+ [Configuración de notificaciones de aprobación](workflows-approval-notify.md)
+ [Aprobación o rechazo de la ejecución de un flujo de trabajo](workflows-approval-approve.md)
+ [Puerta de “aprobación” de YAML](approval-ref.md)
## ¿Cómo puedo desbloquear una puerta de aprobación?
Para desbloquear una puerta de **Aprobación**, se deben cumplir *todas* las condiciones siguientes:
+ **Condición 1**: se debe enviar el número de aprobaciones requerido. El número de aprobaciones requerido se puede configurar y cada usuario puede enviar una sola aprobación.
+ **Condición 2**: todas las aprobaciones deben enviarse antes de que se agote el tiempo de espera de la puerta. La puerta caduca 14 días después de su activación. Este período no se puede configurar.
+ **Condición 3**: nadie debe rechazar la ejecución del flujo de trabajo. Un solo rechazo provocará un error en la ejecución del flujo de trabajo.
+ **Condición 4**: (solo se aplica si se utiliza el modo de ejecución reemplazado). La ejecución no debe reemplazarse por una ejecución posterior. Para obtener más información, consulte [¿Cómo funcionan las aprobaciones de flujos de trabajo con los modos de ejecución en cola, reemplazado y en paralelo?](#workflows-approval-run-mode).
Si no se cumple alguna de las condiciones, CodeCatalyst detiene el flujo de trabajo y establece el estado de ejecución en **Fallada** (en el caso de **las condiciones 1** a **3**) o **Reemplazada** (en el caso de la **condición 4**).
## Cuándo usar la puerta de Aprobación
Normalmente, se utiliza una puerta de **Aprobación** en un flujo de trabajo que implemente aplicaciones y otros recursos en un servidor de producción o en cualquier entorno en el que se deban validar los estándares de calidad. Al colocar la puerta antes de la implementación en producción, los revisores tienen la oportunidad de validar la nueva revisión del software antes de que esté disponible para el público.
## ¿Quién puede proporcionar una aprobación?
Cualquier usuario que sea miembro de su proyecto y que tenga el rol de **Colaborador** o **Administrador del proyecto** puede dar su aprobación. Los usuarios con el rol de **Administrador del espacio** que pertenezcan al espacio del proyecto también pueden dar su aprobación.
**nota**
Los usuarios con el rol de **Revisor** no pueden proporcionar aprobaciones.
## ¿Cómo notifico a los usuarios que se requiere una aprobación?
Para notificar a los usuarios que se requiere una aprobación, debe hacer lo siguiente:
+ Haz que les CodeCatalyst envíes una notificación a Slack. Para obtener más información, consulte [Configuración de notificaciones de aprobación](workflows-approval-notify.md).
+ Ve a la página de la CodeCatalyst consola donde están los botones **Aprobar** y **Rechazar** y pega la URL de esa página en una aplicación de correo electrónico o mensajería dirigida a los responsables de la aprobación. Para obtener más información sobre cómo navegar a esta página, consulte [Aprobación o rechazo de la ejecución de un flujo de trabajo](workflows-approval-approve.md).
## ¿Puedo usar una puerta de Aprobación para impedir que se inicie la ejecución de un flujo de trabajo?
Sí, con cualificaciones. Para obtener más información, consulte [¿Puedo usar una puerta para impedir que se inicie la ejecución de un flujo de trabajo?](workflows-gates.md#workflows-gates-prevent).
## ¿Cómo funcionan las aprobaciones de flujos de trabajo con los modos de ejecución en cola, reemplazado y en paralelo?
Cuando se utiliza el modo de ejecución en cola, reemplazado o paralelo, la puerta de **Aprobación** funciona de forma similar a las [acciones](workflows-actions.md). Le sugerimos que lea las secciones [Acerca del modo de ejecución en cola](workflows-configure-runs.md#workflows-configure-runs-queued), [Acerca del modo de ejecución reemplazado](workflows-configure-runs.md#workflows-configure-runs-superseded) y [Acerca del modo de ejecución en paralelo](workflows-configure-runs.md#workflows-configure-runs-parallel) para familiarizarse con estos modos de ejecución. Una vez que tenga una comprensión básica de ellas, vuelva a esta sección para averiguar cómo funcionan estos modos de ejecución cuando se tiene una puerta de **Aprobación**.
Cuando existe la puerta de **Aprobación**, las ejecuciones se procesan de la siguiente manera:
+ Si se utiliza el [modo de ejecución en cola](workflows-configure-runs.md#workflows-configure-runs-queued), las ejecuciones se pondrán en cola detrás de la ejecución que esté esperando su aprobación en la puerta. Cuando esa puerta se desbloquee (es decir, cuando se hayan obtenido todas las aprobaciones), la siguiente ejecución de la cola avanzará hasta la puerta y esperará a recibir las aprobaciones. Este proceso continúa y las ejecuciones en cola se procesan hasta el final. one-by-one [Figure 1](#figure-1-workflow-queued-run-mode-ma)ilustra este proceso.
+ Si se utiliza el [modo de ejecución reemplazado](workflows-configure-runs.md#workflows-configure-runs-superseded), el comportamiento es el mismo que en el modo de ejecución en cola, con la diferencia de que, en lugar de acumular ejecuciones en la cola, las ejecuciones más recientes reemplazan (sustituyen) a las anteriores. No hay colas, y cualquier ejecución que esté esperando su aprobación en la puerta ese momento se cancelará y será reemplazada por una ejecución más reciente. [Figure 2](#figure-2-workflow-superseded-run-mode-ma) ilustra este proceso.
+ Si utiliza el [modo de ejecución en paralelo](workflows-configure-runs.md#workflows-configure-runs-parallel), las ejecuciones comienzan en paralelo y no se forman colas. La puerta procesa cada ejecución inmediatamente, ya que no hay ninguna ejecución por delante. [Figure 3](#figure-3-workflow-parallel-run-mode-ma) ilustra este proceso.
**Figura 1**: modo de ejecución en cola y puerta de **Aprobación**
![\[Cómo funciona una puerta de Aprobación con el modo de ejecución en cola\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png)
**Figura 2**: modo de ejecución reemplazado y puerta de **Aprobación**
![\[Cómo funciona una puerta de Aprobación con el modo de ejecución reemplazado\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png)
**Figura 3**: modo de ejecución en paralelo y puerta de **Aprobación**
![\[Cómo funciona una puerta de Aprobación con el modo de ejecución en paralelo\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png)
# Ejemplo: Una puerta de Aprobación
En el siguiente ejemplo se muestra cómo añadir una puerta de **Aprobación** llamada `Approval_01` entre dos acciones denominadas `Staging` y `Production`. La acción `Staging` se ejecuta en primer lugar, la puerta `Approval_01` en segundo lugar y la acción `Production` en último lugar. La acción `Production` solo se ejecuta si la puerta `Approval_01` está desbloqueada. La propiedad `DependsOn` garantiza que las fases `Staging`, `Approval_01` y `Production` se ejecuten en orden secuencial.
Para obtener más información sobre la puerta de **Aprobación**, consulte [Exigencia de aprobaciones en ejecuciones de flujos de trabajo](workflows-approval.md).
```
Actions:
Staging: # Deploy to a staging server
Identifier: aws/ecs-deploy@v1
Configuration:
...
Approval_01:
Identifier: aws/approval@v1
DependsOn:
- Staging
Configuration:
ApprovalsRequired: 2
Production: # Deploy to a production server
Identifier: aws/ecs-deploy@v1
DependsOn:
- Approval_01
Configuration:
...
```
# Adición de una puerta de Aprobación
Para configurar su flujo de trabajo de modo que requiera una aprobación, debe añadir la puerta de **Aprobación** al flujo de trabajo. Siga estas instrucciones para añadir una puerta de **Aprobación** a su flujo de trabajo.
Para obtener más información acerca de este tipo de puerta, consulte [Exigencia de aprobaciones en ejecuciones de flujos de trabajo](workflows-approval.md).
------
#### [ Visual ]
**Adición de una puerta de Aprobación a un flujo de trabajo (editor visual)**
1. Abre la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. En la parte superior izquierda, seleccione **Puertas**.
1. En el catálogo de **Puertas**, en **Aprobación**, seleccione el signo más (**\$1**).
1. Seleccione **Entradas** y, en el campo **Depende de**, haga lo siguiente.
Especifique la acción, el grupo de acciones o la puerta que debe ejecutarse correctamente para que esta puerta se ejecute. De forma predeterminada, al añadir una puerta a un flujo de trabajo, la puerta se configura para que dependa de la última acción del flujo de trabajo. Si elimina esta propiedad, la puerta no dependerá de nada y se ejecutará primero, antes que otras acciones.
**nota**
Se debe configurar una puerta para que se ejecute antes o después de una acción, un grupo de acciones o una puerta. No se puede configurar para que se ejecute en paralelo con otras acciones, grupos de acción y puertas.
Para obtener más información sobre la funcionalidad **Depende de**, consulte [Secuenciación de puertas y acciones](workflows-gates-depends-on.md).
1. Elija la pestaña **Configuración**.
1. En el campo **Nombre de la puerta**, haga lo siguiente.
Especifique el nombre que desea asignar a la puerta. Todos los nombres de puertas deben ser únicos dentro del flujo de trabajo. Los nombres de puertas están limitados a caracteres alfanuméricos (a-z, A-Z y 0-9), guiones (-) y guiones bajos (\$1). No se permiten espacios. No puede utilizar comillas para permitir caracteres especiales ni espacios en los nombres de las puertas.
1. (Opcional) En el campo **Número de aprobaciones**, haga lo siguiente.
Especifique el número mínimo de aprobaciones necesarias para abrir la puerta de **Aprobación**. El mínimo es `1`. El máximo es `2`. Si se omite, el valor predeterminado es `1`.
**nota**
Si desea omitir la propiedad `ApprovalsRequired`, elimine la sección `Configuration` de la puerta del archivo de definición del flujo de trabajo.
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
#### [ YAML ]
**Adición de una puerta de Aprobación a un flujo de trabajo (editor de YAML)**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **YAML**.
1. Añada una sección `Approval` y las propiedades subyacentes utilizando el siguiente ejemplo como guía. Para obtener más información, consulte [Puerta de “aprobación” de YAML](approval-ref.md) en la [Definición de flujo de trabajo en YAML](workflow-reference.md).
```
Actions:
MyApproval_01:
Identifier: aws/approval@v1
DependsOn:
- PreviousAction
Configuration:
ApprovalsRequired: 2
```
Para ver otro ejemplo, consulte [Ejemplo: Una puerta de Aprobación](workflows-approval-example.md).
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
# Configuración de notificaciones de aprobación
Puede hacer que CodeCatalyst envíe una notificación a un canal de Slack en la que se informe a los usuarios de que la ejecución de un flujo de trabajo requiere una aprobación. Los usuarios ven la notificación y hacen clic en el enlace que contiene. El enlace los lleva a una página de aprobaciones de CodeCatalyst en la que pueden aprobar o rechazar el flujo de trabajo.
También puede configurar las notificaciones para informar a los usuarios de que un flujo de trabajo ha sido aprobado, rechazado o de que la solicitud de aprobación ha caducado.
Utilice las siguientes instrucciones para configurar las notificaciones de Slack.
**Antes de empezar**
Asegúrese de haber agregado una puerta de **Aprobación** a su flujo de trabajo. Para obtener más información, consulte [Adición de una puerta de Aprobación](workflows-approval-add.md).
**Envío de notificaciones de aprobación de un flujo de trabajo a un canal de Slack**
1. Configure CodeCatalyst con Slack. Para obtener más información, consulte [Introducción a las notificaciones de Slack](getting-started-notifications.md).
1. En el proyecto de CodeCatalyst que contenga el flujo de trabajo que requiera una aprobación, habilite las notificaciones si aún no están habilitadas. Para habilitar las notificaciones:
1. Acceda al proyecto y elija **Ajustes del proyecto** en el panel de navegación.
1. En la parte superior, seleccione **Notificaciones**.
1. En **Eventos de notificación**, seleccione **Editar notificaciones**.
1. Active **Aprobación de flujo de trabajo pendiente** y elija un canal de Slack al que CodeCatalyst enviará la notificación.
1. (Opcional) Active las notificaciones adicionales para avisar a los usuarios sobre las aprobaciones aprobadas, rechazadas o vencidas. Puede activar **Ejecución del flujo de trabajo aprobada**, **Ejecución del flujo de trabajo rechazada**, **Aprobación del flujo de trabajo reemplazado** y **Tiempo de espera de la aprobación del flujo de trabajo agotado**. Junto a cada notificación, seleccione el canal de Slack al que CodeCatalyst enviará la notificación.
1. Seleccione **Save**.
# Aprobación o rechazo de la ejecución de un flujo de trabajo
Las ejecuciones de flujos de trabajo que incluyan la puerta de **Aprobación** deberán aprobarse o rechazarse. Los usuarios pueden dar su aprobación o rechazo desde:
+ la CodeCatalyst consola
+ un enlace proporcionado por un miembro del equipo;
+ una notificación automática de Slack.
Una vez que un usuario dé su aprobación o rechazo, esta decisión será irrevocable.
**nota**
Solo determinados usuarios pueden aprobar o rechazar la ejecución de un flujo de trabajo. Para obtener más información, consulte [¿Quién puede proporcionar una aprobación?](workflows-approval.md#workflows-approval-who).
**Antes de empezar**
Asegúrese de haber agregado una puerta de **Aprobación** a su flujo de trabajo. Para obtener más información, consulte [Adición de una puerta de Aprobación](workflows-approval-add.md).
**Para aprobar o rechazar un flujo de trabajo, ejecútelo desde la CodeCatalyst consola**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. En el diagrama de flujo de trabajo, seleccione la casilla que representa la puerta de **Aprobación**.
Aparece un panel lateral.
**nota**
En este momento, podrá enviar la URL de esta página a otros aprobadores si lo desea.
1. En **Decisión de revisión**, seleccione **Aprobar** o **Rechazar**.
1. (Opcional) En **Comentar - opcional**, introduzca un comentario que indique por qué ha aprobado o rechazado la ejecución del flujo de trabajo.
1. Seleccione **Enviar**.
**Aprobación o rechazo de una ejecución de flujo de trabajo desde un enlace proporcionado por un miembro del equipo**
1. Haga clic en el enlace que le envió un miembro del equipo. (Puede pedir a un miembro del equipo que lea el procedimiento anterior para obtener el enlace).
1. Inicie sesión en CodeCatalyst, si se le solicita.
Se le redirigirá a la página de aprobación de la ejecución del flujo de trabajo.
1. En **Decisión de revisión**, seleccione **Aprobar** o **Rechazar**.
1. (Opcional) En **Comentar - opcional**, introduzca un comentario que indique por qué ha aprobado o rechazado la ejecución del flujo de trabajo.
1. Seleccione **Enviar**.
**Aprobación o rechazo de una ejecución de flujo de trabajo desde una notificación automática de Slack**
1. Asegúrese de que las notificaciones de Slack estén configuradas. Consulte [Configuración de notificaciones de aprobación](workflows-approval-notify.md).
1. En Slack, en el canal al que se envió la notificación de aprobación, seleccione el enlace de la notificación de aprobación.
1. Inicie sesión en CodeCatalyst, si se le solicita.
Se le redirigirá a la página de la ejecución del flujo de trabajo.
1. En el diagrama de flujo de trabajo, seleccione la puerta de aprobación.
1. En **Decisión de revisión**, seleccione **Aprobar** o **Rechazar**.
1. (Opcional) En **Comentar - opcional**, introduzca un comentario que indique por qué ha aprobado o rechazado la ejecución del flujo de trabajo.
1. Seleccione **Enviar**.
# Puerta de “aprobación” de YAML
A continuación, se incluye la definición de YAML de la puerta de **aprobación**. Para obtener información sobre cómo utilizar esta puerta, consulte [Exigencia de aprobaciones en ejecuciones de flujos de trabajo](workflows-approval.md).
Esta definición de acción existe como una sección dentro de un archivo de definición de flujo de trabajo más amplio. Para obtener más información acerca de este archivo, consulte [Definición de flujo de trabajo en YAML](workflow-reference.md).
**nota**
La mayoría de las propiedades de YAML que se muestran a continuación tienen elementos de interfaz de usuario correspondientes en el editor visual. Para buscar un elemento de la interfaz de usuario, use **Ctrl\$1F**. El elemento aparecerá en la lista con su propiedad de YAML asociada.
```
# The workflow definition starts here.
# See Propiedades de nivel superior for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The 'Approval' gate definition starts here.
Approval:
Identifier: aws/approval@v1
DependsOn:
- another-action
Configuration:
ApprovalsRequired: number
```
## Approval
(Obligatorio)
Especifique el nombre que desea asignar a la puerta. Todos los nombres de puertas deben ser únicos dentro del flujo de trabajo. Los nombres de puertas están limitados a caracteres alfanuméricos (a-z, A-Z y 0-9), guiones (-) y guiones bajos (\$1). No se permiten espacios. No puede utilizar comillas para permitir caracteres especiales ni espacios en los nombres de las puertas.
Predeterminado: `Approval_nn`.
Interfaz de usuario correspondiente: pestaña Configuración/**Nombre de la puerta**
## Identifier
(*Approval*/**Identifier**)
(Obligatorio)
Identifica la puerta. La puerta de **aprobación** admite la versión `1.0.0`. No cambie esta propiedad a menos que desee cambiar a una versión anterior. Para obtener más información, consulte [Especificación de la versión de la acción que se va a utilizar](workflows-action-versions.md).
Predeterminado: `aws/approval@v1`.
Interfaz de usuario correspondiente: Diagrama de flujo de trabajo/Approval\$1nn/etiqueta **aws/approval@v1**
## DependsOn
(*Approval*/**DependsOn**)
(Opcional)
Especifique la acción, el grupo de acciones o la puerta que debe ejecutarse correctamente para que esta puerta se ejecute. De forma predeterminada, al añadir una puerta a un flujo de trabajo, la puerta se configura para que dependa de la última acción del flujo de trabajo. Si elimina esta propiedad, la puerta no dependerá de nada y se ejecutará primero, antes que otras acciones.
**nota**
Se debe configurar una puerta para que se ejecute antes o después de una acción, un grupo de acciones o una puerta. No se puede configurar para que se ejecute en paralelo con otras acciones, grupos de acción y puertas.
Para obtener más información sobre la funcionalidad **Depende de**, consulte [Secuenciación de puertas y acciones](workflows-gates-depends-on.md).
Interfaz de usuario correspondiente: pestaña Entradas/**Depende de**
## Configuration
(*Approval*/**Configuration**)
(Opcional)
Una sección en la que puede definir las propiedades de configuración de la puerta.
Interfaz de usuario correspondiente: pestaña **Configuración**
## ApprovalsRequired
(*Approval*/Configuration/**ApprovalsRequired**)
(Opcional)
Especifique el número mínimo de aprobaciones necesarias para abrir la puerta de **aprobación**. El mínimo es `1`. El máximo es `2`. Si se omite, el valor predeterminado es `1`.
**nota**
Si desea omitir la propiedad `ApprovalsRequired`, elimine la sección `Configuration` de la puerta del archivo de definición del flujo de trabajo.
Interfaz de usuario correspondiente: pestaña Configuración/**Número de aprobaciones**
# Configuración del comportamiento de puesta en cola de las ejecuciones
De forma predeterminada, en Amazon CodeCatalyst, cuando se ejecutan varios flujos de trabajo al mismo tiempo, CodeCatalyst los pone en cola y los procesa uno por uno, en el orden en que se iniciaron. Puede cambiar este comportamiento predeterminado especificando un *modo de ejecución*. Existen varios modos de ejecución:
+ (Predeterminado) Modo de ejecución en cola: los procesos de CodeCatalyst se ejecutan uno por uno
+ Modo de ejecución reemplazado: los procesos de CodeCatalyst se ejecutan uno por uno, y las ejecuciones más recientes sustituyen a las antiguas
+ Modo de ejecución en paralelo: los procesos de CodeCatalyst se ejecutan en paralelo
Para obtener más información acerca de las ejecuciones de flujos de trabajo, consulte [Ejecución de un flujo de trabajo](workflows-working-runs.md).
**Topics**
+ [Acerca del modo de ejecución en cola](#workflows-configure-runs-queued)
+ [Acerca del modo de ejecución reemplazado](#workflows-configure-runs-superseded)
+ [Acerca del modo de ejecución en paralelo](#workflows-configure-runs-parallel)
+ [Configuración del modo de ejecución](#workflows-configure-runs-configure)
## Acerca del modo de ejecución en cola
En el *modo de ejecución en cola*, las ejecuciones se producen en serie y las ejecuciones que están en espera forman una cola.
Las colas se forman en los puntos de acceso a las acciones y los grupos de acciones, por lo que puede tener *varias colas en el mismo flujo de trabajo* (consulte [Figure 1](#figure-1-workflow-queued-run-mode)). Cuando una ejecución en cola entra en una acción, la acción se bloquea y no puede entrar ninguna otra ejecución. Cuando la ejecución finaliza y sale de la acción, la acción se desbloquea y está lista para la siguiente ejecución.
[Figure 1](#figure-1-workflow-queued-run-mode) ejemplifica un flujo de trabajo configurado en el modo de ejecución en cola. Se muestra lo siguiente:
+ Siete ejecuciones recorriendo el flujo de trabajo.
+ Dos colas: una fuera de la entrada al origen de la entrada (**Repo:main**) y otra fuera de la entrada a la acción **BuildTestActionGroup**.
+ Dos bloques bloqueados: el origen de entrada (**Repo:main**) y el **BuildTestActionGroup**.
Así es como sucederán las cosas a medida que se ejecute el flujo de trabajo y finalice el procesamiento:
+ Cuando **Run-4d444** termine de clonar el repositorio de código fuente, saldrá de la fuente de entrada y se unirá a la cola detrás de **Run-3c333**. A continuación, **Run-5e555** entrará en el origen de entrada.
+ Cuando **Run-1a111** termine de compilar y realizar las pruebas, saldrá de la acción **BuildTestActionGroup** y entrará en la acción **DeployAction**. A continuación, **Run-2b222** entrará en la acción **BuildTestActionGroup**.
**Figura 1**: un flujo de trabajo configurado en el modo de ejecución en cola.
![\[Un flujo de trabajo configurado en el modo de ejecución en cola.\]](http://docs.aws.amazon.com/es_es/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
Utilice el modo de ejecución en cola si:
+ **Desea mantener una relación de uno a uno entre las características y las ejecuciones; estas características pueden agruparse cuando se utiliza el modo reemplazado**. Por ejemplo, cuando se combina la característica 1 en la confirmación 1, se inicia la ejecución 1, y cuando se combina la característica 2 en la confirmación 2, se inicia la ejecución 2, y así sucesivamente. Si utilizara el modo reemplazado en lugar del modo en cola, sus características (y confirmaciones) se agruparán en la ejecución que reemplazará a las demás.
+ **Quiere evitar las condiciones de carrera y los problemas inesperados que puedan producirse al utilizar el modo en paralelo**. Por ejemplo, si dos desarrolladores de software, Wang y Saanvi, inician las ejecuciones del flujo de trabajo aproximadamente al mismo tiempo para implementarlas en un clúster de Amazon ECS, la ejecución de Wang podría iniciar las pruebas de integración en el clúster mientras la ejecución de Saanvi implementa un nuevo código de aplicación en el clúster, lo que provoca que las pruebas de Wang fallen o prueben el código incorrecto. Pongamos otro ejemplo: es posible que tenga un destino que no disponga de un mecanismo de bloqueo, en cuyo caso las dos ejecuciones podrían sobrescribir los cambios de la otra de forma inesperada.
+ **Desea limitar la carga** de los recursos de computación que CodeCatalyst utiliza para procesar sus ejecuciones. Por ejemplo, si dispone de tres acciones en su flujo de trabajo, puede tener un máximo de tres ejecuciones al mismo tiempo. Imponer un límite al número de ejecuciones que se pueden realizar al mismo tiempo hace que el rendimiento de las ejecuciones sea más predecible.
+ **Desea limitar el número de solicitudes que el flujo de trabajo realiza a servicios de terceros**. Por ejemplo, su flujo de trabajo podría tener una acción de compilación que incluya instrucciones para extraer una imagen de Docker Hub. [Docker Hub limita el número de solicitudes de extracción](https://www.docker.com/increase-rate-limits) que puede realizar a un número determinado por hora y por cuenta, y si se supera el límite, se produce un bloqueo. Si utiliza el modo de ejecución en cola para reducir el rendimiento de las ejecuciones, se generarán menos solicitudes a Docker Hub por hora, lo que limitará la posibilidad de que se produzcan bloqueos y los consiguientes errores de compilación y ejecución.
**Tamaño máximo de cola**: 50
Notas sobre el **tamaño máximo de la cola**:
+ El tamaño máximo de la cola se refiere al número máximo de ejecuciones permitido en *todas las colas* del flujo de trabajo.
+ Si una cola supera las 50 ejecuciones, CodeCatalyst descarta la 51.ª ejecución y las siguientes.
**Comportamiento de error**:
Si una ejecución deja de responder mientras está siendo procesada por una acción, las ejecuciones que se produzcan después permanecerán en la cola hasta que se agote el tiempo de espera de la acción. El tiempo de espera de las acciones se agota cuando ha transcurrido una hora.
Si una ejecución falla dentro de una acción, se permite continuar con la primera ejecución que esté en la cola detrás de esta.
## Acerca del modo de ejecución reemplazado
El *modo de ejecución reemplazado* es el mismo que el *modo de ejecución en cola*, con la salvedad de que:
+ Si una ejecución en cola alcanza a otra ejecución de la cola, la ejecución posterior reemplaza (sustituye) a la anterior, y esta última se cancela y se marca como reemplazada.
+ Como resultado del comportamiento descrito en la primera viñeta, una cola solo puede incluir una ejecución cuando se utiliza el modo de ejecución reemplazado.
Utilicemos el flujo de trabajo de [Figure 1](#figure-1-workflow-queued-run-mode) como guía: si se aplica el modo de ejecución reemplazado a este flujo de trabajo, se produciría lo siguiente:
+ **Run-7g777** sustituiría a las otras dos ejecuciones de la cola y sería la única ejecución restante en la **Cola n.º 1**. **Run-6f666** y **Run-5e555** se cancelarían.
+ **Run-3c333** reemplazaría a **Run-2b222** y sería la única ejecución restante en la **Cola n.º 2**. **Run-2b222** se cancelaría.
Utilice el modo de ejecución reemplazado si desea:
+ un mejor rendimiento que con el modo en cola;
+ menos solicitudes incluso a servicios de terceros que con el modo en cola; esto es ventajoso si el servicio de terceros tiene límites de velocidad, como Docker Hub.
## Acerca del modo de ejecución en paralelo
En el *modo de ejecución en paralelo*, las ejecuciones son independientes entre sí y no tienen que esperar a que se completen las demás para iniciarse. No hay colas y el rendimiento de las ejecuciones solo está limitado por la rapidez con la que se puedan completar las acciones del flujo de trabajo.
Utilice el modo de ejecución en paralelo en entornos de desarrollo en los que cada usuario tenga su propia ramificación de características y se implemente en destinos que no compartan otros usuarios.
**importante**
Si tiene un destino compartido en el que puedan realizar implementaciones varios usuarios, como una función de Lambda en un entorno de producción, no utilice el modo en paralelo, ya que pueden producirse condiciones de carrera. Se produce una *condición de carrera* cuando las ejecuciones de un flujo de trabajo en paralelo intentan cambiar un recurso compartido al mismo tiempo, lo que genera resultados impredecibles.
**Número máximo de ejecuciones en paralelo**: 1000 por espacio de CodeCatalyst
## Configuración del modo de ejecución
Puede configurar el modo de ejecución en cola, reemplazado o en paralelo. El valor predeterminado es ejecución en cola.
Al cambiar el modo de ejecución del modo en cola o reemplazado al modo en paralelo, CodeCatalyst cancela las ejecuciones que estén en cola y permite que las ejecuciones que una acción está procesando actualmente finalicen antes de cancelarlas.
Al cambiar el modo de ejecución del modo en paralelo al modo en cola o reemplazado, CodeCatalyst permite que se completen todas las ejecuciones en paralelo que se estén ejecutando actualmente. Todas las ejecuciones que se inicien después de cambiar el modo de ejecución al modo en cola o reemplazado utilizarán el nuevo modo.
------
#### [ Visual ]
**Cambio del modo de ejecución mediante el editor visual**
1. Abra la consola de CodeCatalyst en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Seleccione **Editar**.
1. En la parte superior derecha, seleccione **Propiedades del flujo de trabajo**.
1. Expanda **Avanzado** y, en **Modo de ejecución**, elija una de las siguientes opciones:
1. **En cola**: consulte [Acerca del modo de ejecución en cola](#workflows-configure-runs-queued)
1. **Reemplazado**: consulte [Acerca del modo de ejecución reemplazado](#workflows-configure-runs-superseded)
1. **En paralelo**: consulte [Acerca del modo de ejecución en paralelo](#workflows-configure-runs-parallel)
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
#### [ YAML ]
**Cambio del modo de ejecución mediante el editor de YAML**
1. Abra la consola de CodeCatalyst en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Seleccione **Editar**.
1. Elija **YAML**.
1. Añada la propiedad `RunMode`, de la siguiente manera:
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
Para obtener más información, consulte la descripción de la propiedad `RunMode` en la sección [Propiedades de nivel superior](workflow-reference.md#workflow.top.level) de la [Definición de flujo de trabajo en YAML](workflow-reference.md).
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
# Almacenamiento en caché de archivos entre ejecuciones de flujos de trabajo
Cuando el almacenamiento en caché de archivos está activado, las acciones de compilación y prueba guardan los archivos del disco en una memoria caché y los restauran desde esa memoria caché en las siguientes ejecuciones del flujo de trabajo. El almacenamiento en caché reduce la latencia provocada por la creación o descarga de dependencias que no han cambiado entre ejecuciones. CodeCatalyst también es compatible con las cachés alternativas, que se pueden usar para restaurar cachés parciales que contienen algunas de las dependencias necesarias. Esto ayuda a reducir los impactos en la latencia de un error de caché.
**nota**
El almacenamiento en caché de archivos solo está disponible con las acciones de CodeCatalyst [compilación](build-workflow-actions.md) y [prueba](test-workflow-actions.md) de Amazon, y solo cuando están configuradas para usar el [tipo de **EC2**procesamiento](workflows-working-compute.md#compute.types).
**Topics**
+ [Acerca del almacenamiento en caché de archivos](#workflows-caching.files)
+ [Creación de una caché](#workflows-caching.fallback)
+ [Restricciones de almacenamiento en caché de archivos](#workflows-caching.constraints)
## Acerca del almacenamiento en caché de archivos
El almacenamiento en caché de archivos permite organizar los datos en varias cachés, a las que se hace referencia en la propiedad `FileCaching`. Cada caché guarda un directorio especificado por una ruta determinada. El directorio especificado se restaurará en futuras ejecuciones del flujo de trabajo. A continuación, se muestra un ejemplo de fragmento de código de YAML para almacenar en caché con varias cachés denominadas `cacheKey1` y `cacheKey2`.
```
Actions:
BuildMyNpmApp:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
Caching:
FileCaching:
cacheKey1:
Path: file1.txt
RestoreKeys:
- restoreKey1
cacheKey2:
Path: /root/repository
RestoreKeys:
- restoreKey2
- restoreKey3
```
**nota**
CodeCatalyst utiliza el almacenamiento en caché multicapa, que consiste en una caché local y una caché remota. Cuando las flotas aprovisionadas o las máquinas bajo demanda detectan un error de caché en una caché local, las dependencias se restaurarán desde una caché remota. Como resultado, es posible que algunas ejecuciones de acciones experimenten latencia debido a la descarga de una caché remota.
CodeCatalyst aplica restricciones de acceso a la caché para garantizar que una acción de un flujo de trabajo no pueda modificar las cachés de un flujo de trabajo diferente. Esto protege cada flujo de trabajo de otros flujos que podrían generar datos incorrectos que afectarían a las compilaciones o implementaciones. Las restricciones se aplican con alcances de caché que aíslan las cachés para cada emparejamiento de flujos de trabajo y ramificaciones. Por ejemplo, el `workflow-A` en la ramificación `feature-A` tiene una caché de archivos diferente al `workflow-A` en la ramificación hermana `feature-B`.
Los errores de caché se producen cuando un flujo de trabajo busca una caché de archivos específica y no puede encontrarla. Esto puede ocurrir por varios motivos, por ejemplo, cuando se crea una nueva ramificación o cuando se hace referencia a una nueva caché y aún no se ha creado. También puede ocurrir cuando una caché caduca, lo que de forma predeterminada ocurre 14 días después de su último uso. Para mitigar las pérdidas de memoria caché y aumentar la tasa de visitas a la memoria caché, CodeCatalyst es compatible con las cachés alternativas. Las cachés alternativas son cachés adicionales de respaldo y ofrecen la oportunidad de restaurar cachés parciales, que pueden ser una versión anterior de una caché. Para restaurar una memoria caché, primero se busca una coincidencia de `FileCaching` para el nombre de la propiedad y, si no se encuentra, se evalúa `RestoreKeys`. Si hay un error de caché tanto para el nombre de la propiedad como para todas las `RestoreKeys`, el flujo de trabajo seguirá ejecutándose, ya que el almacenamiento en caché es el mejor método posible y no está garantizado.
## Creación de una caché
Puede seguir estas instrucciones para añadir una caché a su flujo de trabajo.
------
#### [ Visual ]
**Cómo añadir una caché mediante el editor visual**
1. [Abra la CodeCatalyst consola en https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Seleccione **Editar**.
1. Elija **Visual**.
1. En el diagrama de flujo de trabajo, elija la acción a la que quiera añadir la caché.
1. Elija **Configuración**.
1. En **Almacenamiento en caché de archivos - opcional**, seleccione **Añadir caché** e introduzca la información en los campos de la siguiente manera:
**Clave**
Especifique el nombre de la propiedad de su caché principal. Los nombres de propiedades de caché deben ser únicos en el flujo de trabajo. Puede haber hasta cinco entradas de cada acción en `FileCaching`.
**Ruta**
Especifique la ruta asociada a la memoria caché.
**Restaure claves - opcional**
Especifique la clave de restauración para utilizarla como alternativa cuando no se pueda encontrar la propiedad de caché principal. Los nombres de clave de restauración deben ser únicos en el flujo de trabajo. Puede haber hasta cinco entradas de cada acción en `RestoreKeys`.
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
#### [ YAML ]
**Cómo añadir una caché mediante el editor YAML**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Seleccione **Editar**.
1. Elija **YAML**.
1. En una acción de flujo de trabajo, agregue código similar al siguiente:
```
action-name:
Configuration:
Steps: ...
Caching:
FileCaching:
key-name:
Path: file-path
# # Specify any additional fallback caches
# RestoreKeys:
# - restore-key
```
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
## Restricciones de almacenamiento en caché de archivos
A continuación enumeramos las restricciones para nombres de propiedades y `RestoreKeys`:
+ Los nombres deben ser únicos dentro de un flujo de trabajo.
+ Los nombres están limitados a caracteres alfanuméricos (A-Z, a-z y 0-9), guiones (-) y guiones bajos (\$1).
+ Los nombres pueden tener un máximo de 180 caracteres.
+ Puede haber hasta cinco cachés para cada acción en `FileCaching`.
+ Puede haber hasta cinco entradas de cada acción en `RestoreKeys`.
Estas son las restricciones para las rutas:
+ No se permiten los asteriscos (\$1).
+ Las rutas pueden tener un máximo de 255 caracteres.
# Visualización del estado y los detalles de la ejecución de un flujo de trabajo
EN Amazon CodeCatalyst, puedes ver el estado y los detalles de una sola ejecución del flujo de trabajo o de varias ejecuciones al mismo tiempo.
Para obtener una lista de posibles estados de ejecución, consulte [Estados de ejecución de un flujo de trabajo](workflows-view-run-status.md).
**nota**
También puede ver el estado del flujo de trabajo, que es diferente del estado de la *ejecución* del flujo de trabajo. Para obtener más información, consulte [Visualización del estado de un flujo de trabajo](workflows-view-status.md).
Para obtener más información acerca de las ejecuciones de flujos de trabajo, consulte [Ejecución de un flujo de trabajo](workflows-working-runs.md).
**Topics**
+ [Visualización del estado y los detalles de una sola ejecución](#workflows-view-run-single)
+ [Visualización del estado y los detalles de todas las ejecuciones del proyecto](#workflows-view-run-all)
+ [Visualización del estado y los detalles de todas las ejecuciones de un flujo de trabajo específico](#workflows-view-run-wf)
+ [Visualización de ejecuciones de un flujo de trabajo en el diagrama de flujo de trabajo](#workflows-view-run-wf-diagram)
## Visualización del estado y los detalles de una sola ejecución
Es posible que desee ver el estado y los detalles de una sola ejecución de flujo de trabajo para comprobar si se ha ejecutado correctamente, a qué hora se ha completado o quién o qué la ha iniciado.
**Visualización del estado y los detalles de una sola ejecución**
1. Abre la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. En el nombre del flujo de trabajo, seleccione **Ejecuciones**.
1. En **Historial de ejecuciones**, en la columna **ID de ejecución**, seleccione una ejecución. Por ejemplo, `Run-95a4d`.
1. Bajo el nombre de la ejecución, elija una de las siguientes opciones:
+ **Visual** para ver un diagrama de flujo de trabajo que muestre las acciones de la ejecución del flujo de trabajo y su estado (véase [Estados de ejecución de un flujo de trabajo](workflows-view-run-status.md)). Esta vista también muestra el repositorio y la ramificación de origen utilizados durante la ejecución.
En el diagrama del flujo de trabajo, elija una acción para ver detalles como los registros, los informes y los resultados generados por la acción durante la ejecución. La información que se muestra depende del tipo de acción que se seleccione. Para obtener más información acerca de cómo visualizar los archivos de compilación o implementación, consulte [Consulta de los resultados de una acción de compilación](build-view-results.md) o [Visualización de los registros de implementación](deploy-deployment-logs.md).
+ **YAML** para ver el archivo de definición del flujo de trabajo que se utilizó para la ejecución.
+ **Artefactos** para ver los artefactos producidos por la ejecución del flujo de trabajo. Para obtener más información acerca de los artefactos, consulte [Cómo compartir artefactos y archivos entre acciones](workflows-working-artifacts.md).
+ **Informes** para ver los informes de las pruebas y otros tipos de informes producidos por la ejecución del flujo de trabajo. Para obtener más información acerca de los informes, consulte [Tipos de informes de calidad](test-workflow-actions.md#test-reporting).
+ **Variables** para ver las variables de salida generadas por la ejecución del flujo de trabajo. Para obtener más información acerca de las variables, consulte [Uso de variables en flujos de trabajo](workflows-working-with-variables.md).
**nota**
Si se ha eliminado el flujo de trabajo principal de la ejecución, aparecerá un mensaje que indicará este hecho en la parte superior de la página de detalles de la ejecución.
## Visualización del estado y los detalles de todas las ejecuciones del proyecto
Es posible que quiera ver el estado y los detalles de todas las ejecuciones del flujo de trabajo del proyecto para comprender la cantidad de actividad del flujo de trabajo que se está produciendo en el proyecto y obtener información sobre el estado general de los flujos de trabajo.
**Visualización del estado y los detalles de todas las ejecuciones del proyecto**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. En **Flujos de trabajo**, elija **Ejecuciones**.
Se muestran todas las ejecuciones de todos los flujos de trabajo, en todas las ramificaciones y en todos los repositorios del proyecto.
La página incluye las siguientes columnas:
+ **ID de ejecución**: el identificador único de la ejecución. Seleccione el enlace del ID de ejecución para ver información detallada sobre la ejecución.
+ **Estado**: el estado de procesamiento de la ejecución del flujo de trabajo. Para obtener más información acerca de los estados de ejecución, consulte [Estados de ejecución de un flujo de trabajo](workflows-view-run-status.md).
+ **Desencadenador**: la persona, la confirmación, la solicitud de extracción (PR) o la programación que haya iniciado la ejecución del flujo de trabajo. Para obtener más información, consulte [Inicio de un flujo de trabajo y ejecución automática mediante desencadenadores](workflows-add-trigger.md).
+ **Flujo de trabajo**: el nombre del flujo de trabajo para el que se inició una ejecución y el repositorio y la ramificación de origen donde resida el archivo de definición del flujo de trabajo. Puede que tenga que expandir el ancho de columna para ver esta información.
**nota**
Si esta columna está configurada como **No disponible**, normalmente se debe a que el flujo de trabajo asociado se ha eliminado o trasladado.
+ **Hora de inicio**: hora a la que se ha iniciado la ejecución del flujo de trabajo.
+ **Duración**: cuánto tiempo tardó en procesarse la ejecución del flujo de trabajo. Si aparecen duraciones muy largas o muy cortas, eso puede indicar que ha habido problemas.
+ **Hora de finalización**: hora a la que finalizó la ejecución del flujo de trabajo.
## Visualización del estado y los detalles de todas las ejecuciones de un flujo de trabajo específico
Es posible que desee ver el estado y los detalles de todas las ejecuciones asociadas a un flujo de trabajo específico para comprobar si alguna ejecución está generando cuellos de botella en el flujo de trabajo o para determinar qué ejecuciones están actualmente en curso o se han completado.
**Visualización del estado y los detalles de todas las ejecuciones de un flujo de trabajo específico**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. En el nombre del flujo de trabajo, seleccione **Ejecuciones**.
Aparecen las ejecuciones asociadas al flujo de trabajo seleccionado.
La página se divide en dos secciones:
+ **Ejecuciones activas**: muestra las ejecuciones en curso. Estas ejecuciones estarán en uno de los siguientes estados: **En curso**.
+ **Historial de ejecuciones**: muestra las ejecuciones que se han completado (es decir, que no están en curso).
Para obtener más información acerca de los estados de ejecución, consulte [Estados de ejecución de un flujo de trabajo](workflows-view-run-status.md).
## Visualización de ejecuciones de un flujo de trabajo en el diagrama de flujo de trabajo
Puede ver el estado de todas las ejecuciones de un flujo de trabajo a medida que avancen en el flujo de trabajo. Las ejecuciones aparecen en el diagrama de flujo de trabajo (a diferencia de en una vista de lista). Esto le presenta una representación visual de qué ejecuciones se están procesando mediante qué acciones y qué ejecuciones están en espera en una cola.
**Visualización del estado de varias ejecuciones a medida que avanzan en conjunto en un flujo de trabajo**
**nota**
Este procedimiento solo se aplica si el flujo de trabajo utiliza el modo de ejecución en cola o reemplazado. Para obtener más información, consulte [Configuración del comportamiento de puesta en cola de las ejecuciones](workflows-configure-runs.md).
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Elija el proyecto.
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
**nota**
Asegúrese de que está viendo una página de un flujo de trabajo y no una página de una ejecución.
1. Seleccione la pestaña **Último estado** en la esquina superior izquierda.
Aparecerá un diagrama de flujo de trabajo.
1. Revise el diagrama de flujo de trabajo. El diagrama muestra todas las ejecuciones que están actualmente en curso dentro del flujo de trabajo y las últimas ejecuciones que han finalizado. Más concretamente:
+ Las ejecuciones que aparecen en la parte superior, antes de **Orígenes**, están en cola y esperando para empezar.
+ Las ejecuciones que aparecen entre acciones están en cola y esperando a ser procesadas por la siguiente acción.
+ Las ejecuciones que aparecen dentro de una acción están 1) siendo procesadas por la acción actualmente, 2) la acción acaba de terminar de procesarlas o 3) no han sido procesadas por la acción (normalmente porque una acción anterior ha fallado).