Compartir vía

Desencadenar una canalización después de otra

  • Artículo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Los productos grandes tienen varios componentes que dependen unos de otros. Estos componentes suelen compilarse de forma independiente. Cuando cambia un componente de nivel superior (por ejemplo, una biblioteca), las dependencias de nivel inferior deben volver a generarse y validarse.

En situaciones como estas, agregue un desencadenador de canalización para ejecutar la canalización tras la finalización correcta de la canalización de desencadenamiento.

Nota:

Anteriormente, es posible que haya usado el editor clásico para la canalización YAML y haya configurado desencadenadores de finalización de compilación en la interfaz de usuario. Aunque ese modelo sigue funcionando, ya no se recomienda. El enfoque recomendado es especificar desencadenadores de canalización directamente dentro del archivo YAML. Los desencadenadores de finalización de compilación definidos en el editor clásico tienen varios inconvenientes, que ahora se han solucionado en los desencadenadores de canalización. Por ejemplo, no hay ninguna manera de desencadenar una canalización en la misma rama que la de la canalización de desencadenamiento mediante desencadenadores de finalización de compilación.

Configuración de desencadenadores de recursos de canalización

Para desencadenar una canalización tras la finalización de otra, configure un desencadenador de recursos de canalización.

En el ejemplo siguiente se configura un desencadenador de recursos de canalización para que una canalización llamada app-ci se ejecute después de que se complete cualquier ejecución de la canalización security-lib-ci.

Este ejemplo tiene las dos canalizaciones siguientes.

  • security-lib-ci: esta canalización se ejecuta primero.

    # security-lib-ci YAML pipeline
steps:
- bash: echo "The security-lib-ci pipeline runs first"

  • app-ci: esta canalización tiene un desencadenador de recursos de canalización que configura la canalización app-ci para que se ejecute automáticamente cada vez que se complete una ejecución de la canalización security-lib-ci.

    # app-ci YAML pipeline
# We are setting up a pipeline resource that references the security-lib-ci
# pipeline and setting up a pipeline completion trigger so that our app-ci
# pipeline runs when a run of the security-lib-ci pipeline completes
resources:
  pipelines:
  - pipeline: securitylib # Name of the pipeline resource.
    source: security-lib-ci # The name of the pipeline referenced by this pipeline resource.
    project: FabrikamProject # Required only if the source pipeline is in another project
    trigger: true # Run app-ci pipeline when any run of security-lib-ci completes

steps:
- bash: echo "app-ci runs after security-lib-ci completes"
  • - pipeline: securitylib especifica el nombre del recurso de canalización. Use la etiqueta definida aquí al hacer referencia al recurso de canalización desde otras partes de la canalización, como al usar variables de recursos de canalización o descargar artefactos.
  • source: security-lib-ci especifica el nombre de la canalización a la que hace referencia este recurso de canalización. Puede recuperar el nombre de una canalización del portal de Azure DevOps en varios lugares, como la página de aterrizaje de Pipelines. De forma predeterminada, las canalizaciones reciben el nombre del repositorio que las contiene. Para actualizar el nombre de una canalización, consulte Configuración de canalizaciones. Si la canalización está contenida en una carpeta, incluya el nombre de la carpeta, incluido el inicial \, por ejemplo \security pipelines\security-lib-ci.
  • project: FabrikamProject: si la canalización de desencadenamiento está en otro proyecto de Azure DevOps, debe especificar el nombre del proyecto. Esta propiedad es opcional si la canalización de origen y la canalización desencadenada están en el mismo proyecto. Si especifica este valor y la canalización no se desencadena, consulte la nota al final de esta sección.
  • trigger: true: use esta sintaxis para desencadenar la canalización cuando se complete cualquier versión de la canalización de origen. Consulte las secciones siguientes de este artículo para saber cómo filtrar qué versiones de la canalización de origen que se completa desencadenarán una ejecución. Cuando se especifican filtros, la ejecución de la canalización de origen debe coincidir con todos los filtros para desencadenar una ejecución.

