Compartilhar via

Suporte para curingas e expressões condicionais em arquivos de pipeline YAML

  • Artigo

Neste sprint, incluímos suporte para curingas e expressões condicionais para arquivos de pipeline YAML. Além disso, fizemos várias atualizações nas imagens hospedadas do Azure Pipelines.

Confira as descrições de recurso a seguir para obter detalhes.

Azure Pipelines

Azure Repos

Azure Pipelines

Novas expressões condicionais YAML

Escrever expressões condicionais em arquivos YAML ficou mais fácil com o uso de ${{ else }} expressões and ${{ elseif }} . Abaixo estão exemplos de como usar essas expressões em arquivos de pipelines YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux') }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Suporte para curingas em filtros de caminho

Os curingas podem ser usados ao especificar ramificações de inclusão e exclusão para gatilhos de CI ou PR em um arquivo YAML de pipeline. No entanto, eles não podem ser usados ao especificar filtros de caminho. Por exemplo, você não pode incluir todos os caminhos que correspondem a src/app/**/myapp*. Isso foi apontado como um inconveniente por vários clientes. Esta atualização preenche essa lacuna. Agora, você pode usar caracteres curinga (**, *ou ?) ao especificar filtros de caminho.

Suporte para vários status no Bitbucket

O Azure Pipelines se integra aos repositórios do Bitbucket e dá suporte a gatilhos de CI e PR. Você pode configurar vários pipelines de um único repositório do Bitbucket. No entanto, quando esses pipelines foram concluídos, você só pôde ver um status no Bitbucket. Ouvimos comentários da Comunidade de Desenvolvedores pedindo para visualizar o status de cada pipeline separadamente no Bitbucket. Com essa atualização, atualizamos nossas chamadas de API para o Bitbucket e passamos informações adicionais sobre o nome do pipeline.

Status do Build

Permitir que os colaboradores ignorem a busca de comentários de PR antes da validação do build

Ao usar Azure Pipelines com repositórios GitHub, recomendamos que você não execute automaticamente um pipeline de validação de PR para contribuições recebidas de um repositório bifurcado. A prática recomendada aqui é primeiro fazer com que um dos colaboradores do repositório revise a alteração e, em seguida, adicione um comentário à PR para disparar o pipeline. Você pode definir essas configurações selecionando o menu Gatilhos (para pipelines YAML) ou a guia Gatilhos (para pipelines de build clássicos) no editor da Web do pipeline. Em vez de exigir que cada PR de uma bifurcação seja revisada primeiro por um membro da equipe, você também pode impor essa política apenas em contribuições originadas de não membros da equipe.

Com esta atualização, estamos permitindo que você pule a busca de um comentário de RP de contribuições recebidas por qualquer colaborador. Como um não membro da equipe, quando você cria uma bifurcação e cria uma PR para o upstream, você não é considerado um colaborador do repositório upstream até que sua PR seja mesclada. Depois que seu PR for mesclado, você será considerado um colaborador. Ao selecionar a nova opção mostrada abaixo, quando um não membro da equipe envia uma PR de uma bifurcação pela primeira vez, alguém da sua equipe teria que revisar a PR e adicionar um comentário para disparar o pipeline. Mas, uma vez que o PR é mesclado, quaisquer outras contribuições feitas por esse não membro da equipe acionarão diretamente o pipeline sem esperar por um comentário de PR.

Exigir o comentário de um membro da equipe antes de criar uma solicitação de pull

O Windows Server 2022 com o Visual Studio 2022 agora está disponível em agentes hospedados pela Microsoft (versão prévia)

O Windows Server 2022 e o Visual Studio Enterprise 2022 Preview agora estão disponíveis em versão prévia em agentes hospedados pela Microsoft. Você pode usá-lo referenciando windows-2022 como imagem em seu pipeline.

pool:
  vmImage: 'windows-2022'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '**/*.sln'
- task: VSBuild@1 # Visual Studio 2022 build
  inputs:
    solution: '**/*.sln'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: 'Any CPU'
    configuration: 'Release'

Quando você faz referência ao pool windows-latest em seus pipelines YAML, isso ainda significa windows-2019 e não windows-2022, enquanto o último está em versão prévia.

A imagem de pipeline do Windows Server 2022 tem ferramentas e versões de ferramentas diferentes quando comparada ao Windows Server 2019. Você pode ver os detalhes no problema do anúncio de software e no repositório de ambientes virtuais da documentação.

Disponibilidade geral do macOS 11 em agentes hospedados pela Microsoft

