Devops do Azure executando dois builds sequencialmente

Question

Temos a configuração do Azure Devops. Neste momento, nosso projeto será construído duas vezes.

Uma vez durante o check-in de solicitação de pull no arquivo YAML e outra devido às configurações de compilação (imagem abaixo).

Isso dispara duas compilações e faz com que nosso tempo de compilação dobre. Nossa equipe Devops mencionou que esta é uma prática regular. Por que o Azure Devops não dispara apenas uma compilação e ou é uma prática mais segura com duas compilações?

Answer 1

Por que o Azure Devops não dispara apenas uma compilação e ou é uma prática mais segura com duas compilações?

Pelo que eu sei, esse é o fluxo de trabalho esperado do Azure Devops.

devido às configurações de compilação

Este é o gatilho de solicitação de pull .

Este gatilho ocorre no processo de solicitação pull, o gatilho PR deve ser executado sempre que um PR é criado.

Este gatilho é equivalente a uma etapa de verificação, o arquivo não está realmente comprometido com a ramificação de destino (pré-mesclado com a ramificação Targer).

Você pode verificar os resultados da construção para determinar se o código da filial de origem é válido.

Por exemplo:

Se o acionador de solicitação pull falhar, você pode rejeitar a solicitação pull. Não afeta o ramo de destino, o ramo de destino permanece no estado original

Puxe a solicitação de check-in no arquivo YAML

Este pode ser o gatilho do CI .

Este gatilho acontecerá quando a solicitação pull for concluída.

Nesse caso, a ramificação de destino mudou. A mudança da ramificação de destino aciona o gatilho de CI. Isso pode verificar se o código é válido.

Resumo do fluxo de trabalho:

Criar solicitação de pull -> acionador de solicitação de pull (pré-mesclado e verificação de disparo) -> Solicitação de pull concluída -> acionador de CI (concluir a fusão de ramificações e a segunda verificação).

A propósito, se você deseja excluir alguns arquivos para que não acionem o acionador de solicitação de pull, você pode adicionar um filtro de caminho.

Por exemplo:

Answer 2

Funcionalmente, as duas compilações podem não ser sempre iguais.

Digamos que você tenha o exemplo abaixo. Letras maiúsculas são confirmações e letras minúsculas são confirmações potenciais.

  e e'
 /   \
|  |   D
C  |   B 
 \ |  /
   A

Isso mostra dois branches saindo do commit A (branch master). Cada ramo de recurso teve um PR criado para cada um. Um branch tem uma construção no e 'commit e o outro branch tem uma construção no e' commit. Os devops do Azure não podem ter certeza de qual PR será mesclado primeiro.

Depois de mesclar os PRs, você acabará com um novo commit no master que não foi criado anteriormente. Isso é descrito aqui

   F
   E \
 / |   D
C  |   B 
 \ |  /
   A

Se você deseja eliminar a necessidade de sua construção no mestre, pode definir a expiração da construção para Immediately when branch name is updated