Partilhar via

API de visualização YAML aprimorada & configuram fonte upstream para pacotes universais

  • Artigo

Neste sprint, estamos lançando um novo endpoint de API que permite recuperar o corpo YAML finalizado. Também temos o prazer de anunciar que estamos adicionando a capacidade de configurar sua fonte upstream para pacotes universais com esta versão.

Confira a lista de recursos abaixo para obter detalhes.

Funcionalidades

Azure Boards

Pipelines do Azure

Artefactos do Azure

Azure Boards

Tipos de itens de trabalho do sistema em registos de tarefas pendentes e quadros

Iniciamos uma visualização privada de um recurso que permite adicionar um tipo de item de trabalho do sistema ao nível de lista de pendências escolhido. Historicamente, esses tipos de item de trabalho só estavam disponíveis a partir de consultas.

Processo Tipo de Item de Trabalho
Ágil Problema
Scrum Impedimento
CMMI Pedido de Alteração
Problema
Rever
Risco

Estamos felizes em anunciar que o recurso está agora fora da pré-visualização e disponível para todas as organizações. Adicionar um tipo de item de trabalho do sistema a um nível de lista de pendências é simples. Basta entrar no seu processo personalizado e clicar na guia Níveis de lista de pendências. Selecione o nível de escolha da sua lista de pendências (exemplo: Lista de requisitos em atraso) e escolha a opção de edição. Em seguida, adicione o tipo de item de trabalho.

backlogs

Evento de registo de auditoria

Adicionamos um novo evento aos logs de auditoria para ajudar os clientes a rastrear melhor as alterações relacionadas ao processo. Um evento será registrado sempre que os valores em uma lista de opções forem alterados. As alterações nos campos da lista de opções geralmente são as alterações mais comuns feitas em um processo. Com este novo evento, os administradores da organização podem controlar melhor quando e quem fez alterações nesses campos.

audit-logs

Limite do repositório de aplicações do GitHub para o Azure Boards gerado (pré-visualização privada)

Se você estiver usando o aplicativo Azure Boards do mercado GitHub, há um limite de 100 repositórios do GitHub aos quais você pode se conectar.  Isso se torna um bloqueador para grandes organizações que podem ter mais de 100 repositórios. Neste sprint, alterámos a forma como o Azure Boards se liga aos seus repositórios GitHub para suportar mais de 100. Se você estiver atingindo o limite de 100 repos, informe-nos e podemos habilitar o recurso para aumentar esse limite e desbloqueá-lo. Por favor, envie-nos um e-mail diretamente com o nome da sua organização (dev.azure.com/{organization}).

Personalizar o estado do item de trabalho quando o pedido Pull for intercalado (pré-visualização privada)

Nem todos os fluxos de trabalho são iguais. Alguns clientes desejam fechar seus itens de trabalho relacionados quando uma solicitação pull é concluída. Outros querem definir os itens de trabalho para outro estado para serem validados antes de fechar. Devemos permitir ambos.

A partir do sprint 174, temos um novo recurso que permite definir os itens de trabalho para o estado desejado quando a solicitação pull é mesclada e concluída. Para fazer isso, verificamos a descrição da solicitação pull e procuramos o valor do estado seguido pelo #mention do(s) item(ns) de trabalho. Neste exemplo, estamos definindo duas histórias de usuário como Resolvidas e fechando duas tarefas.

work-item-state

Este recurso já vem de muito tempo e estamos animados para ver o que você pensa. Para começar, estamos apenas verificando a descrição da solicitação pull e não incluindo nenhuma alteração na interface do usuário. Queríamos receber o seu feedback antes de investir mais.

Se estiver interessado em participar na pré-visualização privada, envie-nos um e-mail diretamente. Não se esqueça de incluir a sua organização (dev.azure.com/{organization}).

Pipelines do Azure

Anúncios de imagens de pipelines

Nota

As imagens do Azure Pipelines são atualizadas continuamente em um esforço para fornecer aos usuários a melhor experiência possível. Estas atualizações de rotina destinam-se predominantemente a resolver bugs ou software desatualizado. Muitas vezes, não terão impacto nos seus gasodutos, no entanto, nem sempre é esse o caso. Seu pipeline pode ser afetado se depender de um software que foi removido ou atualizado na imagem.

Para saber mais sobre as próximas atualizações em nossas imagens para Windows, Linux e macOS, leia os seguintes anúncios:

Para ver as notas de versão das alterações futuras (pré-lançamento) e implementadas, subscreva as seguintes notas de versão:

Carregamentos de registos do agente melhorados

Quando um agente para de se comunicar com o servidor do Azure Pipelines, o trabalho que estava sendo executado é abandonado. Se por acaso você estava olhando para os logs do console de streaming, você pode ter obtido algumas pistas sobre o que o agente estava fazendo antes de parar de responder. Mas se você não estava, ou se você atualizou a página, esses logs do console desapareceram. Com esta versão, se o agente parar de responder antes de enviar seus logs completos, manteremos os logs do console como a próxima melhor coisa. Os logs do console são limitados a 1000 caracteres por linha e ocasionalmente podem estar incompletos, mas são muito mais úteis do que não mostrar nada! Examinar esses logs pode ajudá-lo a solucionar problemas de seus próprios pipelines, e certamente ajudará nossos engenheiros de suporte quando eles ajudarem na solução de problemas.

Montar opcionalmente volumes de contentores só de leitura

