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 , volumes, portse 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 editar 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) por meio da querystring. 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 endpoint 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 desse novo endpoint, envie um email 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 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 por 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 de biblioteca que ele está usando. Por exemplo, se o main pipeline for executado no branch, ele deverá fazer check-out do main branch do repositório de biblioteca. Se os pipelines forem executados no dev branch, ele deverá fazer check-out do dev branch da biblioteca.

Até hoje, você tinha que especificar explicitamente o branch a ser verificado e alterar o código do pipeline sempre que o branch for alterado.

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 o branch para fazer check-out do library repositório.

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

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

Um caso de uso popular é hospedar 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 modelo está localizado no Templates 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 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 que seu pipeline: estendesse um modelo de um branch diferente estendesse um modelo do mesmo nome de branch do pipeline, independentemente de qual branch você executou o pipeline

Com a introdução de expressões de modelo na definição de recurso 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, o pipeline estenderá o modelo no mesmo branch que o branch no qual o pipeline é executado, para que você possa garantir que os branches 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 ramificação dev do templates repositório.

Ou você pode escolher, no tempo de fila de compilação, qual ramificação do repositório de modelos usar, escrevendo o código YAML a seguir.

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 no branch main estenda um modelo do branch dev em uma execução e estenda um modelo do branch 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 do YAML ou do Pipelines.

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

Adicionamos suporte para expressões de modelo ao definir as endpointpropriedades , volumes, portse options de um container recurso em um pipeline YAML. Este foi um recurso altamente solicitado por 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 do 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 que você controle 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 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.

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

Os autores de tarefas que desejam determinar se um agente está em execução 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 por meio de um ponto de extremidade privado se for executada de um agente auto-hospedado ou de agentes de conjunto de dimensionamento 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