Улучшения копирования панели мониторинга
Мы рады сообщить о некоторых долгожданных улучшениях в предварительной версии копирования панели мониторинга. Теперь панель мониторинга можно скопировать в другую команду, ту же команду или другой проект, а конфигурация команды и запроса обновляется на новой панели мониторинга. Это еще больше сводит к минимуму работу, необходимую для создания аналогичных панелей мониторинга с нуля для нескольких команд.
Дополнительные сведения см. в следующих описаниях функций.
Общие сведения
Azure Pipelines
- Автоматические повторные попытки для задачи
- Использование входных данных из другой задачи в декораторе
- Улучшения в журнале использования подключений к службам
- Спецификация агента по умолчанию для классических конвейеров теперь — Windows-2019
Отчеты
- Улучшения панели мониторинга копирования
- Фильтрация по значениям NULL в мини-приложении диаграммы сгорания
Общие сведения
Назначение роли администратора Azure DevOps группе Azure AD
Роль администратора Azure DevOps, необходимая для настройки политик клиента Azure AD в Azure DevOps, теперь можно назначить группам Azure AD. Узнайте больше об использовании групп Azure AD для управления назначениями ролей в Azure AD.
Azure Pipelines
Автоматические повторные попытки для задачи
При наличии сложной задачи, которая периодически завершается сбоем в конвейере, для успешного выполнения может потребоваться повторно запустить конвейер. В большинстве случаев лучший способ решения ненадежной задачи или скрипта — исправить саму задачу или скрипт. Например, если задача тестирования завершается сбоем в конвейере из-за неопрятных тестов, рекомендуется исправить несложные тесты и сделать их более надежными. Аналогичным образом, если время от времени происходит сбой скрипта, лучше исправить его, например, введя повторные попытки в скрипте.
Однако в некоторых случаях может потребоваться повторить задачу. Распространенным вариантом использования для этого является задача, которая загружает пакет (например, NuGet, npm и т. д.). Мы часто наблюдали, что эти задачи подвержены сбоям сети и временным сбоям на серверах размещения пакетов. Мы услышали ваши отзывы о том, что было бы лучше автоматически повторить такие неудачные задачи без повторного перезапуска всего конвейера.
На основе ваших отзывов мы добавили функцию для автоматической повторной попытки задачи в конвейере при сбое. Если вы используете конвейеры YAML, эти входные данные можно задать следующим образом:
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
При использовании классических конвейеров сборки или выпуска это свойство можно задать в параметрах управления для задачи.
Ниже приведены некоторые моменты, которые следует учитывать при использовании повторных попыток.
- Сбойная задача немедленно выполняется повторно.
- Нет никаких предположений о идемпотентности задачи. Если задача имеет побочные эффекты (например, если она создала внешний ресурс частично), она может завершиться ошибкой при втором запуске.
- Сведения о количестве повторных попыток, доступных для задачи, отсутствуют.
- В журналы задач добавляется предупреждение, указывающее на то, что перед повторным выполнением завершилось сбоем.
- Все попытки повторить задачу отображаются в пользовательском интерфейсе как часть одного узла задачи.
Примечание
Требуется агент версии 2.194.0 или более поздней. Не поддерживается для задач без агента.
Использование входных данных из другой задачи в декораторе
Недавно мы добавили функцию для автоматического внедрения задачи в конвейер перед другой целевой задачей в этом конвейере. Теперь мы улучшаем эту функцию, позволяя настраивать внедренную задачу с помощью входных параметров целевой задачи. Синтаксис для написания декоратора для этого выглядит следующим образом:
{
"contributions": [
{
"id": <my-required-task>,
"type": "ms.azure-pipelines.pipeline-decorator",
"targets": [
"ms.azure-pipelines-agent-job.pre-task-tasks",
"ms.azure-pipelines-agent-job.post-task-tasks"
],
"properties": {
"template": "my-decorator.yml",
"targettask": <target-task-id>,
"targettaskinputs": ["<name of input>"]
}
}
],
...
}
Эта функция работает только при использовании pre-task-tasks
или post-task-tasks
в качестве целевого объекта для внедрения и указания targettask
в разделе свойств вклада. Затем можно добавить дополнительное свойство с именем targettaskinputs
и указать список имен входных параметров, принятых целевой задачей. Теперь эти входные данные становятся доступными для внедренной задачи.
Распространенный вариант использования, который может быть реализован с помощью такого сценария, выглядит следующим образом. Предположим, вы хотите внедрить задачу, которая автоматически регистрирует имя артефакта, публикуемого сборкой. Имя артефакта является входным PublishBuildArtifacts
для задачи. Внедренная задача теперь может получить тот же входной параметр и использовать его для ведения журнала.
Улучшения в журнале использования подключений к службам
Когда конвейер использует подключение службы, это использование регистрируется в журнале подключения. Администраторы подключения службы могут просмотреть журнал использования, перейдя к параметрам проекта и выбрав соответствующее подключение службы. С этим обновлением были устранены некоторые проблемы с журналом использования подключений к службам. К исправлениям относятся следующие:
- Если подключение службы используется в задании развертывания (а не в обычном задании), это использование не регистрируется.
- Если вы использовали несколько подключений служб на нескольких этапах конвейера, все подключения службы будут отображать запись в журнале использования, даже если некоторые этапы были пропущены.
Спецификация агента по умолчанию для классических конвейеров теперь — Windows-2019
В последних заметках о выпуске мы объявили о расписании устаревания для vs2017-win2016
размещенных образов. В рамках подготовки к этой настройке теперь мы изменяем спецификацию агента по умолчанию при создании новых конвейеров в классических конвейерах на windows-2019
.
Отчеты
Улучшения панели мониторинга копирования
Мы рады сообщить о выходе этапа 2 в общедоступной предварительной версии копирования панели мониторинга! Запросы и конфигурация теперь переносятся с помощью операции копирования. Спасибо за терпение, так как потребовалось немного больше времени, чем ожидалось, чтобы решить некоторые из вопросов.
Предварительный просмотр включен по умолчанию с флагом функции копирования возможностей панели мониторинга (в разделе предварительных версий функций).
Чтобы скопировать панель мониторинга, сначала перейдите на панель мониторинга, которую нужно скопировать. Во-вторых, щелкните меню, чтобы открыть меню Копировать панель мониторинга , а затем щелкните ее.
Затем укажите имя и описание новой панели мониторинга, а затем выберите тип панели мониторинга: Команда или Проект. При выборе панели мониторинга команды новый проект и команда выбираются из соответствующих раскрывающихся списков. Для панели мониторинга Project требуется только проект.
После нажатия кнопки Создать вы перейдете на созданную панель мониторинга. Мини-приложения и макет остаются прежними.
В разделе Общие запросы создается папка с именем новой панели мониторинга. Все запросы для новой панели мониторинга копируются в ту папку. Имена запросов остаются прежними. Мини-приложения с конфигурацией команды обновляются с помощью новой команды. Мини-приложения с конфигурацией команды, копируемыми с панели мониторинга группы на панель мониторинга проекта, сохраняют исходную конфигурацию.
Фильтрация по значениям NULL в мини-приложении диаграммы сгорания
Теперь можно выполнять фильтрацию по значению NULL при использовании условий поля в мини-приложении диаграммы сгорания. Теперь это поведение согласуется с запросом, использующим те же условия поля.
Дальнейшие действия
Примечание
Эти функции будут развернуты в течение следующих двух-трех недель.
Перейдите в Azure DevOps и посмотрите.
Отправка отзыва
Мы хотели бы услышать, что вы думаете об этих функциях. Используйте меню справки, чтобы сообщить о проблеме или предоставить предложение.
Вы также можете получить советы и ответы на свои вопросы от сообщества на Сайте Stack Overflow.
Thanks,
Аарон Халлберг