Si la canalización de desencadenamiento y la canalización desencadenada usan el mismo repositorio, ambas canalizaciones se ejecutarán con la misma confirmación cuando una desencadene la otra. Esto resulta útil si la primera canalización compila el código y la segunda lo prueba. Sin embargo, si las dos canalizaciones usan repositorios diferentes, la canalización desencadenada usará la versión del código de la rama especificada por la configuración Default branch for manual and scheduled builds, como se describe en Consideraciones sobre la rama en los desencadenadores de finalización de canalización.

Nota:

En algunos escenarios, la rama predeterminada para compilaciones manuales y compilaciones programadas no incluye un prefijo refs/heads. Por ejemplo, la rama predeterminada se puede establecer en main en lugar de en refs/heads/main. En este escenario, un desencadenador de un proyecto diferente no funciona. Si tiene problemas al establecer project en un valor distinto al de la canalización de destino, puede actualizar la rama predeterminada para incluir refs/heads cambiando su valor por otra rama y, después, cambiándolo de nuevo por la rama predeterminada que quiera usar.

No se admite la configuración de desencadenadores de finalización de canalización en plantillas YAML. Todavía puede definir recursos de canalización en plantillas.

Filtros de rama

Opcionalmente, puede especificar las ramas que se van a incluir o excluir al configurar el desencadenador. Si especifica filtros de rama, se desencadena una nueva canalización cada vez que se completa correctamente una ejecución de canalización de origen que coincida con los filtros de rama. En el ejemplo siguiente, la canalización app-ci se ejecuta si security-lib-ci se completa en cualquier rama releases/*, excepto en releases/old*.

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        exclude:
        - releases/old*

Para desencadenar la canalización secundaria para diferentes ramas para las que se desencadena el elemento primario, incluya todos los filtros de rama para los que se desencadena el elemento primario. En el ejemplo siguiente, la canalización app-ci se ejecuta si security-lib-ci se completa en cualquier rama releases/* o rama principal, excepto en releases/old*.

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        - main
        exclude:
        - releases/old*

Nota:

Si los filtros de rama no funcionan, intente usar el prefijo refs/heads/. Por ejemplo, use refs/heads/releases/old* en lugar de releases/old*.

Filtros de etiquetas

La propiedad tags de trigger filtra qué eventos de finalización de canalización pueden desencadenar la canalización. Si la canalización de desencadenamiento coincide con todas las etiquetas de la lista tags, la canalización se ejecuta.

resources:
  pipelines:
  - pipeline: MyCIAlias
    source: Farbrikam-CI
    trigger:
      tags:        # This filter is used for triggering the pipeline run
      - Production # Tags are AND'ed
      - Signed

Nota:

El recurso de canalización también tiene una propiedad tags. La propiedad tags del recurso de canalización se utiliza para determinar de qué canalización se van a recuperar los artefactos, cuando la canalización se desencadena manualmente o mediante un desencadenador programado. Para más información, consulte Recursos: canalizaciones y Evaluación de la versión del artefacto.

Filtros de fase

Puede desencadenar la canalización cuando se completen una o varias fases de la canalización de desencadenamiento mediante el filtro stages. Si proporciona varias fases, la canalización desencadenada se ejecuta cuando se completan todas las fases enumeradas.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    source: Farbrikam-CI  
    trigger:    
      stages:         # This stage filter is used when evaluating conditions for 
      - PreProduction # triggering your pipeline. On successful completion of all the stages
      - Production    # provided, your pipeline will be triggered.

Consideraciones sobre las ramas

Los desencadenadores de finalización de canalización usan la configuración Rama predeterminada para compilaciones manuales y programadas para determinar qué versión de la rama de los filtros de rama de una canalización YAML se debe evaluar al determinar si se debe ejecutar una canalización como resultado de la finalización de otra. De forma predeterminada, esta configuración apunta a la rama predeterminada del repositorio.

Cuando se completa una canalización, el entorno de ejecución de Azure DevOps evalúa los filtros de rama del desencadenador de recursos de canalización de cualquier canalización con desencadenadores de finalización de canalización que hacen referencia a la canalización completada. Una canalización puede tener varias versiones en diferentes ramas, por lo que el tiempo de ejecución evalúa los filtros de rama de la versión de canalización de la rama especificada en la configuración Default branch for manual and scheduled builds. Si hay una coincidencia, la canalización se ejecuta, pero la versión de la canalización que se ejecuta puede estar en otra rama según si la canalización desencadenada está en el mismo repositorio que la canalización completada.

  • Si las dos canalizaciones están en repositorios diferentes, se ejecuta la versión de canalización desencadenada en la rama especificada por Default branch for manual and scheduled builds .
  • Si los dos canalizaciones se encuentran en el mismo repositorio, se ejecuta la versión de la canalización desencadenada en la misma rama que la canalización desencadenadora (utilizando la versión de la canalización de dicha rama en el momento en que se cumple la condición desencadenadora), incluso si dicha rama es diferente de la Default branch for manual and scheduled builds, e incluso si dicha versión no tiene filtros de rama que coincidan con la rama de la canalización completada. Esto se debe a que los filtros de rama de la rama Default branch for manual and scheduled builds se usan para determinar si se debe ejecutar la canalización, y no los filtros de rama de la versión que se encuentra en la rama de canalización completada.

Si los desencadenadores de finalización de la canalización no parecen activarse, compruebe el valor de Rama predeterminada para compilaciones manuales y programadas de la canalización desencadenada. Los filtros de rama de la versión de esa rama de la canalización se usan para determinar si el desencadenador de finalización de la canalización inicia una ejecución de la canalización. De forma predeterminada, Default branch for manual and scheduled builds se establece en la rama predeterminada del repositorio, pero puede cambiarla después de crear la canalización.

Un escenario típico en el que el desencadenador de finalización de la canalización no se activa es cuando se crea una nueva rama, los filtros de rama del desencadenador de finalización de canalización se modifican para incluir esta nueva rama, pero cuando la primera canalización se completa en una rama que coincide con los nuevos filtros de rama, la segunda canalización no se desencadena. Esto sucede si los filtros de rama de la versión de canalización de la rama Default branch for manual and scheduled builds no coinciden con la nueva rama. Para resolver este problema del desencadenador, tiene las dos opciones siguientes.

  • Actualizar los filtros de rama de la canalización de la rama Default branch for manual and scheduled builds para que coincidan con la nueva rama.
  • Actualizar el valor Rama predeterminada para compilaciones manuales y programadas en una rama que tenga una versión de la canalización con los filtros de rama que coincidan con la nueva rama.

Combinación de tipos de desencadenador

Al especificar tanto desencadenadores de CI como desencadenadores de canalización en la canalización, puede esperar que se inicien nuevas ejecuciones cada vez que se realice una inserción que coincida con los filtros del desencadenador de CI, y que se complete una ejecución de la canalización de origen que coincida con los filtros del desencadenador de finalización de la canalización.

Por ejemplo, considere dos canalizaciones llamadasA y B que están en el mismo repositorio, tienen desencadenadores de CI y B tiene un desencadenador de finalización de la canalización configurado para la finalización de la canalización A. Si realiza una inserción en el repositorio:

  • Se inicia una nueva ejecución de A, según su desencadenador de CI.
  • Al mismo tiempo, se inicia una nueva ejecución de B, según su desencadenador de CI. Esta ejecución consume los artefactos de una ejecución anterior de la canalización A.
  • Cuando se completa A, se desencadena otra ejecución de B, en función del desencadenador de finalización de la canalización en B.

Para evitar que se desencadenen dos ejecuciones de B en este ejemplo, debe deshabilitar su desencadenador de CI (trigger: none) o desencadenador de canalización (pr: none).