Quando você executa um trabalho de contêiner no Azure Pipelines, vários volumes que contêm o espaço de trabalho, tarefas e outros materiais são mapeados como volumes. Esses volumes usam como padrão o acesso de leitura/gravação. Para maior segurança, você pode montar os volumes somente leitura alterando a especificação do contêiner no YAML. Cada chave em mountReadOnly pode ser definida como true somente leitura (o padrão é false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Controlo otimizado para início/paragem de contentores

Em geral, recomendamos que você permita que o Azure Pipelines gerencie o ciclo de vida de seus contêineres de trabalho e serviço. No entanto, em alguns cenários incomuns, você pode querer começar e pará-los você mesmo. Com esta versão, incorporamos esse recurso à tarefa do Docker.

Aqui está um exemplo de pipeline usando o novo recurso:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Além disso, incluímos a lista de contêineres em uma variável de pipeline, Agent.ContainerMapping. Você pode usar isso se quiser inspecionar a lista de contêineres em um script, por exemplo. Ele contém um objeto JSON stringified mapeando o nome do recurso ("builder" do exemplo acima) para o ID do contêiner que o agente gerencia.

Deszipar grupos de tarefas para cada passo

Quando o agente executa um trabalho, ele primeiro baixa todos os pacotes de tarefas exigidos pelas etapas do trabalho. Normalmente, para desempenho, ele descompacta as tarefas uma vez por trabalho, mesmo que a tarefa seja usada em várias etapas. Se você tiver preocupações sobre código não confiável alterando o conteúdo descompactado, você pode trocar um pouco de desempenho fazendo com que o agente descompacte a tarefa em cada uso. Para habilitar esse modo, passe --alwaysextracttask ao configurar o agente.

Melhor a segurança das versões ao restringir o âmbito dos tokens de acesso

Com base em nossa iniciativa de aprimorar as configurações de segurança para o Azure Pipelines, agora damos suporte à restrição do escopo de tokens de acesso para versões.

Cada trabalho executado em versões recebe um token de acesso. O token de acesso é usado pelas tarefas e pelos seus scripts para chamar de volta para o Azure DevOps. Por exemplo, usamos o token de acesso para obter código-fonte, baixar artefatos, carregar logs, resultados de teste ou fazer chamadas REST no Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído.

Com esta atualização, nos baseamos em melhorar a segurança do pipeline, restringindo o escopo dos tokens de acesso e estendendo o mesmo para versões clássicas.

Esse recurso estará ativado por padrão para novos projetos e organizações. Para organizações existentes, você deve habilitá-lo em Configurações de pipelines de configurações > da > organização. > Limite o escopo de autorização de trabalho ao projeto atual para pipelines de versão. Saiba mais aqui.

Melhoramentos da API de pré-visualização do YAML

Alguns sprints atrás, introduzimos a capacidade de visualizar o YAML completo de um pipeline sem executá-lo. Com esta atualização, criámos um novo URL dedicado para a funcionalidade de pré-visualização. Agora você pode POST para https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview recuperar o corpo YAML finalizado. Essa nova API usa os mesmos parâmetros que enfileirar uma execução, mas não requer mais a permissão "Queue builds".

Artefactos do Azure

Configurar as origens dos Universal Packages

Agora você pode configurar seus feeds de Artefatos do Azure para baixar automaticamente Pacotes Universais de fontes upstream sob demanda.

Anteriormente, você podia configurar fontes upstream em seu feed para pacotes NuGet, Python, Maven e npm, mas não para Pacotes Universais. Isso ocorreu devido a uma diferença na tecnologia de armazenamento usada para Pacotes Universais, que suportam pacotes muito maiores do que outros tipos de pacotes suportados.

Agora você pode configurar fontes upstream para Pacotes Universais da mesma forma que para outros tipos de pacotes; abra as configurações do feed, clique em Fontes upstream - Adicionar fonte upstream ->> e escolha o tipo de fonte certo para você. Você verá Pacotes Universais (UPack) como uma nova opção na próxima visualização (veja a imagem abaixo). Para obter mais informações, consulte a documentação de configuração de fontes upstream.

upack

Observe que os Pacotes Universais em fontes upstream só são suportados entre feeds na mesma Organização de DevOps.

Atualização da API REST da Versão dos Pacotes agora disponível para pacotes do Maven

Agora você pode usar a API REST "Versão do Pacote de Atualização" dos Artefatos do Azure para atualizar as versões do pacote Maven. Anteriormente, você podia usar a API REST para atualizar versões de pacotes para NuGet, Maven, npm e Pacotes Universais, mas não pacotes Maven.

Para atualizar pacotes Maven, use o comando HTTP PATCH da seguinte maneira.

PATCH https://pkgs.dev.azure.com/{organization}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Você pode definir o seguinte:

Parâmetros de URI

Nome In Necessário Tipo Descrição
artifactId path TRUE string ID do artefato do pacote
feed path TRUE string Nome ou ID do feed
groupId path TRUE string ID de grupo do pacote
organização path TRUE string O nome da organização do Azure DevOps
versão path TRUE string Versão do pacote
projeto path string ID do projeto ou nome do projeto
api-version query TRUE string Versão da API a ser usada. Isso deve ser definido como '5.1-preview.1' para usar esta versão da api

Órgão do Pedido

Nome Tipo Descrição
vistas JsonPatchOperation A vista à qual a versão do pacote será adicionada

Para obter mais informações, consulte a documentação da API REST à medida que ela é atualizada.

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.

Make a suggestion

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

Obrigado,

Aaron Hallberg