Foram abordadas várias solicitações do Developer Community

  • Artigo

Em resposta aos seus comentários, priorizamos vários recursos que você solicitou no Developer Community. Em Pipelines, adicionamos suporte para a função de divisão de cadeia de caracteres na expressão YAML. Além disso, agora estamos permitindo que você desabilite mostrando o último mensagem do commit para uma execução de pipeline. Em Planos de Entrega, aumentamos o limite de equipe de 15 para 20.

Confira as notas sobre a versão para obter detalhes.

Azure Boards

Azure Pipelines

Azure Boards

Aumentar o limite da equipe de Planos de Entrega de 15 para 20

Os Planos de Entrega permitem exibir várias listas de pendências e várias equipes em sua organização. Anteriormente, você podia exibir 15 listas de pendências de equipe, incluindo uma combinação de listas de pendências e equipes de diferentes projetos. Neste sprint, aumentamos o limite máximo de 15 para 20.

Corrigimos um bug na API Obter Links do Item de Trabalho de Relatório para retornar o valor remoteUrl correto para System.LinkTypes.Remote.Related tipos de link. Antes dessa correção, estávamos retornando o nome errado da organização e uma ID de projeto ausente.

Novas correções de bugs do Hub de Quadros

Neste sprint, corrigimos vários bugs para o New Boards Hub. Você pode ver uma lista de correções de bugs na postagem do blog New Boards Hub, atualização do Sprint 209.

Azure Pipelines

Desabilitar a exibição do último mensagem do commit para uma execução de pipeline

Anteriormente, a interface do usuário do Pipelines era usada para mostrar a última mensagem do commit ao exibir a execução de um pipeline.

Exemplo da última mensagem do commit

Essa mensagem pode ser confusa, por exemplo, quando o código do pipeline YAML reside em um repositório diferente daquele que contém o código que está criando. Ouvimos seus comentários do Developer Community nos pedindo uma maneira de habilitar/desabilitar a anexação dos mensagem do commit mais recentes ao título de cada execução de pipeline.

Com essa atualização, adicionamos uma nova propriedade YAML, chamada appendCommitMessageToRunName, que permite que você faça exatamente isso. Por padrão, a propriedade é definida como true. Quando você defini-lo como false, a execução do pipeline exibirá apenas o BuildNumber.

Exemplo de execução de pipeline com número de build

Exemplo de execução de pipeline com o último mensagem do commit

Recursos consumidos e parâmetros de modelo na API Rest de Execuções de Pipelines

A API REST de Execuções de Pipelines estendida agora retorna mais tipos de artefatos usados por uma execução de pipeline e os parâmetros usados para disparar essa execução. Aprimoramos a API para retornar os container recursos e pipeline e os parâmetros de modelo usados em uma execução de pipeline. Agora você pode, por exemplo, gravar verificações de conformidade que avaliam os repositórios, contêineres e outras execuções de pipeline usadas por um pipeline.

Aqui está um exemplo do novo corpo da resposta.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Adicionar suporte para função de divisão de cadeia de caracteres em expressões de modelo YAML

Os pipelines YAML fornecem maneiras convenientes de reduzir a duplicação de código, como looping por meio each do valor de uma lista ou propriedade de um objeto.

Às vezes, o conjunto de itens a serem iterados é representado como uma cadeia de caracteres. Por exemplo, quando a lista de ambientes a serem implantados é definida pela cadeia de caracteres integration1, integration2.

Enquanto ouvimos seus comentários do Developer Community, ouvimos que você queria uma função de cadeia split de caracteres em expressões de modelo YAML.

Agora, você pode split uma cadeia de caracteres e iterar sobre each suas subcadeias de caracteres.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Não sincronize marcas ao buscar um repositório Git

