Поддержка подстановочных знаков и условных выражений в файлах конвейера YAML

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

Дополнительные сведения см. в следующих описаниях функций.

Azure Pipelines (система конвейеров Azure)

• Новые условные выражения YAML
• Поддержка подстановочных символов в фильтрах путей
• Поддержка нескольких состояний в Bitbucket
• Разрешить участникам пропустить поиск комментариев PR перед проверкой сборки
• Windows Server 2022 с Visual Studio 2022 теперь доступен в размещенных майкрософт агентах (предварительная версия)
• Общая доступность macOS 11 Big Sur на агентах, размещенных на платформе Microsoft
• Удаление образа Ubuntu 16.04 на агентах, размещенных Microsoft

Azure Repos

• Новые страницы TFVC общедоступны
• Настройка прав для создателей веток так, чтобы они не получали право "Управление разрешениями" на своих ветках
• Запретить пользователям вилки голосовать на своих вышестоящих PR

Azure Pipelines (система конвейеров Azure)

Новые условные выражения YAML

Написание условных выражений в файлах YAML стало проще с использованием выражений ${{ else }} и ${{ elseif }}. Ниже приведены примеры использования этих выражений в файлах конвейеров YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux') }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

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

Подстановочные карточки можно использовать при указании ветвей включения и исключения для триггеров CI или PR в файле YAML конвейера. Однако их нельзя использовать при указании фильтров путей. Например, нельзя включать все пути, которые соответствуют src/app/**/myapp*. Некоторые клиенты отметили это как неудобство. Это обновление заполняет этот пробел. Теперь можно использовать подстановочные знаки (**, *, или ?) при указании фильтров путей.

Поддержка нескольких состояний в Bitbucket

Azure Pipelines интегрируется с репозиториями Bitbucket и поддерживает триггеры CI и PR. Можно настроить несколько конвейеров из одного репозитория Bitbucket. Однако, когда эти конвейеры были завершены, в Bitbucket можно увидеть только одно состояние. Мы слышали отзывы от сообщества разработчиков с просьбой просмотреть состояние каждого конвейера отдельно в Bitbucket. В этом обновлении мы обновили вызовы API к Bitbucket и передаем дополнительные сведения об имени конвейера.

Разрешить участникам пропускать проверку комментариев к PR перед валидацией сборки.

При использовании Azure Pipelines с репозиториями GitHub мы рекомендуем не запускать конвейер проверки pull request для вкладов, полученных из форкнутого репозитория. Рекомендуется, чтобы один из участников репозитория сначала проверил изменение, а затем добавил комментарий к PR для запуска пайплайна. Эти параметры можно настроить, выбрав меню "Триггеры" (для конвейеров YAML) или вкладку "Триггеры" (для классических конвейеров сборки) в веб-редакторе конвейера. Вместо того чтобы требовать, чтобы каждый PR из форка был сначала проверен участником команды, вы можете применять эту политику только для вкладов, поступающих от лиц, которые не являются членами команды.

В этом обновлении мы можем пропустить запрос на pr-комментарий от вкладов, полученных любым участником. В качестве участника, отличного от команды, при создании вилки и создании pr в вышестоящий репозиторий вы не считаетсяе участником вышестоящего репозитория, пока ваш PR не будет объединен. После объединения pr вы будете считаться участником. Выбрав новый параметр, показанный ниже, когда не-член команды отправляет PR из форка в первый раз, кто-то из вашей команды должен будет просмотреть его и добавить комментарий, чтобы запустить пайплайн. Но после объединения PR любые дальнейшие вклады, внесенные этим не членом команды, напрямую запустят пайплайн без ожидания комментариев в PR.

Windows Server 2022 с Visual Studio 2022 теперь предоставляется в агентах, размещенных Майкрософт (предварительная версия)

Windows Server 2022 и Visual Studio Enterprise 2022 Preview теперь доступны в предварительной версии на агентах, размещенных Microsoft. Его можно использовать, ссылаясь на windows-2022 как на изображение в рабочем процессе.

pool:
  vmImage: 'windows-2022'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '**/*.sln'
- task: VSBuild@1 # Visual Studio 2022 build
  inputs:
    solution: '**/*.sln'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: 'Any CPU'
    configuration: 'Release'

Если вы ссылаетесь на пул windows-latest в конвейерах YAML, он по-прежнему будет означать windows-2019, а не windows-2022, а последний находится в предварительной версии.

