Partilhar via

Acionar um pipeline após o outro

  • Artigo

Serviços de DevOps do Azure | Azure DevOps Server 2022 | Azure DevOps Server 2020

Os grandes produtos têm vários componentes que dependem uns dos outros. Estes componentes são muitas vezes construídos de forma independente. Quando um componente a montante (uma biblioteca, por exemplo) muda, as dependências a jusante têm de ser reconstruídas e revalidadas.

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

Observação

Anteriormente, você pode ter navegado até o editor clássico para seu pipeline YAML e configurado gatilhos de conclusão de compilação 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, como definidos no editor clássico, têm várias desvantagens, que agora foram abordadas nos gatilhos de pipeline. Por exemplo, não há como acionar um pipeline na mesma branch do pipeline que está a ser acionado usando gatilhos de conclusão de compilação.

Os gatilhos definidos usando a interface do usuário de configurações de pipeline têm precedência sobre os gatilhos YAML. Para excluir gatilhos agendados da interface do usuário de um pipeline do YAML, consulte as configurações da interface do usuário substituem os gatilhos agendados do YAML.

Configurar gatilhos de recursos de pipeline

Para acionar 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 pipeline security-lib-ci.

Este exemplo tem as seguintes duas pipelines.

  • security-lib-ci - Este fluxo de trabalho é executado primeiro.

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

  • app-ci - Este pipeline tem um gatilho de recurso de pipeline que configura o pipeline de app-ci para ser executado automaticamente sempre que uma execução do pipeline de security-lib-ci for 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. Utilize a etiqueta definida aqui ao referir-se ao recurso de pipeline a partir de outras partes do pipeline, como ao usar variáveis de recurso de pipeline ou ao baixar artefatos.
  • source: security-lib-ci especifica o nome do pipeline referenciado por este 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 destino do Pipelines. Por padrão, os pipelines são nomeados após o repositório que contém o pipeline. Para atualizar o nome de um pipeline, consulte Configurações do pipeline. Se o pipeline estiver contido numa pasta, inclua o nome da pasta, incluindo o inicial \, por exemplo \security pipelines\security-lib-ci.
  • project: FabrikamProject - Se o pipeline de acionamento estiver em outro projeto do Azure DevOps, você deverá especificar o nome do projeto. Essa propriedade é opcional se o pipeline de origem e o pipeline acionado estiverem no mesmo projeto. Se você especificar esse valor e seu pipeline não for acionado, consulte a observação no final desta seção.
  • trigger: true - Use esta sintaxe para acionar o pipeline sempre que qualquer versão do pipeline de origem for concluída. Consulte as seções a seguir neste artigo para saber como selecionar quais versões do pipeline de origem, ao serem concluídas, acionarã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 acionamento e o pipeline acionado usarem o mesmo repositório, ambos os pipelines serão executados usando o mesmo commit quando um acionar o outro. Isso é útil se o primeiro pipeline compilar o código e o segundo pipeline testá-lo. No entanto, se os dois pipelines usarem repositórios diferentes, o pipeline acionado usará a versão do código na ramificação especificada pela configuração Default branch for manual and scheduled builds, conforme descrito em Considerações de ramificação para gatilhos de conclusão de pipeline.

Observação

Em alguns cenários, a ramificação padrão para compilações manuais e compilações agendadas não inclui um prefixo refs/heads. Por exemplo, a ramificação padrão pode ser definida 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 para um valor diferente do pipeline de destino, poderá atualizar a ramificação padrão para incluir refs/heads alterando seu valor para uma ramificação diferente e, em seguida, alterando-a de volta para a ramificação padrão que deseja usar.

A configuração de gatilhos de conclusão de pipeline não é suportada em modelos YAML. Você ainda pode definir recursos de pipeline em modelos.

Filtros de ramificação

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

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

Para acionar 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 de app-ci é executado se o security-lib-ci for concluído em qualquer ramificação releases/* ou na principal, exceto na 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 ramificação não estiverem funcionando, tente usar o prefixo refs/heads/. Por exemplo, use refs/heads/releases/old*em vez de releases/old*.

Filtros de tags

A propriedade tags do trigger filtra quais eventos de conclusão de pipeline podem acionar seu pipeline. Se o pipeline de acionamento corresponder a todas as tags 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 é acionado manualmente ou por um gatilho agendado. Para obter mais informações, consulte Recursos : pipelines e Avaliação da versão do artefato.

Filtros de palco

Você pode acionar seu pipeline quando um ou mais estágios do pipeline de acionamento forem concluídos usando o filtro stages. Se você fornecer vários estágios, o pipeline acionado 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 sobre a ramificação

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

Quando um pipeline é concluído, o tempo de execução do Azure DevOps avalia os filtros de ramificação dos gatilhos de recursos do pipeline de qualquer pipeline com gatilhos de conclusão que fazem referência ao pipeline concluído. Um pipeline pode ter várias versões em ramificações diferentes, portanto, o tempo de execução avalia os filtros de ramificação na versão do pipeline na ramificação especificada 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 pode estar em uma ramificação diferente, dependendo se o pipeline acionado está no mesmo repositório que o pipeline concluído.

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

Se os gatilhos de conclusão do pipeline não parecerem ser ativados, verifique o valor da ramificação predefinida para compilações manuais e agendadas na configuração do pipeline acionado. Os filtros de ramificação na versão correspondente dessa ramificação do pipeline são utilizados para determinar se o acionador de conclusão do pipeline inicia uma execução dele. Por padrão, Default branch for manual and scheduled builds é definido como a ramificação padrão do repositório, mas você pode alterá-lo depois que o pipeline é criado.

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

  • Atualize os filtros de ramificação no pipeline na ramificação Default branch for manual and scheduled builds para que correspondam à nova ramificação.
  • Atualize a configuração ramificação Padrão para compilações manuais e agendadas para uma ramificação que tenha uma versão do pipeline com os filtros de ramificação que correspondem à nova ramificação.

Combinação de tipos de gatilho

Ao especificar os gatilhos de CI e os gatilhos de pipeline no seu pipeline, pode esperar que novas execuções sejam iniciadas sempre que for realizado um push que corresponda aos filtros do gatilho de CI e uma execução do pipeline de origem for 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 configurado para ser acionado após a conclusão do pipeline A. Se fizeres um push para o repositório:

  • Uma nova execução de A é iniciada, com base no seu trigger de CI.
  • Ao mesmo tempo, uma nova execução de B é iniciada, com base no seu gatilho de CI. Essa execução consome os artefatos de uma execução anterior do pipeline A.
  • Quando A é concluído, 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, deve-se desabilitar o seu disparador de CI (trigger: none) ou o disparador de pipeline (pr: none).