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.
Automatización del inicio de las canalizaciones mediante desencadenadores y filtrado
Los desencadenadores permiten configurar la canalización para que se inicie con un tipo de evento concreto o filtrado, por ejemplo, cuando se detecta un cambio en una ramificación específica o en una solicitud de extracción. Los activadores se pueden configurar para las acciones de origen con conexiones que utilizan la CodeStarSourceConnection acción en CodePipeline, por ejemplo GitHub, Bitbucket y GitLab. Para obtener más información acerca de las acciones de origen que utilizan conexiones, consulte Agrega proveedores de fuentes de terceros a las canalizaciones mediante CodeConnections.
Las acciones de origen, como CodeCommit S3, utilizan la detección automática de cambios para iniciar las canalizaciones cuando se realiza un cambio. Para obtener más información, consulte CodeCommit acciones de origen y EventBridge.
Puede especificar desencadenadores mediante la consola o la CLI.
Los tipos de filtros se especifican de la siguiente manera:
-
Sin filtro
Esta configuración de desencadenador inicia la canalización con cualquier inserción a la ramificación predeterminada especificada como parte de la configuración de la acción.
-
Especificar filtro
Añada un filtro que inicie la canalización con un filtro específico, por ejemplo, en los nombres de las ramificaciones de una inserción de código, y obtenga la confirmación exacta. Esto también configura la canalización para que no se inicie automáticamente cuando se produzcan cambios.
-
Inserción
-
Las combinaciones de filtros válidas son:
-
Etiquetas Git
Incluir o excluir
-
sucursales
Incluir o excluir
-
ramas + rutas de archivos
Incluir o excluir
-
-
-
Solicitud de extracción
-
Las combinaciones de filtros válidas son:
-
sucursales
Incluir o excluir
-
ramas + rutas de archivos
Incluir o excluir
-
-
-
-
No detectar cambios
Este tipo de filtro no añade ningún desencadenador y la canalización no se inicia automáticamente aunque se produzcan cambios.
La siguiente tabla proporciona opciones de filtro válidas para cada tipo de evento. En la tabla también se muestran qué configuraciones de desencadenador son verdaderas o falsas de forma predeterminada para la detección automática de cambios en la configuración de la acción.
| Configuración de desencadenadores | Tipo de evento | Opciones de filtro | Detección de cambios |
|---|---|---|---|
| Agregar un desencadenador, sin filtro | Ninguno | Ninguno | true |
| Agregar un desencadenador: filtrar en la inserción de código | evento de inserción | Etiquetas de Git, ramificaciones, rutas de archivo | false |
| Agregar un desencadenador: filtrar las solicitudes de inserción | solicitudes de extracción | ramificaciones, rutas de archivo | false |
| Sin desencadenador: no detectar | Ninguno | Ninguno | false |
nota
Este tipo de desencadenador utiliza la detección automática de cambios (como el tipo de desencadenador Webhook). Los proveedores de acciones de origen que utilizan este tipo de activador son conexiones configuradas para la inserción de código (Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com y GitLab autogestionadas).
Para ver las definiciones de los campos y obtener más información sobre los desencadenantes, consulte
Para obtener una lista de las definiciones de campos de la estructura JSON, consulte triggers.
Para el filtrado, se admiten patrones de expresiones regulares en formato glob, tal y como se detalla en Trabajar con patrones glob en la sintaxis.
nota
En algunos casos, en el caso de las canalizaciones con desencadenadores que se filtran en rutas de archivo, es posible que una canalización no se inicie al crear por primera vez una ramificación con un filtro de ruta de archivo. Para obtener más información, consulte Es posible que las canalizaciones con conexiones que utilicen el filtrado de desencadenadores por rutas de archivo no se inicien al crear la ramificación.
Consideraciones sobre los filtros de desencadenadores
Las siguientes consideraciones se aplican cuando se utilizan desencadenadores.
-
No puede añadir más de un activador por acción de origen.
-
Puede añadir varios tipos de filtros a un disparador. Para ver un ejemplo, consulta 4: Un disparador con dos tipos de filtros push con inclusiones y exclusiones contradictorias .
-
En el caso de un desencadenador con filtros de ramificaciones y rutas de archivo, al insertar la ramificación por primera vez, la canalización no se ejecutará debido a que no se podrá acceder a la lista de archivos modificados para la ramificación recién creada.
-
La fusión de una solicitud de extracción puede provocar la ejecución de dos canalizaciones en los casos en que las configuraciones de activación push (filtro de ramas) y solicitud de extracción (filtro de ramas) se crucen.
-
En el caso de un filtro que activa tu canalización en función de eventos de solicitudes de extracción, en el caso del tipo de evento de solicitud de extracción cerrada, el proveedor de repositorios externo de tu conexión podría tener un estado diferente para un evento de fusión. Por ejemplo, en Bitbucket, el evento Git de una fusión no es un evento de cierre de una solicitud de extracción. Sin embargo GitHub, en el caso de fusionar una solicitud de extracción, se cierra. Para obtener más información, consulte Extraiga los eventos de solicitud para activarlos por proveedor.
Extraiga los eventos de solicitud para activarlos por proveedor
La siguiente tabla proporciona un resumen de los eventos de Git, como el cierre de solicitudes de extracción, que dan como resultado los tipos de eventos de solicitud de extracción por proveedor.
| Proveedor de repositorios para tu conexión | ||||
|---|---|---|---|---|
| Evento de relaciones públicas como activador | Bitbucket | GitHub | SÍ | GitLab |
| Abrir: esta opción activa la canalización cuando se crea una solicitud de extracción para la ruta de la rama o el archivo. | La creación de una solicitud de extracción da como resultado un evento de OpenGit. | La creación de una solicitud de extracción da como resultado un evento de OpenGit. | La creación de una solicitud de extracción da como resultado un evento de OpenGit. | La creación de una solicitud de extracción da como resultado un evento de OpenGit. |
| Actualización: esta opción activa la canalización cuando se publica una revisión de una solicitud de extracción para la ruta de la rama o el archivo. | La publicación de una actualización da como resultado un evento Git actualizado. | La publicación de una actualización da como resultado un evento Git actualizado. | La publicación de una actualización da como resultado un evento Git actualizado. | La publicación de una actualización da como resultado un evento Git actualizado. |
| Cerrado: esta opción activa la canalización cuando se cierra una solicitud de incorporación de cambios para la ruta de la rama o el archivo. | Si se fusiona una solicitud de cambios en Bitbucket, se produce un evento de Git cerrado. Importante: si se cierra manualmente una solicitud de cambios en Bitbucket sin fusionarla, no se produce un evento de Git cerrado. | Al fusionar o cerrar manualmente una solicitud de cambios, se produce un evento de Git cerrado. | Al fusionar o cerrar manualmente una solicitud de cambios, se produce un evento de Git cerrado. | Al fusionar o cerrar manualmente una solicitud de cambios, se produce un evento de Git cerrado. |
Ejemplos de filtros de desencadenador
En el caso de una configuración de Git con filtros para los tipos de eventos de solicitudes de inserción y extracción, los filtros especificados pueden entrar en conflicto entre sí. A continuación, se muestran ejemplos de combinaciones de filtros válidas para eventos de solicitudes de inserción y extracción. Un disparador puede contener varios tipos de filtros, como dos tipos de filtros de inserción en la configuración del disparador, y los tipos de filtro de solicitud de inserción y extracción utilizarán una operación OR entre ellos, lo que significa que cualquier coincidencia iniciará la canalización. Del mismo modo, cada tipo de filtro puede incluir varios filtros, como FilePaths y ramificaciones; estos filtros utilizarán una operación AND, lo que significa que solo una coincidencia completa iniciará la canalización. Cada tipo de filtro puede contener inclusiones y exclusiones, y estos utilizarán una operación AND entre ellos, lo que significa que solo una coincidencia completa iniciará la canalización. Los nombres incluidos en la opción de inclusión/exclusión, como los nombres de las ramas, utilizan una operación O. Si hay un conflicto, por ejemplo, entre dos filtros push, por ejemplo, si uno incluye la main rama y el otro la excluye, el valor predeterminado es excluir. La siguiente lista resume las operaciones de cada parte del objeto de configuración de Git.
Para obtener una lista de las definiciones de campos de la estructura JSON y una referencia detallada sobre las inclusiones y exclusiones, consulte. triggers
ejemplo 1: Un tipo de filtro con filtros para las ramas y las rutas de los archivos (operación AND)
Para un solo tipo de filtro, como el de una solicitud de extracción, puedes combinar filtros, y estos filtros utilizarán una operación AND, lo que significa que solo una coincidencia completa iniciará la canalización. El siguiente ejemplo muestra una configuración de Git para un tipo de evento push con dos filtros (filePathsybranches) diferentes. En el siguiente ejemplo, filePaths utilizará la operación AND con branches:
{ "filePaths": { "includes": ["common/**/*.js"] }, "branches": { "includes": ["feature/**"] } }
Con la configuración de Git anterior, este ejemplo muestra un evento que iniciará la ejecución de la canalización, ya que la operación AND se realiza correctamente. En otras palabras, common/app.js se incluye la ruta del archivo para el filtro, que inicia la canalización como AND aunque la rama refs/heads/feature/triggers especificada no haya tenido ningún impacto.
{ "ref": "refs/heads/feature/triggers", ... "commits": [ { ... "modified": [ "common/app.js" ] ... } ] }
En el siguiente ejemplo, se muestra un evento de un activador con la configuración anterior que no iniciará la ejecución de la canalización porque la rama puede filtrar, pero la ruta del archivo no.
{ "ref": "refs/heads/feature/triggers", ... "commits": [ { ... "modified": [ "src/Main.java" ] ... } ] }
ejemplo 2: Incluye y excluye el uso de una operación AND entre ellas
Los filtros de activación, como la ramificación en un solo tipo de evento de solicitud de extracción, utilizan una operación AND entre las inclusiones y las exclusiones. Esto permite configurar varios desencadenadores para iniciar la ejecución en la misma canalización. El siguiente ejemplo muestra una configuración de activación con un único tipo de filtro (branches) en el objeto de configuración para un evento push. ExcludesLas operaciones Includes y serán AND, lo que significa que si una rama coincide con un patrón de exclusión (como feature-branch en el ejemplo), la canalización no se activará a menos que una inclusión también coincida. Si el patrón de inclusión coincide, como en el caso de la ramificación main, se desencadenará la canalización.
Para el siguiente ejemplo, JSON:
-
Al enviar una confirmación a la
mainrama, se activará la canalización -
Enviar una confirmación a la
feature-branchsucursal no activará la canalización.
{ "branches": { "Includes": [ "main" ], "Excludes": [ "feature-branch" ] }
ejemplo 3: Un disparador con tipos de filtros de solicitud de pulsar y tirar (operación OR), filtros para rutas de archivos y ramas (operación AND) e incluir/excluir (operación AND)
Los objetos de configuración del disparador, como un disparador que contiene un tipo de evento de inserción y un tipo de evento de solicitud de extracción, utilizan una operación OR entre los dos tipos de eventos. El siguiente ejemplo muestra una configuración de activación con un tipo de evento de inserción con la main rama incluida y un tipo de evento de solicitud de extracción con la misma rama main excluida. Además, el tipo de evento de inserción tiene una ruta de archivo LICENSE.txt excluida y una ruta de archivo README.MD incluida. Para el segundo tipo de evento, una solicitud de extracción que se encuentre Created en la feature-branch sucursal Closed o en ella (incluida) inicia la canalización, y la canalización no se inicia al crear o cerrar una solicitud de extracción en una feature-branch-2 o varias main sucursales (excluidas). Las Excludes operaciones Includes y serán AND, con un conflicto por defecto con la exclusión. Por ejemplo, para un evento de solicitud de extracción en la feature-branch rama (incluido en la solicitud de extracción), mientras que la feature-branch rama está excluida para el tipo de evento de inserción, el valor predeterminado será excluir.
Para el siguiente ejemplo,
-
Al enviar una confirmación a la
mainrama (incluida) de la ruta delREADME.MDarchivo (incluida), se activará la canalización. -
En la
feature-branchrama (excluida), si se pulsa una confirmación, no se activará la canalización. -
En la rama incluida, al editar la ruta del
README.MDarchivo (incluida) se activa la canalización. -
En la rama incluida, la edición de la ruta del
LICENSE.TXTarchivo (excluida) no activa la canalización. -
En la
feature-branchrama, cerrar una solicitud de extracción para la ruta delREADME.MDarchivo (incluida en el evento de inserción) no activará la canalización, ya que el tipo de evento de inserción especifica lafeature-branchrama como excluida y, por lo tanto, el conflicto predeterminado es la exclusión.
En la siguiente imagen se muestra la configuración.
El siguiente es el ejemplo de JSON para la configuración.
"triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "branches": { "includes": [ "main" ], "excludes": [ "feature-branch", "feature-branch-2" ] }, "filePaths": { "includes": [ "README.md" ], "excludes": [ "LICENSE.txt" ] } } ], "pullRequest": [ { "events": [ "CLOSED", "OPEN" ], "branches": { "includes": [ "feature-branch" ], "excludes": [ "feature-branch-2", "main" ] } } ] } } ] },
ejemplo 4: Un disparador con dos tipos de filtros push con inclusiones y exclusiones contradictorias
La siguiente imagen muestra un tipo de filtro push que especifica el filtro en la etiqueta release-1 (incluido). Se ha añadido un segundo tipo de filtro de empuje que especifica que se debe filtrar en la rama main (incluido) y no iniciar si se empuja hacia las feature* ramas (excluido).
Para el ejemplo siguiente:
-
Si presionas una opción desde la etiqueta
release-1(incluida para el primer filtro de inserción) de lafeature-branchrama (excluida, comofeature*en el caso del segundo filtro de inserción), no se activará la canalización, ya que los dos tipos de eventos serán AND. -
Si presionas una liberación desde la
mainrama (incluida en el segundo filtro Push), se iniciará la canalización.
El siguiente ejemplo de la página de edición muestra los dos tipos de filtros push y su configuración para incluir y excluir.
El siguiente es el ejemplo de JSON para la configuración.
"triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "tags": { "includes": [ "release-1" ] } }, { "branches": { "includes": [ "main*" ], "excludes": [ "feature*" ] } } ] } } ] },
ejemplo 5: El disparador está configurado mientras que la configuración de acción predeterminada BranchName se utiliza para un inicio manual
El BranchName campo predeterminado de configuración de acciones define una sola rama que se usará cuando la canalización se inicie manualmente, mientras que los activadores con filtros se pueden usar para cualquier rama o ramas que especifique.
El siguiente es el ejemplo de JSON para la configuración de acciones que muestra el BranchName campo.
{ "name": "Source", "actions": [ { "name": "Source", "actionTypeId": { "category": "Source", "owner": "AWS", "provider": "CodeStarSourceConnection", "version": "1" }, "runOrder": 1, "configuration": { "BranchName": "main", "ConnectionArn": "ARN", "DetectChanges": "false", "FullRepositoryId": "owner-name/my-bitbucket-repo", "OutputArtifactFormat": "CODE_ZIP" }, "outputArtifacts": [ { "name": "SourceArtifact" } ], "inputArtifacts": [], "region": "us-west-2", "namespace": "SourceVariables" } ],
El siguiente ejemplo de salida de la acción muestra que se utilizó la rama principal predeterminada cuando la canalización se inició manualmente.
El siguiente ejemplo de salida de acción muestra la solicitud de extracción y la rama que se utilizaron para el desencadenador cuando se filtraron por solicitud de extracción.
