Partilhar via

Suporte para expressões de modelo em definições de recursos de repositório e contêiner

  • Artigo

Com esta atualização, incluímos suporte para expressões de modelo em definições de recursos de repositório e contêiner. Agora você pode usar expressões de modelo ao definir a ref propriedade de um repository recurso em um pipeline YAML para escolher a ramificação de um recurso de repositório. Além disso, adicionamos suporte para expressões de modelo ao definir as endpointpropriedades , volumes, portse options de um container recurso em um pipeline YAML.

Confira as notas de versão para obter detalhes.

Azure Boards

Pipelines do Azure

Azure Boards

Anteriormente, alterar um link de item de trabalho exigia pelo menos três etapas para ser concluído. Por exemplo, para alterar um link pai para um link relacionado, você precisa copiar o ID do item de trabalho, remover o link pai, adicionar um novo link existente do tipo relacionado e, finalmente, colar o id copiado e salvar. É um processo complicado.

Resolvemos o problema permitindo que você edite e altere o tipo de link diretamente. Você pode alterar rapidamente o tipo de link em apenas uma etapa.

Gif para demonstração editar tipos de link de item de trabalho.

Nota

Este recurso só estará disponível com a visualização dos Novos Hubs de Painéis.

Criar ponto de extremidade REST de consulta temporária

Vimos várias instâncias de autores de extensões tentando executar consultas não salvas passando a instrução WIQL (Work Item Query Language) pela querystring. Isso funciona bem, a menos que você tenha uma instrução WIQL grande que atinja os limites do navegador no comprimento querystring. Para resolver isso, criamos um novo ponto de extremidade REST para permitir que os autores de ferramentas gerem uma consulta temporária. Usar o id da resposta para passar via querystring elimina esse problema.

Saiba mais na página de documentação da API REST de consultas temporárias.

API de exclusão em lote (visualização privada)

Atualmente, a única maneira de remover itens de trabalho da lixeira é usando essa API REST para excluir um de cada vez. Este pode ser um processo lento e está sujeito a limitação de taxa ao tentar fazer qualquer tipo de limpeza em massa. Em resposta, adicionamos um novo ponto de extremidade da API REST para excluir e/ou destruir itens de trabalho em lote.

Se estiver interessado em participar numa pré-visualização privada deste novo endpoint, envie-nos um e-mail diretamente.

@CurrentIteration macro em Planos de Entrega

Com esta atualização, adicionamos suporte para a @CurrentIteration macro para estilos em Planos de Entrega. Essa macro permitirá que você obtenha a iteração atual do contexto da equipe de cada linha do seu plano.

Gif para demonstrar a macro CurrentIteration em Planos de Entrega.

Pipelines do Azure

Expressões de modelo na definição de recursos do repositório

Adicionamos suporte para expressões de modelo ao definir a ref propriedade de um repository recurso em um pipeline YAML. Este foi um recurso altamente solicitado pela nossa Comunidade de Desenvolvedores.

Existem casos de uso em que você deseja que seu pipeline faça check-out de diferentes ramificações do mesmo recurso de repositório.

Por exemplo, digamos que você tenha um pipeline que constrói seu próprio repositório e, para isso, ele precisa fazer check-out de uma biblioteca de um repositório de recursos. Além disso, digamos que você queira que seu pipeline verifique a mesma ramificação da biblioteca que ele está usando. Por exemplo, se o main pipeline for executado na ramificação, ele deverá verificar a main ramificação do repositório da biblioteca. Se os pipelines forem executados na dev ramificação, ela deverá verificar a ramificação da dev biblioteca.

Até hoje, você tinha que especificar explicitamente a ramificação para fazer check-out e alterar o código do pipeline sempre que a ramificação mudasse.

Agora, você pode usar expressões de modelo para escolher a ramificação de um recurso de repositório. Veja o seguinte exemplo de código YAML para usar para as ramificações não principais do seu pipeline:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Ao executar o pipeline, você pode especificar a ramificação para fazer check-out do library repositório.

Especificar a versão de um modelo a ser estendido no tempo de fila de compilação

Os modelos representam uma ótima maneira de reduzir a duplicação de código e melhorar a segurança de seus pipelines.

Um caso de uso popular é abrigar modelos em seu próprio repositório. Isso reduz o acoplamento entre um modelo e os pipelines que o estendem e facilita a evolução do modelo e dos pipelines de forma independente.

Considere o exemplo a seguir, no qual um modelo é usado para monitorar a execução de uma lista de etapas. O código do Templates modelo está localizado no repositório.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Digamos que você tenha um pipeline YAML que estenda esse modelo, localizado no repositório FabrikamFiber. Até hoje, não era possível especificar a ref propriedade do recurso do repositório dinamicamente ao usar o repositório como fonte do templates modelo. Isso significava que você tinha que alterar o código do pipeline se quisesse: estender um modelo de uma ramificação diferente estender um modelo a partir do mesmo nome de ramificação que seu pipeline, independentemente de qual ramificação você executou seu pipeline

