Поделиться через

Поддержка выражений шаблонов в определениях ресурсов репозитория и контейнера

  • Статья

В этом обновлении мы включили поддержку выражений шаблонов в определениях ресурсов репозитория и контейнера. Теперь можно использовать выражения шаблонов при определении ref свойства repository ресурса в конвейере YAML, чтобы выбрать ветвь ресурса репозитория. Кроме того, мы добавили поддержку выражений container шаблонов при определении endpointресурса volumesportsи options свойств ресурса в конвейере YAML.

Дополнительные сведения см. в заметках о выпуске.

Azure Boards

Azure Pipelines

Azure Boards

Ранее для изменения ссылки на рабочий элемент требуется по крайней мере три шага. Например, чтобы изменить родительскую ссылку на связанную ссылку, необходимо скопировать идентификатор рабочего элемента, удалить родительскую ссылку, добавить новую существующую ссылку типа, а затем вставить скопированный идентификатор и сохранить. Это громоздкий процесс.

Мы решили проблему, позволяя изменять и изменять тип ссылки напрямую. Вы можете быстро изменить тип ссылки только на одном шаге.

Gif для демонстрации типов ссылок рабочих элементов.

Примечание.

Эта функция будет доступна только в предварительной версии New Boards Hubs.

Создание временной конечной точки REST запроса

Мы видели несколько экземпляров авторов расширений, пытающихся выполнять несохраненные запросы, передав инструкцию wiQL для языка запросов рабочих элементов (WIQL). Это работает хорошо, если у вас нет большой инструкции WIQL, которая достигает ограничений браузера на длину строки запросов. Для этого мы создали новую конечную точку REST, чтобы разрешить авторам инструментов создавать временный запрос. Использование идентификатора из ответа для передачи через запросы устраняет эту проблему.

Дополнительные сведения см. на странице документации по REST API для временных запросов.

API пакетного удаления (частная предварительная версия)

В настоящее время единственным способом удаления рабочих элементов из корзины является использование этого REST API для одновременного удаления. Это может быть медленный процесс и подвержен ограничению скорости при попытке сделать любую массовую очистку. В ответ мы добавили новую конечную точку REST API для удаления и (или) уничтожения рабочих элементов в пакете.

Если вы заинтересованы в участии в частной предварительной версии этой новой конечной точки, отправьте нам письмо напрямую.

@CurrentIteration макрос в планах доставки

В этом обновлении мы добавили поддержку @CurrentIteration макроса для стилей в планах доставки. Этот макрос позволит получить текущую итерацию из контекста команды каждой строки в плане.

Gif для демонстрации макроса CurrentIteration в планах доставки.

Azure Pipelines

Выражения шаблонов в определении ресурсов репозитория

Мы добавили поддержку выражений repository шаблонов при определении ref свойства ресурса в конвейере YAML. Это была очень запрашиваемая функция нашими Сообщество разработчиков.

Существуют случаи использования, когда конвейер будет проверять разные ветви одного ресурса репозитория.

Например, предположим, что у вас есть конвейер, который создает собственный репозиторий, и для этого необходимо извлечь библиотеку из репозитория ресурсов. Кроме того, предположим, что вы хотите, чтобы конвейер проверял ту же ветвь библиотеки, что и сама по себе. Например, если конвейер выполняется в main ветви, он должен проверить main ветвь репозитория библиотеки. Если конвейеры выполняются в dev ветви, она должна проверить dev ветвь библиотеки.

До сегодняшнего дня необходимо явно указать ветвь для проверки и изменить код конвейера всякий раз, когда ветвь изменяется.

Теперь можно использовать выражения шаблонов для выбора ветви ресурса репозитория. См. следующий пример кода YAML для использования для не основных ветвей конвейера:

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

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

При запуске конвейера можно указать ветвь для library получения репозитория.

Укажите версию шаблона, расширяемую во время сборки

Шаблоны представляют собой отличный способ уменьшить дублирование кода и повысить безопасность конвейеров.

