Azure Pipelines – Atualização do Sprint 194
Recursos
- Post neutral status no GitHub quando um build é ignorado
- O acesso a todos os pipelines está desativado por padrão em recursos protegidos
- Injetar tarefa antes ou depois das tarefas de destino especificadas usando um decorador
- Anunciando um agendamento de substituição para imagens hospedadas no Windows 2016
- Anunciando a substituição de imagens hospedadas no macOS 10.14
Post neutral status no GitHub quando um build é ignorado
Com o Azure Pipelines, você sempre pode validar uma solicitação de pull no GitHub. Você também pode especificar quais caminhos no repositório GitHub devem disparar um pipeline. Por exemplo, o pipeline a seguir é disparado quando uma alteração é enviada por push para code no main branch, mas não é disparada quando uma alteração é enviada por push para a docs pasta.
trigger: none
pr:
branches:
include:
- main
paths:
include:
- code
exclude:
- docs
pool:
vmImage: ubuntu-latest
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
Depois que o pipeline for concluído, o Azure Pipelines postará um status de volta no GitHub. Se você tiver políticas de proteção de branch em vigor para seu repositório GitHub, a status postada pelo Azure Pipelines determinou se a solicitação de pull seria mesclada.
No exemplo acima, se você fez uma alteração no docs, o GitHub bloqueia atualmente a solicitação de pull aguardando que um status seja retornado pelo Azure Pipelines. No entanto, o Azure Pipelines não executa um build de validação, pois esse caminho é excluído do gatilho, tornando impossível concluir a solicitação de pull. Os clientes que configuram gatilhos de exclusão de caminho ou vários pipelines para um único repositório GitHub frequentemente enfrentavam esse desafio.
Seguindo em frente, o Azure Pipelines postará um neutral status de volta ao GitHub quando decidir não executar um build de validação devido a uma regra de exclusão de caminho. Isso fornecerá uma direção clara para o GitHub indicando que o Azure Pipelines concluiu seu processamento.
Modo de exibição de conversa:
Verifique os detalhes:
O acesso a todos os pipelines está desativado por padrão em recursos protegidos
Um pipeline YAML pode contar com um ou mais recursos protegidos. Conexões de serviço, pools de agentes, grupos de variáveis, arquivos seguros e repositórios são exemplos de recursos protegidos, pois um administrador desse recurso pode controlar quais pipelines têm acesso a esse recurso. Os administradores usam o painel de configurações de segurança do recurso para habilitar ou desabilitar pipelines.
Quando você cria um desses recursos, a experiência padrão concede acesso a todos os pipelines, a menos que você o desative explicitamente. Seguindo em frente, para melhorar a postura geral de segurança, o padrão está sendo definido para negar o acesso a todos os pipelines. Para conceder acesso a todos os pipelines, basta ativar a alternância na experiência de criação ou depois que o recurso for criado.
Injetar tarefa antes ou depois das tarefas de destino especificadas usando um decorador
Decoradores são uma maneira de injetar tarefas automaticamente em um pipeline. Eles são comumente usados por equipes centrais em uma organização para executar automaticamente os procedimentos de conformidade necessários. Decoradores podem ser usados com builds clássicos, versões clássicas ou pipelines YAML.
Atualmente, uma tarefa pode ser injetada por meio de um decorador no início de cada trabalho, no final de cada trabalho ou logo após uma tarefa marcar. Para controlar isso, especifique um target na seção de contribuição da extensão do decorador, conforme descrito aqui. Agora estamos expandindo a lista de destinos para incluir o seguinte:
ms.azure-pipelines-agent-job.pre-task-tasks
ms.azure-pipelines-agent-job.post-task-tasks
ms.azure-release-pipelines-agent-job.pre-task-tasks
ms.azure-release-pipelines-agent-job.post-task-tasks
Aqui está um exemplo de um decorador que injeta uma tarefa antes de cada instância de uma PublishPipelineArtifacts tarefa em um pipeline.
{
"manifestVersion": 1,
"contributions": [
{
"id": "my-required-task",
"type": "ms.azure-pipelines.pipeline-decorator",
"targets": [
"ms.azure-pipelines-agent-job.pre-task-tasks"
],
"properties": {
"template": "my-decorator.yml",
"targettask": "ECDC45F6-832D-4AD9-B52B-EE49E94659BE"
}
}
],
"files": [
{
"path": "my-decorator.yml",
"addressable": true,
"contentType": "text/plain"
}
]
}
Anunciando um agendamento de substituição para imagens hospedadas no Windows 2016
Recentemente, disponibilizamos o Windows 2022 como uma imagem hospedada. Com o fim do suporte base para o Windows 2016 em janeiro de 2022, estamos preterindo vs2017-win2016 imagens a partir de 15 de novembro. A desativação completa dessa imagem está prevista para março de 2022. Como essa é uma imagem comumente usada, queríamos dar a você um aviso e tempo suficientes para fazer as alterações necessárias em seus pipelines.
Consulte nossa postagem no blog detalhando como localizar todos os projetos e pipelines usando a imagem hospedada do Windows 2016 e as etapas que você pode seguir para migrar para versões mais recentes.
Anunciando a substituição de imagens hospedadas no macOS 10.14
Recentemente, disponibilizamos o macOS-11 como uma imagem hospedada. Como resultado, vamos preterir a imagem do macOS-10.14 em dezembro de 2021. Os builds que dependem dessa imagem falharão depois que ela for preterida. Você pode encontrar mais detalhes sobre a substituição de várias imagens de nossa postagem no blog.
Próximas etapas
Observação
Esses recursos serão distribuídos nas próximas duas a três semanas.
Acesse o Azure DevOps e dê uma olhada.
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.
Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.