O macOS 11 agora está disponível para o público geral em agentes hospedados pela Microsoft. Você pode usá-lo referenciando macos-11 como imagem em seu pipeline.

pool:
  vmImage: macos-11

Remoção da imagem do Ubuntu 16.04 em agentes hospedados pela Microsoft

Conforme anunciado anteriormente, removeremos a imagem do Ubuntu 16.04 dos agentes hospedados pela Microsoft em 20 de setembro de 2021. O suporte tradicional de 5 anos do Ubuntu 16.04 pela Canonical terminou em abril de 2021. Você precisará migrar os pipelines do ubuntu-16.04 para o ubuntu-18.04 ou ubuntu-latest, que será executado no Ubuntu 20.04 LTS.

As compilações que usam o Ubuntu-16.04 já têm um aviso sendo registrado nelas. Para garantir que todos estejam cientes dessa mudança, agendamos 2 "quedas de energia" curtas. As compilações do Ubuntu 16.04 falharão durante o período de queda de energia. Portanto, é recomendável migrar seus fluxos de trabalho antes de 6 de setembro de 2021.

As quedas de energia estão programadas para as seguintes datas e horários (observe que foram estendidos em uma hora em relação aos horários anunciados anteriormente): 6 de setembro de 2021 16:00 UTC – 22:00 UTC 14 de setembro de 2021 16:00 UTC – 22:00 UTC

Azure Repos

Novas páginas TFVC estão em disponibilidade geral

Atualizamos várias páginas no Azure DevOps para usar uma nova plataforma Web com o objetivo de tornar a experiência mais consistente e acessível entre os vários serviços. As páginas do TFVC foram atualizadas para usar a nova plataforma da Web e essas alterações estão em versão prévia há vários meses. Com essa atualização, estamos disponibilizando as novas páginas do TFVC para o público em geral. Com esta atualização, você não verá mais um recurso de visualização chamado "Novas páginas TFVC" em suas configurações de usuário.

Configurar criadores de branch para não receber "Permissões para gerenciar" em suas ramificações

Ao criar um novo branch, você obtém "Gerenciar permissões" nesse branch. Essa permissão permite alterar as permissões de outros usuários ou admitir usuários adicionais para contribuir com essa ramificação. Por exemplo, um criador de branch pode usar essa permissão para permitir que outro usuário externo faça alterações no código. Ou eles podem permitir que um pipeline (identidade de serviço de build) altere o código nesse branch. Em determinadas organizações com requisitos de conformidade mais altos, os usuários não devem ser capazes de fazer essas alterações.

Com essa atualização, você pode configurar todo e qualquer repositório em seu projeto de equipe e impedir que os criadores de branch obtenham a permissão "Gerenciar permissões". Para fazer isso, navegue até as configurações do projeto, selecione Repositórios e, em seguida, Configurações para todos os repositórios ou um repositório específico.

Todas as configurações de repositórios

Essa configuração está ativada por padrão para imitar o comportamento existente. Mas você pode desativá-lo se desejar usar esse novo recurso de segurança.

Impedir que os usuários do branch votem em seus PRs upstream

Com Azure Repos, os usuários com permissão de "leitura" em um repositório podem bifurcar o repositório e fazer alterações em sua bifurcação. Para enviar uma solicitação de pull com suas alterações no upstream, os usuários precisam da permissão "contribuir para solicitações de pull" no upstream. No entanto, essa permissão também rege quem pode votar em solicitações de pull no repositório upstream. Como resultado, você pode acabar em situações em que um usuário, que não é um colaborador do repositório, pode enviar uma solicitação de pull e fazer com que ela seja mesclada, dependendo de como você configura as políticas de branch.

Em organizações que promovem um modelo de fonte interna, bifurcar e contribuir é um padrão comum. Para proteger e promover ainda mais esse padrão, estamos alterando a permissão para votar em uma solicitação de pull de "contribuir para solicitações de pull" para "contribuir". No entanto, essa alteração não está sendo feita por padrão em todas as organizações. Você precisa aceitar e selecionar uma nova política em seu repositório, chamada "Modo de votação estrita" para alternar essa permissão. Recomendamos que você faça isso se depender de bifurcações no Azure Repos.

Configurações do repositório

Próximas etapas

Observação

Esses recursos serão lançados nas próximas duas a três semanas.

Vá até o Azure DevOps e dê uma olhada.

Ir para o Azure DevOps

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre esses recursos. Use o menu de ajuda para relatar um problema ou fornecer uma sugestão.

Fazer uma sugestão

Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigada,

Aaron Hallberg