Compartilhar via

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

  • Artigo

Com essa 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 , volumesports, e options de um container recurso em um pipeline YAML.

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

Azure Boards

Azure Pipelines

Azure Boards

Anteriormente, a alteração de um link de item de trabalho exigia pelo menos três etapas para ser concluída. Por exemplo, para alterar um link pai para um link relacionado, você precisa copiar a ID do item de trabalho, remover o link pai, adicionar um novo link existente do tipo relacionado e, finalmente, colar a ID copiada 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, edite tipos de link de item de trabalho.

Observação

Esse recurso só estará disponível com a versão prévia do New Boards Hubs.

Criar ponto de extremidade REST de consulta temporária

Vimos várias instâncias de autores de extensão tentando executar consultas não salvas passando a instrução WIQL (Work Item Query Language) pela cadeia de caracteres query. Isso funciona bem, a menos que você tenha uma instrução WIQL grande que atinja os limites do navegador no comprimento da cadeia de caracteres de consulta. Para resolver isso, criamos um novo ponto de extremidade REST para permitir que os autores da ferramenta 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 você estiver interessado em participar de uma 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 de equipe de cada linha em seu plano.

Gif para demonstrar a macro CurrentIteration em Planos de Entrega.

Azure Pipelines

Expressões de modelo na definição de recurso 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 cria 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 mesmo está usando. Por exemplo, se o main pipeline for executado na ramificação, ele deverá fazer check-out main da ramificação do repositório da biblioteca. Se os pipelines forem executados na dev ramificação, ela deverá fazer check-out da 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 for alterada.

Agora, você pode usar expressões de modelo para escolher a ramificação de um recurso de repositório. Consulte o exemplo a seguir de código YAML a ser usado para as ramificações não principais do 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 estendida 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 estende esse modelo, localizado no repositório FabrikamFiber. Até hoje, não era possível especificar a ref templates propriedade do recurso do repositório dinamicamente ao usar o repositório como fonte de modelo. Isso significava que você tinha que alterar o código do pipeline se quisesse que o pipeline: estender um modelo de uma ramificação diferente estender um modelo 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 que a ramificação na qual o pipeline é executado, para que você possa garantir que as ramificações do pipeline e do modelo sempre correspondam. 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, no momento da fila de compilação, qual ramificação do 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 da ramificação dev em uma execução e estenda um modelo da 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 e 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 as endpointpropriedades , volumesports, e options 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 o seguinte.

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 aquelas 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 geralmente é 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 de DevOps do Azure.

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

Tarefa Os autores 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 deseja influenciar o comportamento com base em ter acesso à rede de um cliente ou não. Uma tarefa pode tentar acessar um serviço do Azure em um ponto de extremidade privado se for executada a partir de um agente autohospedado ou agentes de conjunto de escala que residem na rede de um cliente. Consulte a referência da tarefa.

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 obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigada,

Vijay Machiraju