Partilhar via

Acionar um pipeline após 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 upstream (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 pipeline de acionamento.

Nota

Anteriormente, você pode ter navegado para 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 compilação, conforme 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 ramificação do pipeline de acionamento usando gatilhos de conclusão de compilação.

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 nomeado app-ci seja executado após a security-lib-ci conclusão de qualquer execução do pipeline.

Este exemplo tem os dois pipelines a seguir.

  • security-lib-ci - Este pipeline é 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 app-ci pipeline para ser executado automaticamente sempre que uma execução do security-lib-ci pipeline 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. Use o rótulo definido aqui ao se referir 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 de DevOps do Azure em vários locais, como a página inicial de 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 em uma pasta, inclua o nome da pasta, incluindo a entrelinha \, 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 quando qualquer versão do pipeline de origem for concluída. Consulte as seções a seguir neste artigo para saber como filtrar quais versões da conclusão do pipeline de origem 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 a mesma confirmação 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 Default branch for manual and scheduled builds configuração, conforme descrito em Considerações de ramificação para gatilhos de conclusão de pipeline.

Nota

Em alguns cenários, a ramificação padrão para compilações manuais e compilações agendadas não inclui um refs/heads prefixo. 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 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 app-ci pipeline é executado se o security-lib-ci for concluído em qualquer releases/* ramificação, exceto em 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 app-ci pipeline é executado se o security-lib-ci for concluído em qualquer releases/* ramificação 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*

Nota

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 tags propriedade dos filtros, trigger quais eventos de conclusão de pipeline podem acionar seu pipeline. Se o pipeline de acionamento corresponder a todas as tags na lista, o tags 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

Nota

O recurso de pipeline também tem uma tags propriedade. A tags propriedade do recurso de pipeline é usada para determinar de qual pipeline é executado para 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 stages filtro. 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 Ramificação padrão para compilações manuais e agendadas para determinar qual versão de ramificação dos filtros de ramificação de um pipeline YAML deve ser avaliada ao determinar 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 de gatilho de recurso de pipeline de quaisquer 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 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 Default branch for manual and scheduled builds configuração. 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 builds, e 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 Default branch for manual and scheduled builds ramificação 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 estar sendo acionados, verifique o valor da ramificação Padrão para a configuração de compilações manuais e agendadas para o pipeline acionado. Os filtros de ramificação na versão do pipeline dessa ramificação são usados para determinar se o gatilho de conclusão do pipeline inicia uma execução do pipeline. Por padrão, é definido como a ramificação padrão do repositório, Default branch for manual and scheduled builds mas você pode alterá-la depois que o pipeline for criado.

Um cenário típico em que o gatilho de conclusão de pipeline não é acionado é quando uma nova ramificação é criada, os filtros de ramificação de conclusão de pipeline são modificados para incluir essa nova ramificação, mas quando o primeiro pipeline é concluído em uma ramificação que corresponde aos novos filtros de ramificação, o segundo pipeline não é acionado. Isso acontece se os filtros de ramificação na versão de pipeline na Default branch for manual and scheduled builds ramificação 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 Default branch for manual and scheduled builds ramificação 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 gatilhos de CI e gatilhos de pipeline em seu pipeline, você pode esperar que novas execuções sejam iniciadas sempre que for feito 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 nomeados A e que estão no mesmo repositório, ambos têm gatilhos de CI e B 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 é iniciada, com base em seu gatilho de A CI.
  • Ao mesmo tempo, uma nova execução de é iniciada, com base em seu gatilho de B IC. Essa execução consome os artefatos de uma execução anterior de pipeline A.
  • Quando A concluído, ele dispara outra execução de , com base no gatilho de conclusão do Bpipeline em B.

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