Compartilhar via

API de visualização YAML aprimorada & configurar origem 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.

Recursos

Azure Boards

Azure Pipelines

Azure Artifacts

Azure Boards

Tipos de item de trabalho do sistema em listas de pendências e painéis

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ó estão disponíveis em consultas.

Processar Tipo de Item de Trabalho
Agile Problema
Scrum Impedimento
CMMI Alterar pedido
Problema
Revisão
Risco

Temos o prazer de anunciar que o recurso está agora fora de 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 em seu processo personalizado e clicar na guia Níveis de Backlog. Selecione o nível de lista de pendências de sua escolha (exemplo: Requisitos Backlog) e escolha a opção de edição. Em seguida, adicione o tipo de item de trabalho.

backlogs

Evento de log de auditoria

Adicionamos um novo evento aos logs de auditoria para ajudar os clientes a controlar 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 esse novo evento, os administradores da organização podem controlar melhor quando e quem fez alterações nesses campos.

audit-logs

O limite de repositório de aplicativo GitHub do Azure Boards foi elevado (versão prévia 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. Nesta sprint, alteramos a forma como o Azure Boards se conecta aos seus repositórios do GitHub para oferecer suporte a mais de 100. Se você estiver atingindo o limite de 100 repositórios, avise-nos e podemos habilitar o recurso para aumentar esse limite e desbloqueá-lo. Envie-nos um e-mail diretamente com o nome da sua organização (dev.azure.com/{organização}).

Personalizar estado do item de trabalho quando a solicitação de pull for mesclada (versão prévia privada)

Nem todos os fluxos de trabalho são iguais. Alguns clientes desejam fechar seus itens de trabalho relacionados quando uma Solicitação de Pull for concluída. Outros querem definir os itens de trabalho para outro estado a ser validado antes do fechamento. Devemos permitir as duas coisas.

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

Esse recurso vem de longa data 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 obter o seu feedback antes de investir mais.

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

Azure Pipelines

Comunicados sobre as imagens de pipelines

Observação

As imagens do Azure Pipelines são atualizadas continuamente em um esforço para fornecer aos usuários a melhor experiência possível. Essas atualizações de rotina são predominantemente destinadas a resolver bugs ou software desatualizado. Eles muitas vezes não terão impacto em seus pipelines, no entanto, esse nem sempre é 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 do Windows, Linux e macOS, leia os seguintes anúncios:

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

Aprimoramento dos carregamentos de log do agente

Quando um agente para de se comunicar com o servidor do Azure Pipelines, o trabalho que ele estava executando é abandonado. Se 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 estivesse, ou se atualizasse a página, esses logs do console desapareceriam. 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 volumes de contêiner somente leitura opcionalmente

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 têm 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

Controle refinado sobre o início/a parada do contêiner

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 iniciar e pará-los sozinho. 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 stringificado mapeando o nome do recurso ("builder" do exemplo acima) para a ID do contêiner que o agente gerencia.

Descompactar pacotes de tarefas para cada etapa

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.

Aprimorar a segurança da versão por meio da restrição do escopo dos tokens de acesso

Com base em nossa iniciativa de aprimorar as configurações de segurança para o Azure Pipelines, agora oferecemos 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 por 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 assim que o trabalho é concluído.

Com esta atualização, melhoramos 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.

Aprimoramentos da API de versão prévia do YAML

Alguns sprints atrás, introduzimos a capacidade de visualizar o YAML completo de um pipeline sem executá-lo. Com esta atualização, criamos uma nova URL dedicada para o recurso de 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".

Azure Artifacts

Configurar origens upstream para Pacotes Universais

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

Anteriormente, você podia configurar códigos-fonte 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 códigos-fonte upstream para Pacotes Universais da mesma forma que para outros tipos de pacote; abra suas configurações de 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 códigos-fonte upstream.

upack

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

A API REST de atualização da versão do pacote já está disponível para pacotes do Maven

Agora você pode usar a API REST "Update Package Version" do Azure Artifacts 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 Universal Packages, 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 Obrigatório Tipo Descrição
artifactId caminho TRUE string ID do artefato do pacote
feed caminho TRUE string Nome ou ID do feed
groupId caminho TRUE string ID do grupo do pacote
organization caminho TRUE string O nome da organização do Azure DevOps
version caminho TRUE string Versão do pacote
project caminho string ID do projeto ou nome do projeto
api-version Consulta 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

Corpo da solicitação

Nome Tipo Descrição
Modos de exibição JsonPatchOperação O modo de exibição ao 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ó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.

Ir para o Azure DevOps

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.

Make a suggestion

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

Obrigada,

Aaron Hallberg