Alterações nas concessões gratuitas do Azure Pipelines
Estamos alterando temporariamente o processo para adquirir concessões gratuitas do Azure Pipelines para lidar com o crescente abuso de agentes hospedados. Por padrão, novas organizações criadas no Azure DevOps podem não obter mais uma concessão gratuita de pipelines simultâneos. Novos usuários terão que enviar um e-mail e fornecer informações adicionais para obter CI/CD gratuito.
Confira a lista de recursos abaixo para obter detalhes.
Azure Pipelines
- Alterações nas concessões gratuitas do Azure Pipelines
- Remoção de políticas de retenção por pipeline em builds clássicos
- Novos controles para variáveis de ambiente em pipelines
- Gerar token irrestrito para builds de bifurcação
- Alteração nos módulos pré-instalados do Az, Azure e Azure RM
Azure Repos
Azure Pipelines
Alterações nas concessões gratuitas do Azure Pipelines
O Azure Pipelines oferece CI/CD gratuito para projetos públicos e privados há vários anos. Como isso equivale a distribuir computação gratuita, sempre foi alvo de abuso – especialmente mineração de criptomoedas. Minimizar esse abuso sempre exigiu energia da equipe. Nos últimos meses, a situação piorou substancialmente, com uma alta porcentagem de novos projetos no Azure DevOps sendo usados para mineração de criptomoedas e outras atividades que classificamos como abusivas. Vários incidentes de serviço no mês passado foram causados por esse abuso, resultando em longos tempos de espera para os clientes existentes.
Para resolver essa situação, adicionamos uma etapa extra para que novas organizações no Azure DevOps obtenham sua concessão gratuita. As seguintes alterações entram em vigor imediatamente:
- Por padrão, novas organizações criadas no Azure DevOps não receberão mais uma concessão gratuita de pipelines simultâneos. Isso se aplica a projetos públicos e privados em novas organizações.
- Para solicitar sua concessão gratuita, envie uma solicitação e forneça os seguintes detalhes claramente:
- Seu nome
- Organização do Azure DevOps para a qual você está solicitando a concessão gratuita
- Se você precisa do subsídio gratuito para projetos públicos ou privados
- Links para os repositórios que você planeja criar (somente projetos públicos)
- Breve descrição do seu projeto (somente projetos públicos)
Analisaremos sua solicitação e responderemos dentro de alguns dias.
Observação
Essa mudança afeta apenas novas organizações. Ele não se aplica a projetos ou organizações existentes. Isso não altera a quantidade de concessão gratuita que você pode obter. Isso apenas adiciona uma etapa extra para obter essa concessão gratuita.
Pedimos desculpas por qualquer inconveniente que isso possa causar a novos clientes que desejam usar o Azure Pipelines para CI/CD. Acreditamos que isso é necessário para continuar fornecendo um alto nível de serviço a todos os nossos clientes. Continuaremos a explorar formas automatizadas de prevenir abusos e restauraremos o modelo anterior assim que tivermos um mecanismo confiável para prevenir abusos.
Remoção de políticas de retenção por pipeline em builds clássicos
Agora você pode configurar políticas de retenção para builds clássicos e pipelines YAML nas configurações do projeto do Azure DevOps. Embora essa seja a única maneira de configurar a retenção para pipelines YAML, você também pode configurar a retenção para pipelines de build clássicos por pipeline. Removeremos todas as regras de retenção por pipeline para pipelines de build clássicos em uma versão futura.
O que isso significa para você: qualquer pipeline de build clássico que ainda tenha regras de retenção por pipeline em breve será regido pelas regras de retenção no nível do projeto.
Para ajudá-lo a identificar esses pipelines, estamos implementando uma alteração nesta versão para mostrar uma faixa na parte superior da página da lista de execuções.
Recomendamos que você atualize seus pipelines removendo as regras de retenção por pipeline. Se o pipeline exigir especificamente regras personalizadas, você poderá usar uma tarefa personalizada no pipeline. Para obter informações sobre como adicionar concessões de retenção por meio de uma tarefa, consulte a documentação definir políticas de retenção para builds, versões e testes.
Novos controles para variáveis de ambiente em pipelines
O agente do Azure Pipelines verifica a saída padrão em busca de comandos de log especiais e os executa. O setVariable comando pode ser usado para definir uma variável ou modificar uma variável definida anteriormente. Isso pode ser potencialmente explorado por um ator fora do sistema. Por exemplo, se o pipeline tiver uma etapa que imprime a lista de arquivos em um servidor ftp, uma pessoa com acesso ao servidor ftp poderá adicionar um novo arquivo, cujo nome contém o setVariable comando e fazer com que o pipeline altere seu comportamento.
Temos muitos usuários que dependem da configuração de variáveis usando o comando logging em seu pipeline. Com esta versão, estamos fazendo as seguintes alterações para reduzir o risco de usos indesejados do setVariable comando.
- Adicionamos uma nova construção para autores de tarefas. Ao incluir um snippet como o seguinte no
task.json, um autor de tarefa pode controlar se alguma variável é definida por sua tarefa.
{
"restrictions": {
"commands": {
"mode": "restricted"
},
"settableVariables": {
"allowed": [
"myVar",
"otherVar"
]
}
},
}
Além disso, estamos atualizando várias tarefas integradas, como ssh, para que não possam ser exploradas.
Por fim, agora você pode usar construções YAML para controlar se uma etapa pode definir variáveis.
steps:
- script: echo hello
target:
settableVariables: none
steps:
- script: echo hello
target:
settableVariables:
- things
- stuff
Gerar token irrestrito para builds de bifurcação
Os usuários do GitHub geralmente usam bifurcações para contribuir com um repositório upstream. Quando o Azure Pipelines cria contribuições de uma bifurcação de um repositório GitHub, ele restringe as permissões concedidas ao token de acesso ao trabalho e não permite que os segredos do pipeline sejam acessados por esses trabalhos. Você pode encontrar mais informações sobre a segurança da construção de bifurcações em nossa documentação.
As mesmas restrições se aplicam por padrão ao criar bifurcações de um repositório GitHub Enterprise Server. Isso pode ser mais restritivo do que o desejado em ambientes fechados, onde os usuários ainda podem se beneficiar de um modelo de colaboração de origem interna. Embora você possa definir uma configuração em um pipeline para disponibilizar segredos para bifurcações, não há nenhuma configuração para controlar o escopo do token de acesso ao trabalho. Com esta versão, estamos dando a você o controle para gerar um token de acesso de trabalho regular, mesmo para compilações de bifurcações.
Você pode alterar essa configuração em Gatilhos no editor de pipeline. Antes de alterar essa configuração, certifique-se de entender completamente as implicações de segurança de habilitar essa configuração.
Alteração nos módulos pré-instalados do Az, Azure e Azure RM
Estamos atualizando o processo de pré-instalação dos módulos Az, Azure e AzureRM para imagens hospedadas no Ubuntu e no Windows para suporte mais eficiente e uso do espaço de imagem.
Durante a semana de 29 de março, todas as versões, exceto a mais recente e a mais popular, serão armazenadas como arquivos e serão extraídas pela tarefa do Azure PowerShell sob demanda. A lista detalhada de alterações está abaixo:
Imagens do Windows
Todas as versões do módulo Az, exceto a mais recente (atualmente, 5.5.0), serão arquivadas
Todos os módulos do Azure, exceto o mais recente (atualmente, 5.3.0) e 2.1.0, serão arquivados
Todos os módulos do AzureRM, exceto o mais recente (atualmente, 6.13.1) e 2.1.0, serão arquivados
Imagens do Ubuntu
- Todos os módulos Az, exceto o mais recente (atualmente, 5.5.0), serão arquivados ou removidos completamente da imagem e serão instalados pela tarefa sob demanda.
Todos os pipelines que usam tarefas do Azure prontas para uso em agentes hospedados funcionarão conforme o esperado e não exigirão atualizações. Se você não usar essas tarefas, alterne seus pipelines para usar a tarefa do Azure PowerShell para evitar alterações nos módulos pré-instalados.
Observação
Essas atualizações não afetarão os pipelines em execução em agentes auto-hospedados.
Azure Repos
Desabilitar um repositório
Os clientes geralmente solicitam uma maneira de desabilitar um repositório e impedir que os usuários acessem seu conteúdo. Por exemplo, você pode querer fazer isso quando:
- Você encontrou um segredo no repositório.
- Uma ferramenta de verificação de terceiros descobriu que um repositório estava fora de conformidade.
Nesses casos, talvez você queira desativar temporariamente o repositório enquanto trabalha para resolver o problema. Com esta atualização, você pode desabilitar um repositório se tiver permissões de exclusão de repositório . Ao desabilitar um repositório, você:
- Pode listar o repositório na lista de repositórios
- Não é possível ler o conteúdo do repositório
- Não é possível atualizar o conteúdo do repositório
- Veja uma mensagem informando que o repositório foi desabilitado quando eles tentam acessar o repositório na interface do usuário do Azure Repos
Depois que as etapas de mitigação necessárias forem executadas, os usuários com a permissão Excluir repositório poderão reabilitar o repositório. Para desabilitar ou habilitar um repositório, vá para Configurações do Projeto, selecione Repositórios e, em seguida, o repositório específico.
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.
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.
Obrigada,
Vijay Machiraju