Partilhar via


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, as novas organizações criadas no Azure DevOps podem não receber 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.

Pipelines do Azure

Repositórios do Azure

Pipelines do Azure

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 oferecer computação gratuita, sempre foi alvo de abuso – especialmente mineração de criptomoedas. Minimizar esse abuso sempre tirou 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 último mês foram causados por este 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, as novas organizações criadas no Azure DevOps não receberão mais uma concessão gratuita de pipelines simultâneos. Isto aplica-se tanto a projetos públicos como privados em novas organizações.
  • Para solicitar a sua subvenção gratuita, apresente um pedido e forneça claramente os seguintes dados:
    • O seu nome
    • Organização do Azure DevOps para a qual você está solicitando a concessão gratuita
    • Se você precisa da subvenção gratuita 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 (apenas projetos públicos)

Analisaremos o seu pedido e responderemos dentro de alguns dias.

Nota

Essa mudança só impacta novas organizações. Não se aplica a projetos ou organizações existentes. Isso não altera a quantidade de subvenção gratuita que você pode obter. Apenas acrescenta um passo extra para obter essa subvençã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 isto é necessário para continuar a prestar um elevado 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 dispusermos de um mecanismo fiável para prevenir abusos.

Remoção de políticas de retenção por pipeline em compilações clássicas

Agora você pode configurar políticas de retenção para compilações clássicas e pipelines YAML nas configurações do projeto 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 compilação clássicos por pipeline. Removeremos todas as regras de retenção por pipeline para pipelines de compilação clássicos em uma próxima versão.

O que isso significa para você: qualquer pipeline de compilação 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 lançando uma alteração nesta versão para mostrar um banner na parte superior da página da lista de execuções.

Melhorias na retenção de compilaçõ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 compilações, 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 previamente definida. Isto pode ser potencialmente explorado por um interveniente externo ao 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 trecho 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 uma série de tarefas internas, como ssh, para que elas não possam ser exploradas.

  • Finalmente, 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 compilações de fork

Os usuários do GitHub geralmente usam forks para contribuir com um repositório upstream. Quando o Azure Pipelines cria contribuições a partir 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 segredos do pipeline sejam acessados por esses trabalhos. Você pode encontrar mais informações sobre a segurança da construção de garfos em nossa documentação.

As mesmas restrições se aplicam por padrão ao criar bifurcações de um repositório do GitHub Enterprise Server. Isso pode ser mais restritivo do que o desejado nesses 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ê controle para gerar um token de acesso a trabalho regular, mesmo para compilações de forks.

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.

Gerar token irrestrito para compilações de fork

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 Windows para suporte mais eficiente e uso de 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 das alterações encontra-se abaixo:

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

  2. 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 in-the-box em agentes hospedados funcionarão como pretendido 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.

Nota

Essas atualizações não afetarão os pipelines executados em agentes auto-hospedados.

Repositórios do Azure

Desativar um repositório

Os clientes muitas vezes solicitaram uma maneira de desativar 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, convém desativar temporariamente o repositório enquanto trabalha para resolver o problema. Com esta atualização, você pode desativar um repositório se tiver permissões Excluir repositório . Ao desativar 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
  • Ver uma mensagem informando que o repositório foi desabilitado quando eles tentam acessá-lo na interface do usuário do Azure Repos

Após as etapas de mitigação necessárias terem sido tomadas, os usuários com permissão Excluir repositório podem reativar o repositório. Para desativar ou habilitar um repositório, vá para Configurações do projeto, selecione Repositórios e, em seguida, o repositório específico.

Desativar um 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.

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,

Vijay Machiraju