A tarefa de check-out usa --tags a opção para buscar o conteúdo de um repositório Git. Isso faz com que o servidor efetue fetch de todas as tags, bem como todos os objetos apontados por essas tags. Isso aumenta o tempo para executar a tarefa em um pipeline , especialmente se você tiver um repositório grande com várias marcas. Além disso, a tarefa de check-out sincroniza marcas mesmo quando você habilita a opção de busca superficial, possivelmente derrotando sua finalidade. Para reduzir a quantidade de dados buscados ou extraídos de um repositório Git, agora adicionamos uma nova opção à tarefa para controlar o comportamento das marcas de sincronização. Essa opção está disponível em pipelines clássicos e YAML.

Esse comportamento pode ser controlado a partir do arquivo YAML ou da interface do usuário.

Para recusar a sincronização das marcas por meio do arquivo YAML, adicione a fetchTags: false à etapa de check-out. Quando a opção fetchTags não é especificada, ela é a mesma que se fetchTags: true for usada.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Se você quiser alterar o comportamento de pipelines YAML existentes, talvez seja mais conveniente definir essa opção na interface do usuário em vez de atualizar o arquivo YAML. Para navegar até a interface do usuário, abra o editor YAML do pipeline, selecione Gatilhos e, em seguida, Processar e, em seguida, a etapa Checkout.

Se você especificar essa configuração no arquivo YAML e na interface do usuário, o valor especificado no arquivo YAML terá precedência.

Para todos os novos pipelines criados (YAML ou Clássico), as marcas ainda são sincronizadas por padrão. Essa opção não altera o comportamento de pipelines existentes. As marcas ainda serão sincronizadas nesses pipelines, a menos que você altere explicitamente a opção conforme descrito acima.

Agendamento de brownout atualizado para imagens do Ubuntu 18.04

O Azure Pipelines está substituindo a imagem do Ubuntu 18.04 (ubuntu-18.04) em nossos pools hospedados. Esta imagem será desativada em 1º de dezembro. Você pode começar a ver tempos de fila mais longos.

Para ajudá-lo a identificar melhor quais pipelines estão usando a imagem ubuntu-18.04, estamos planejando brownouts. Os trabalhos falharão durante um período de brownout.

  • As mensagens de aviso são exibidas em execuções de pipeline usando a imagem ubuntu-18.04
  • Um script está disponível para ajudá-lo a encontrar pipelines usando imagens preteridas, incluindo ubuntu-18.04
  • Estamos agendando "brownouts" curtos. Todas as execuções do ubuntu-18.04 falharão durante o período de brownout. Portanto, é recomendável migrar seus pipelines antes dos brownouts.

Agendamento do Brownout (atualizado)

  • 3 de outubro, 12:00 UTC - 3 de outubro, 14:00 UTC
  • 18 de outubro, 14:00 UTC - 18 de outubro, 16:00 UTC
  • 15 de novembro, 18:00 UTC – 15 de novembro, 20:00 UTC
  • 30 de novembro, 20:00 UTC - 30 de novembro, 22:00 UTC
  • 15 de dezembro, 20:00 UTC - 16 de dezembro 00:00 UTC
  • 5 de janeiro, 10.00 UTC - 5 de janeiro, 14.00 UTC
  • 13 de janeiro, 12:00 UTC - 13 de janeiro, 16.00 UTC
  • 18 de janeiro, 14:00 UTC - 18 de janeiro, 18.00 UTC
  • 24 de janeiro, 16:00 UTC - 24 de janeiro, 20.00 UTC
  • 1º de fevereiro, 18.00 UTC - 1º de fevereiro, 22.00 UTC
  • 7 de fevereiro, 16.00 UTC - 7 de fevereiro, 22.00 UTC
  • 13 de fevereiro, 14.00 UTC - 13 de fevereiro, 22.00 UTC
  • 21 de fevereiro, 10.00 UTC - 21 de fevereiro, 22.00 UTC
  • 28 de fevereiro, 10.00 UTC - 28 de fevereiro, 22.00 UTC
  • 6 de março, 00.00 UTC - 7 de março, 00.00 UTC
  • 13 de março, 00.00 UTC - 14 de março, 00.00 UTC
  • 21 de março, 00.00 UTC - 22 de março, 00.00 UTC

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.

Fazer uma sugestão

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

Obrigada,

Aaron Hallberg