Com a introdução de expressões de modelo na definição de recursos do repositório, você pode escrever seu pipeline da seguinte maneira:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Ao fazer isso, seu pipeline estenderá o modelo na mesma ramificação em que o pipeline é executado, para que você possa garantir que as ramificações do pipeline e do modelo sempre coincidam. Ou seja, se você executar seu pipeline em uma ramificação dev, ele estenderá o modelo especificado pelo template.yml arquivo na dev ramificação do templates repositório.

Ou você pode escolher, em tempo de fila de compilação, qual ramificação de repositório de modelo usar, escrevendo o seguinte código YAML.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Agora, você pode fazer com que seu pipeline na ramificação main estenda um modelo de ramificação dev em uma execução e estenda um modelo de ramificação main em outra execução, sem alterar o código do pipeline.

Ao especificar uma expressão de modelo para a ref propriedade de um recurso de repositório, você pode usar parameters variáveis predefinidas do sistema, mas não pode usar variáveis definidas pela interface do usuário YAML ou Pipelines.

Expressões de modelo na definição de recurso de contêiner

Adicionamos suporte para expressões de modelo ao definir o endpoint, volumes, portse options propriedades de um container recurso em um pipeline YAML. Este foi um recurso altamente solicitado pela nossa Comunidade de Desenvolvedores.

Agora, você pode escrever pipelines YAML como os seguintes.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Você pode usar parameters. e variables. em suas expressões de modelo. Para variáveis, você só pode usar as definidas no arquivo YAML, mas não as definidas na interface do usuário Pipelines. Se você redefinir a variável, por exemplo, usando comandos de log do agente, ela não terá nenhum efeito.

Eventos de auditoria para alterações em aprovações

As aprovações permitem controlar quando um estágio deve ser executado. Isso é comumente usado para controlar implantações em ambientes de produção. A auditoria permite que você atenda aos requisitos de conformidade e monitore a segurança de sua organização do Azure DevOps.

Quando um usuário é solicitado a aprovar um pipeline para implantar em um estágio específico, esse usuário pode optar por reatribuir a aprovação a outra pessoa.

Eventos de auditoria para alterações em aprovações

Até agora, essas ações não eram registradas nos logs de auditoria. Esse problema foi corrigido agora.

Os logs de auditoria conterão uma entrada semelhante à seguinte.

[
    {
        "Id": "2517368925862632546;00000264-0000-8888-8000-000000000000;839ad1ba-f72b-4258-bc3f-88be7a4553b5",
        "CorrelationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "ActivityId": "a298a06c-965f-4e60-9643-2593f2066e37",
        "ActorCUID": "fe950802-bf07-755b-826d-e8dcc066252c",
        "ActorUserId": "fe950802-bf07-755b-826d-e8dcc066252c",
        "ActorUPN": "silviu@fabrikam.app",
        "AuthenticationMechanism": "AAD_Cookie",
        "Timestamp": "2022-10-10T11:26:53.7367453Z",
        "ScopeType": "Organization",
        "ScopeDisplayName": "Fabrikam (Organization)",
        "ScopeId": "547a7316-cdf4-40d2-af16-3215f97d053e",
        "ProjectId": "4bf16944-3595-421f-9947-79d9eb190284",
        "ProjectName": "FabrikamFiber",
        "IpAddress": "127.0.0.1",
        "UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.37",
        "ActionId": "ApproverReassigned",
        "Data": {
            "ApprovalId": "dae6e7c9-2a10-4cd8-b63a-579a6e7ba78d",
            "OldApproverUserId": "692b6e2a-dd61-4872-866a-85498da390fc",
            "OldApproverDisplayName": "[FabrikamFiber]\\Build Administrators",
            "NewApproverUserId": "fe95080b-bf07-655b-226d-e8dcc066252c",
            "NewApproverDisplayName": "Jack Fabrikam",
            "Comment": "All admins are OOO"
        },
        "Details": "Reassigned approver of Approval dae6e7c9-9a10-4cd8-b63a-579a6e7ba78d in Project \"FabrikamFiber\" from \"[FabrikamFiber]\\Build Administrators\" to \"Jack Fabrikam\" with comment \"All admins are OOO\".",
        "Area": "Checks",
        "Category": "Modify",
        "CategoryDisplayName": "Modify",
        "ActorDisplayName": "Silviu"
    }
]

Além disso, ele aparecerá na interface do usuário de auditoria.

Entrada de log na interface do usuário de auditoria

A biblioteca de tarefas expõe o modelo de hospedagem do agente

Os Autores de Tarefas que desejam determinar se um agente está sendo executado em pools hospedados pela Microsoft ou não agora podem usar a função getAgentMode() Biblioteca de Tarefas para determinar o modelo de hospedagem. Isso é benéfico em cenários em que uma tarefa quer influenciar o comportamento com base em ter acesso à rede de um cliente ou não. Uma tarefa pode tentar alcançar um serviço do Azure através de um ponto de extremidade privado se for executada a partir de um agente auto-hospedado ou agentes de conjunto de escala que residem na rede de um cliente. Consulte a referência da tarefa.

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.

Faça uma sugestão

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

Obrigado,

Vijay Machiraju