Compartilhar via

Disparar um pipeline após o outro

  • Artigo

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

Produtos grandes têm vários componentes que dependem uns dos outros. Esses componentes geralmente são criados de forma independente. Quando um componente upstream (uma biblioteca, por exemplo) é alterado, as dependências downstream precisam ser recompiladas e revalidadas.

Em situações como essas, adicione um gatilho de pipeline para executar o pipeline após a conclusão bem-sucedida do pipeline de gatilho.

Observação

Anteriormente, você pode ter navegado até o editor clássico do pipeline yaml e configurado gatilhos de conclusão de build na interface do usuário. Embora esse modelo ainda funcione, ele não é mais recomendado. A abordagem recomendada é especificar gatilhos de pipeline diretamente no arquivo YAML. Os gatilhos de conclusão de build, conforme definido no editor clássico, têm várias desvantagens, que agora foram abordadas em gatilhos de pipeline. Por exemplo, não há como disparar um pipeline no mesmo branch que o do pipeline de gatilho usando gatilhos de conclusão de build.

Configurar gatilhos de recursos de pipeline

Para disparar um pipeline após a conclusão de outro pipeline, configure um gatilho de recurso de pipeline.

O exemplo a seguir configura um gatilho de recurso de pipeline para que um pipeline chamado app-ci seja executado após a conclusão de qualquer execução do security-lib-ci pipeline.

Este exemplo tem os dois pipelines a seguir.

  • security-lib-ci – Esse pipeline é executado primeiro.

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

  • app-ci – Esse pipeline tem um gatilho de recurso de pipeline que configura o app-ci pipeline para ser executado automaticamente sempre que uma execução do security-lib-ci pipeline é concluída.

    # 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 o nome do recurso de pipeline. Use o rótulo definido aqui ao fazer referência ao recurso de pipeline de outras partes do pipeline, como ao usar variáveis de recurso de pipeline ou baixar artefatos.
  • source: security-lib-ci especifica o nome do pipeline referenciado por esse recurso de pipeline. Você pode recuperar o nome de um pipeline do portal do Azure DevOps em vários locais, como a página de aterrissagem de Pipelines. Por padrão, os pipelines são nomeados em homenagem ao repositório que contém o pipeline. Para atualizar o nome de um pipeline, confira Configurações de pipeline. Se o pipeline estiver contido em uma pasta, inclua o nome da pasta, incluindo o \ à esquerda, por exemplo, \security pipelines\security-lib-ci.
  • project: FabrikamProject – Se o pipeline de gatilho estiver em outro projeto do Azure DevOps, você deverá especificar o nome do projeto. Essa propriedade será opcional se o pipeline de origem e o pipeline disparado estiverem no mesmo projeto. Se você especificar esse valor e o pipeline não for disparado, confira a observação no final desta seção.
  • trigger: true – Use essa sintaxe para disparar o pipeline quando qualquer versão do pipeline de origem for concluída. Confira as seções a seguir neste artigo para saber como filtrar quais versões do pipeline de origem que serão concluídas dispararão uma execução. Quando os filtros são especificados, a execução do pipeline de origem deve corresponder a todos os filtros para disparar uma execução.

Se o pipeline de gatilho e o pipeline disparado usarem o mesmo repositório, ambos os pipelines serão executados usando a mesma confirmação quando um disparar o outro. Isso será útil se o primeiro pipeline compilar o código e o segundo pipeline o testar. No entanto, se os dois pipelines usarem repositórios diferentes, o pipeline disparado usará a versão do código no branch especificado pela configuração Default branch for manual and scheduled builds, conforme descrito em Considerações de branch para gatilhos de conclusão de pipeline.

Observação

Em alguns cenários, o branch padrão para builds manuais e builds agendados não inclui um prefixo refs/heads. Por exemplo, o branch padrão pode ser definido como main em vez de refs/heads/main. Nesse cenário, um gatilho de um projeto diferente não funciona. Se você encontrar problemas ao definir project como um valor diferente do valor do pipeline de destino, poderá atualizar o branch padrão a ser incluído refs/heads alterando seu valor para um branch diferente e, em seguida, alterando-o de volta para o branch padrão que você deseja usar.

Não há suporte para a configuração de gatilhos de conclusão de pipeline nos modelos YAML. Você ainda pode definir recursos de pipeline em modelos.

Filtros de branch

