Некоторые конвейеры сборки ADO отображают все рабочие элементы в связанных элементах, а другие — только соответствующие элементы. Ищем идеи
Я пытаюсь обновить связанные рабочие элементы со статусами сборки в ADO. Я создал скрипт, который получает связанные элементы из RestApi, используя build.id, и публикует необходимые обновления. Скрипт работает нормально. Моя проблема в том, что я обнаружил, что в некоторых сборках есть 1-2 связанных элемента, но в других сборках перечислены все изменения и рабочие элементы, что в данном случае является огромной проблемой.
Рабочий процесс в репо выглядит следующим образом. Разработчики создают новые ветки из ветки разработки, фиксируют изменения и возвращают PR в разработку, прикрепляя к PR правильный билет. Конвейеры запускаются при слиянии и после всех этапов выполняют PR в main.
Может ли кто-нибудь объяснить, почему в некоторых сборках отображаются правильные связанные элементы из PR, а в некоторых все изменения отображаются как связанные элементы? Я не верю, что это сделано намеренно.
Есть ли у кого-нибудь идеи о том, как я могу получить идентификатор PR программно из самой сборки? Если бы я мог получить PR, я бы просто запросил restApi для элементов, связанных с PR, вместо сборки.
Есть ли еще творческие идеи, как справиться с этим?
Ответы 1
Обновлять
Основываясь на дальнейших обсуждениях, мы увидели на скриншоте, что сборка была вызвана коммитом PR-слияния. Обратите внимание, что PR может внести в целевую ветку несколько коммитов, что представляет собой более одного изменения в коде целевой ветки PR, а не один коммит слияния. Таким образом, WIT, связанный с этими коммитами, также был связан с этой сборкой.
Не существует предопределенной переменной конвейера для извлечения идентификатора PR коммита слияния. Вы можете разделить идентификатор PR от $(Build.SourceVersionMessage), если PR завершен с типом слияния, сообщение о фиксации слияния которого начинается с Merged PR <prId>
variables:
prId: ${{ split(split(variables['Build.SourceVersionMessage'], ':')[0], 'Merged PR ')[1] }}
- Может ли кто-нибудь объяснить, почему в некоторых сборках отображаются правильные связанные элементы из PR, а в некоторых все изменения отображаются как связанные элементы?
Согласно документу Настроить конвейеры для поддержки отслеживания работы
Какие рабочие элементы включены в автоматическое связывание?
При разработке программного обеспечения вы можете связывать рабочие элементы при создании ветки, фиксации или запроса на извлечение. Или вы можете инициировать ветку, фиксацию или запрос на извлечение из рабочего элемента, автоматически связывая эти объекты, как описано в разделе Управление разработкой Git из рабочего элемента.
При автоматическом связывании рабочих элементов со сборками производятся следующие вычисления:
- Для первой сборки:
- Определите все рабочие элементы, связанные с веткой, коммитами и запросами на включение, связанными со сборкой.
- Для последующих сборок:
- Определите все рабочие элементы, связанные с текущей создаваемой фиксацией (C1).
- Определите все рабочие элементы, связанные с фиксацией (C2) последней успешной сборки той же исходной ветки.
- Определите все рабочие элементы, связанные с фиксациями между C1 и C2 в дереве фиксации.
Если в конвейере включена функция Автоматически связывать рабочие элементы со сборками или выпусками, он будет генерировать дополнительные ссылки на соответствующие рабочие элементы с типом ссылки Integrated in build или Integrated in release stage. Включение этой опции не влияет на связанные рабочие элементы сборки, которые можно увидеть на странице сводки сборки.
- Есть ли у кого-нибудь идеи о том, как я могу получить идентификатор PR программно из самой сборки?
Если сборка вашего конвейера была инициирована PR ($(Build.Reason) было PullRequest), вы можете получить идентификатор PR, ссылающийся на предопределенную переменную со значением $(System.PullRequest.PullRequestId).
Привет! Я обновил ответ, что опция Automatically link work items не влияет на связанные рабочие элементы сборки; он просто генерирует дополнительные ссылки на рабочие элементы. По второму вопросу, могу ли я узнать, почему сборка имела какое-то отношение к PR, когда вместо Build.Reason было IndividualCI или Manual и т. д.?
Привет, он запускается как индивидуальный ci, а не вручную. Ручной запуск не имеет отношения к этой проблеме. Это работает так: оно запускается при обновлении ветки разработки. Эта ветка обновляется только PR-специалистами, а политика ветки запрещает прямые коммиты в ветку. Итак, как только PR объединен, запускается конвейер. В результате все сборки запускаются успешными PR-слияниями.
Согласно документации Microsoft, триггеры YAML PR поддерживаются только в GitHub и Bitbucket Cloud. Если вы используете Azure Repos Git, вы можете настроить политику ветвей для проверки сборки, чтобы запустить конвейер сборки для проверки. Таким образом, PR-триггер в данном случае неприменим. - В этом случае триггер PR не применяется. Это не конвейер проверки PR.
Итак, у вас была сборка, инициированная IndividualCI, которая представляла собой коммит слияния из PR, и вы ожидали получить идентификатор PR во время этой сборки, верно?
Нет, я ожидаю увидеть правильные связанные элементы и правильные изменения в сборке. Не все изменения и рабочие элементы с начала проекта. Конечно, было бы неплохо получить идентификатор PR, но я не думаю, что это реалистично, если я не собираюсь читать имя коммита и получать оттуда идентификатор PR. Или, может быть, есть другой способ?
Я добавил скриншот
Скриншот оказался гораздо более полезным для понимания вашего вопроса. Пожалуйста, проверьте обновленный ответ.
Автоматическое связывание рабочих элементов не включено для конвейера. И у конвейера есть триггер ветвления. Это не пиар-триггер.