Partilhar 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.

Verifique as seguintes descrições de funcionalidades para obter detalhes.

Pipelines do Azure

Repositórios do Azure

Pipelines do Azure

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 carateres universais nos 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, não é possível 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 esta lacuna. Agora, você pode usar caracteres curinga (**, *ou ?) ao especificar filtros de caminho.

Suporte para vários estados no Bitbucket

O Azure Pipelines integra-se com repositórios Bitbucket e suporta gatilhos de CI e PR. Você pode configurar vários pipelines a partir de um único repositório Bitbucket. No entanto, quando esses pipelines estavam completos, você só podia ver um status no Bitbucket. Ouvimos comentários da Comunidade de Desenvolvedores pedindo para visualizar o status de cada pipeline separadamente no Bitbucket. Com esta atualização, atualizamos nossas chamadas de API para o Bitbucket e passamos informações adicionais sobre o nome do pipeline.

Status da compilação

Permitir que os contribuidores ignorem a procura de comentários PR antes da validação da compilação

Ao usar o Azure Pipelines com repositórios 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 melhor prática aqui é primeiro fazer com que um dos colaboradores do repositório analise 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 Triggers (para pipelines YAML) ou a guia Triggers (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 revisado primeiro por um membro da equipe, você também pode aplicar essa política apenas em contribuições originadas de membros que não fazem parte da equipe.

Com esta atualização, permitimos que você pule a busca por um comentário de RP de contribuições recebidas por qualquer colaborador. Como um membro que não é da equipe, quando você cria uma bifurcação e cria uma RP para o upstream, você não é considerado um contribuidor para o repositório upstream até que sua RP seja mesclada. Uma vez que seu RP é mesclado, você será considerado um contribuidor. Ao selecionar a nova opção mostrada abaixo, quando um membro que não é da equipe envia um RP de uma bifurcação pela primeira vez, alguém da sua equipe terá 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 que não faz parte da equipe acionarão diretamente o pipeline sem esperar por um comentário de RP.

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

O Windows Server 2022 com o Visual Studio 2022 está agora disponível nos agentes alojados na Microsoft (pré-visualização)

O Windows Server 2022 e o Visual Studio Enterprise 2022 Preview já estão disponíveis em versão prévia em agentes hospedados pela Microsoft. Você pode usá-lo fazendo referência como windows-2022 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 significará windows-2019 e não windows-2022, enquanto o último está 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 do 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 em agentes hospedados pela Microsoft. Você pode usá-lo fazendo referência como macos-11 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 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, programamos 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 de 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

Repositórios do Azure

As novas páginas do TFVC estão em disponibilidade geral

Temos vindo a atualizar várias páginas no Azure DevOps para utilizar 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 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 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 os criadores de ramos para que não obtenham "Gerir permissões" nos respetivos ramos

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 filial 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) para alterar o código nessa ramificação. Em certas organizações com requisitos de conformidade mais elevados, 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 ramificações 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 quiser fazer uso deste novo recurso de segurança.

Impedir que os utilizadores de forks votem nos respetivos PRs de origem

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 sua bifurcação. Para enviar uma solicitação pull com suas alterações para o upstream, os usuários precisam da permissão "contribute to pull requests" 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 contribuidor para o repositório, pode enviar uma solicitação pull e fazer com que ela seja mesclada, dependendo de como você configurou as políticas de ramificação.

Em organizações que promovem um modelo de fonte interna, fork-and-contribute é um padrão comum. Para proteger e promover ainda mais esse padrão, estamos alterando a permissão para votar em uma solicitação pull de "contribute to pull requests" para "contribute". No entanto, essa alteração não está sendo feita por padrão em todas as organizações. Você tem que optar por participar 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.

Definições do repositório

Próximos passos

Nota

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 Azure DevOps

Como fornecer feedback

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

Faça uma sugestão

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

Obrigado,

Aaron Hallberg