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 }} e ${{ elseif }} expressões. 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 ao src/app/**/myapp*. Isso tem sido 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 integra-se aos repositórios Bitbucket e dá suporte a gatilhos de CI e PR. Você pode configurar vários pipelines a partir de um único repositório 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 ver 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.

Build status

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

Ao usar o Azure Pipelines com repositórios do GitHub, recomendamos que você não execute automaticamente um pipeline de validação de RP 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 ao PR para acionar o pipeline. Você pode definir essas configurações selecionando o menu Gatilhos (para pipelines YAML) ou a guia Gatilhos (para pipelines de compilação clássicos) no editor da Web de pipeline. Em vez de exigir que cada RP de uma bifurcação seja primeiro revisado por um membro da equipe, você também pode aplicar 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 por um comentário de relações públicas de contribuições recebidas por qualquer colaborador. Como um membro que não é da equipe, quando você cria um fork e cria um PR para o upstream, você não é considerado um colaborador para o repositório upstream até que seu PR seja mesclado. Uma vez que seu PR é mesclado, você será considerado um contribuidor. Ao selecionar a nova opção mostrada abaixo, quando um membro que não é da equipe envia um PR de um fork pela primeira vez, alguém da sua equipe teria que revisar o PR e adicionar um comentário para acionar o pipeline. Mas, uma vez que o PR é fundido, quaisquer outras contribuições feitas por esse membro não-equipe acionarão diretamente o pipeline sem esperar por um comentário de RP.

Require a team member's comment before building a pull request

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 visualização 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 mais recente do Windows em seus pipelines YAML, isso ainda significará windows-2019 e não windows-2022, enquanto o último estiver em visualização.

A imagem de pipeline do Windows Server 2022 tem diferentes ferramentas e versões de ferramentas quando comparada ao Windows Server 2019. Você pode ver os detalhes no problema de anúncio de software e no repositório de ambientes virtuais de 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

A imagem do pipeline do macOS 11 tem diferentes ferramentas e ferramentas, para saber mais sobre esta versão você pode ver a documentação completa aqui.

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 pipelines ubuntu-16.04 para ubuntu-18.04 ou ubuntu-latest que será executado no Ubuntu 20.04 LTS.

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

Os brownouts estão programados para as seguintes datas e horários (Note que estes foram prorrogados por 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

Estamos atualizando várias páginas no Azure DevOps para usar uma nova plataforma Web com o objetivo de tornar a experiência mais consistente e mais acessível entre os vários serviços. As páginas do TFVC foram atualizadas para usar a nova plataforma web, e essas mudanças estão em pré-visualização há vários meses. Com esta 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 uma nova ramificação, você obtém "Gerenciar permissões" nessa ramificação. 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 ramificação 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 (criar identidade de serviço) altere o código nessa ramificação. 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 restringir os criadores de ramificação de obter 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.

All repositories settings

Essa configuração está ativada por padrão para imitar o comportamento existente. Mas, você pode desativá-lo se quiser fazer uso desse novo recurso de segurança.

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

Com o Azure Repos, os usuários com permissão de "leitura" em um repositório podem bifurcar o repositório e fazer alterações em seu fork. Para enviar uma solicitação pull com suas alterações no upstream, os usuários precisam da permissão "contribuir para solicitações pull" no upstream. No entanto, essa permissão também rege quem pode votar em solicitações 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 pull e fazer com que ela seja mesclada, dependendo de como você configura as políticas de ramificação.

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 um pedido de pull de "contribuir para pull requests" 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 Estrito" para alternar essa permissão. Recomendamos que você faça isso se depender de bifurcações no Azure Repos.

Repository settings

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.

Make a suggestion

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

Obrigada,

Aaron Hallberg