Одним из популярных вариантов использования является хранение шаблонов в собственном репозитории. Это уменьшает связь между шаблоном и конвейерами, расширяющими ее, и упрощает развитие шаблона и конвейеров независимо.

Рассмотрим следующий пример, в котором шаблон используется для мониторинга выполнения списка шагов. Код шаблона находится в репозитории Templates .

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

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

Предположим, что у вас есть конвейер YAML, расширяющий этот шаблон, расположенный в репозитории FabrikamFiber. До сих пор невозможно указать ref свойство templates ресурса репозитория динамически при использовании репозитория в качестве источника шаблона. Это означало, что вам пришлось изменить код конвейера, если вы хотите, чтобы конвейер был расширен: расширение шаблона из другой ветви расширяет шаблон из того же имени ветви, что и конвейер, независимо от того, какая ветвь вы запустили конвейер.

Введение выражений шаблонов в определение ресурса репозитория позволяет написать конвейер следующим образом:

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

Таким образом, конвейер расширит шаблон в той же ветви, что и ветвь, в которой выполняется конвейер, чтобы убедиться, что ветви конвейера и шаблона всегда совпадают. То есть, если вы запускаете конвейер в ветви dev, он расширит шаблон, указанный template.yml файлом в dev ветви templates репозитория.

Вы также можете выбрать в очереди сборки, какую ветвь репозитория шаблонов использовать, написав следующий код 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

Теперь конвейер можно расширить main шаблон из ветви dev в одном запуске и расширить шаблон из ветви main в другом запуске, не изменяя код конвейера.

При указании выражения шаблона для ref свойства ресурса репозитория можно использовать parameters и системные предопределенные переменные, но нельзя использовать определяемые пользовательскими переменными YAML или Pipelines.

Выражения шаблонов в определении ресурсов контейнера

Мы добавили поддержку выражений container шаблонов при определении endpoint, volumesportsи options свойств ресурса в конвейере YAML. Это была очень запрашиваемая функция нашими Сообщество разработчиков.

Теперь можно написать конвейеры YAML, как показано ниже.

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'

Вы можете использовать parameters. и variables. в выражениях шаблона. Для переменных можно использовать только те, которые определены в файле YAML, но не те, которые определены в пользовательском интерфейсе Pipelines. Если переменная переопределяется, например с помощью команд журнала агента, она не будет иметь никакого эффекта.

Аудит событий для изменений в утверждениях

Утверждения позволяют управлять выполнением этапа. Это часто используется для управления развертываниями в рабочих средах. Аудит позволяет соответствовать требованиям и отслеживать безопасность организации Azure DevOps.

Когда пользователю предлагается утвердить конвейер для развертывания на определенном этапе, пользователь может переназначить утверждение другому пользователю.

Аудит событий для изменений в утверждениях

До сих пор такие действия не регистрируются в журналах аудита. Эта проблема устранена сейчас.

Журналы аудита будут содержать запись, аналогичную приведенной ниже.

[
    {
        "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"
    }
]

Кроме того, он будет отображаться в пользовательском интерфейсе аудита.

Запись журнала в пользовательском интерфейсе аудита

Библиотека задач предоставляет модель размещения агента

Авторы задач, которые хотят определить, работает ли агент в пулах, размещенных корпорацией Майкрософт, или теперь не может использовать функцию getAgentMode() библиотеки задач для определения модели размещения. Это полезно в сценариях, когда задача хочет повлиять на поведение на основе доступа к сети клиента или нет. Задача может попытаться связаться со службой Azure через частную конечную точку, если она выполняется из локального агента или агентов масштабируемого набора, находящихся в сети клиента. См . справочник по задачам.

Следующие шаги

Примечание.

Эти функции будут развернуты в течение следующих двух-трех недель.

Перейдите к Azure DevOps и посмотрите.

Перейдите в Azure DevOps

Отправка отзыва

Мы хотели бы услышать то, что вы думаете об этих функциях. Используйте меню справки, чтобы сообщить о проблеме или указать предложение.

Внести предложение

Вы также можете получить советы и ваши вопросы, ответы сообщества на Stack Overflow.

Thanks,

Vijay Machiraju