Opcionalmente, você pode especificar os branches a serem incluídos ou excluídos ao configurar o gatilho. Se você especificar filtros de branch, um novo pipeline será disparado sempre que uma execução de pipeline de origem for concluída com êxito e corresponda aos filtros de branch. No exemplo a seguir, o pipeline app-ci será executado se security-lib-ci for concluído em qualquer branch releases/*, exceto para releases/old*.

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

Para disparar o pipeline filho para diferentes ramificações para as quais o pai é acionado, inclua todos os filtros de ramificação para os quais o pai é acionado. No exemplo a seguir, o pipeline app-ci será executado se security-lib-ci for concluído em qualquer ramificação releases/* ou ramificação principal, exceto para releases/old*.

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

Observação

Se os filtros de branch não estiverem funcionando, tente usar o prefixo refs/heads/. Por exemplo, use refs/heads/releases/old* em vez de releases/old*.

Filtros de marca:

A propriedade tags dos filtros trigger que os eventos de conclusão de pipeline podem disparar o pipeline. Se o pipeline de gatilho corresponder a todas as marcas na lista tags, o pipeline será executado.

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

Observação

O recurso de pipeline também tem uma propriedade tags. A propriedade tags do recurso de pipeline é usada para determinar de qual execução de pipeline recuperar artefatos, quando o pipeline é disparado manualmente ou por um gatilho agendado. Para saber mais, confira Recursos: pipelines e Avaliação da versão do artefato.

Filtros de estágio

Você pode disparar o pipeline quando um ou mais estágios do pipeline de gatilho forem concluídos usando o filtro stages. Se você fornecer vários estágios, o pipeline disparado será executado quando todos os estágios listados forem concluídos.

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.

Considerações de ramificação

Os gatilhos de conclusão de pipeline usam a configuração Branch padrão para compilações manuais e agendadas para determinar qual versão do branch dos filtros de branch de um pipeline YAML avaliar ao determinar se um pipeline deve ser executado como resultado da conclusão de outro pipeline. Por padrão, essa configuração aponta para o branch padrão do repositório.

Quando um pipeline é concluído, o runtime do Azure DevOps avalia os filtros de branch de gatilho de recurso de pipeline de todos os pipelines com gatilhos de conclusão de pipeline que fazem referência ao pipeline concluído. Um pipeline pode ter várias versões em branches diferentes, portanto, o runtime avalia os filtros de branch na versão do pipeline no branch especificado pela configuração Default branch for manual and scheduled builds. Se houver uma correspondência, o pipeline será executado, mas a versão do pipeline que é executada poderá estar em um branch diferente, dependendo se o pipeline disparado está no mesmo repositório que o pipeline concluído.

  • Se os dois pipelines estiverem em repositórios diferentes, a versão do pipeline disparada no branch especificado por Default branch for manual and scheduled builds será executada.
  • Se os dois pipelines estiverem no mesmo repositório, a versão do pipeline disparada no mesmo branch que o pipeline de gatilho será executada (usando a versão do pipeline daquela ramificação em que a condição de gatilho é atendida), mesmo que esse branch seja diferente do Default branch for manual and scheduled builds e mesmo que essa versão não tenha filtros de branch que correspondam ao branch do pipeline concluído. Isso ocorre porque os filtros de branch do branch Default branch for manual and scheduled builds são usados para determinar se o pipeline deve ser executado e não os filtros de branch na versão que está no branch de pipeline concluído.

Se os gatilhos de conclusão do pipeline não parecerem estar sendo disparados, marcar o valor do Branch padrão para a configuração de builds manuais e agendados para o pipeline disparado. Os filtros de branch na versão desse branch do pipeline são usados para determinar se o gatilho de conclusão do pipeline inicia uma execução do pipeline. Por padrão, Default branch for manual and scheduled builds é definido como o branch padrão do repositório, mas você pode alterá-lo após a criação do pipeline.

Um cenário típico em que o gatilho de conclusão do pipeline não é acionado é quando um novo branch é criado, os filtros de branch do gatilho de conclusão de pipeline são modificados para incluir esse novo branch, mas quando o primeiro pipeline é concluído em um branch que corresponde aos novos filtros de branch, o segundo pipeline não é disparado. Isso acontece se os filtros de branch na versão do pipeline no branch Default branch for manual and scheduled builds não corresponderem ao novo branch. Para resolve esse problema de gatilho, você tem as duas opções a seguir.

  • Atualize os filtros de branch no pipeline no branch Default branch for manual and scheduled builds para que eles correspondam ao novo branch.
  • Atualize a configuração Branch padrão para builds manuais e agendados para um branch que tenha uma versão do pipeline com os filtros de branch que correspondam ao novo branch.

Combinando tipos de gatilho

Ao especificar gatilhos de CI e gatilhos de pipeline em seu pipeline, você pode esperar que novas execuções sejam iniciadas sempre que um push for feito que corresponda aos filtros do gatilho de CI e uma execução do pipeline de origem seja concluída que corresponda aos filtros do gatilho de conclusão do pipeline.

Por exemplo, considere dois pipelines chamados A e B que estão no mesmo repositório, ambos têm gatilhos de CI e B tem um gatilho de conclusão de pipeline configurado para a conclusão do pipeline A. Se você fizer um push para o repositório:

  • Uma nova execução de A é iniciada, com base em seu gatilho de CI.
  • Ao mesmo tempo, uma nova execução de B é iniciada, com base em seu gatilho de CI. Essa execução consome os artefatos de uma execução anterior do pipeline A.
  • Quando A é concluído, ele dispara outra execução de B, com base no gatilho de conclusão do pipeline em B.

Para evitar o acionamento de duas execuções de B neste exemplo, você deve remover seu gatilho de CI (trigger: none) ou gatilho de pipeline (pr: none).