Образ конвейера Windows Server 2022 имеет различные средства и версии инструментов по сравнению с Windows Server 2019. Всё можно просмотреть в объявлении программного обеспечения и в репозитории virtual-environments на странице документации.

Общедоступность macOS 11 на агентах, размещенных Microsoft

macOS 11 теперь доступен в общем порядке на агентах, размещаемых Microsoft. Его можно использовать, ссылаясь на macos-11 как на изображение в рабочем процессе.

pool:
  vmImage: macos-11

Удаление образа Ubuntu 16.04 в агентах, размещённых Microsoft

Как было объявлено ранее, мы удалим образ Ubuntu 16.04 из агентов, размещенных корпорацией Майкрософт, 20 сентября 2021 г. Традиционная 5-летняя поддержка Ubuntu 16.04 от компании Canonical закончилась в апреле 2021 года. Вам потребуется перенести конвейеры ubuntu-16.04 в ubuntu-18.04 или ubuntu-latest, которые будут работать в Ubuntu 20.04 LTS.

Сборки, использующие Ubuntu-16.04, уже фиксируют предупреждение. Чтобы убедиться, что все знают об этом изменении, мы запланировали 2 коротких "браунутов". Сборки Ubuntu 16.04 будут завершаться сбоем в течение периода пониженного напряжения. Поэтому рекомендуется перенести рабочие процессы до 6 сентября 2021 г.

Отключения запланированы на следующие даты и время (обратите внимание, что они были продлены на час по сравнению с ранее объявленным временем): 6 сентября 2021 г. 16:00 UTC – 22:00 UTC 14 сентября 2021 г. 16:00 UTC – 22:00 UTC

Azure Repos

Новые страницы TFVC теперь доступны для всех

Мы обновляли различные страницы в Azure DevOps, чтобы использовать новую веб-платформу с целью повышения согласованности и повышения доступности различных служб. Страницы TFVC были обновлены для использования новой веб-платформы, и эти изменения были в предварительной версии в течение нескольких месяцев. В этом обновлении мы делаем новые страницы TFVC общедоступными. В этом обновлении вы больше не увидите функцию предварительной версии "Новые страницы TFVC" в параметрах пользователя.

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

Когда вы создаете новую ветвь, вы получаете возможность "Управление разрешениями" на этой ветви. Это разрешение позволяет изменять разрешения других пользователей или допускать дополнительных пользователей для участия в этой ветви. Например, создатель ветви может использовать это разрешение, чтобы разрешить другому внешнему пользователю вносить изменения в код. Кроме того, они могут разрешить конвейеру (удостоверение службы сборки) изменить код в этой ветви. В некоторых организациях с более высокими требованиями к соответствию пользователям не следует вносить такие изменения.

С помощью этого обновления вы можете настроить любые и все репозитории в командном проекте и ограничить создателей веток от получения разрешения "Управление разрешениями". Для этого перейдите к параметрам проекта, выберите репозитории, а затем параметры для всех репозиториев или определенного репозитория.

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

Запретить пользователям форков голосовать за исходные PR.

Используя Azure Repos, пользователи с разрешением для чтения в репозитории могут создать форк репозитория и вносить изменения в нем. Чтобы отправить пулл-реквест с изменениями в вышестоящий поток, пользователям требуется разрешение на участие в пулл-реквестах. Однако эти права доступа также регулируют, кто может голосовать за пулл-реквесты в исходном репозитории. В результате вы можете оказаться в ситуациях, когда пользователь, который не является участником репозитория, может отправить pull request и привести к его объединению в зависимости от способа настройки политик ветви.

В организациях, которые способствуют применению внутренней модели открытого исходного кода, шаблон «форкать и вносить изменения» является распространённым. Чтобы защитить и повысить этот шаблон дальше, мы изменим разрешение на голосование по запросу на вытягивание от "участие в запросе на вытягивание" на "участие". Однако это изменение не выполняется по умолчанию во всех организациях. Чтобы переключить это разрешение, необходимо подписаться и выбрать новую политику в вашем репозитории с именем "Строгий режим голосования". Рекомендуется сделать это, если вы используете вилки в Azure Repos.

Дальнейшие шаги

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

Как предоставить отзыв

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

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

Спасибо,

Аарон Холлберг