Azure DevOps конвейер неожиданно запускается

Question

Обновлено 26-Фев-2020

В нашем проекте у меня есть конвейер "MyPipeline", который восстанавливает пакеты NuGet, создает решения и запускает тесты.

В ветке master у меня есть политика, которая делает такие вещи, как добавление рецензентов кода, и у нее есть шаг проверки сборки, который выполняет MyPipeline. Все хорошо.

Тем не менее, я создал еще одну ветку от Мастера под названием NewBranch и синхронизировал (выдвинул) это до Azure. После внесения небольших изменений в Visual Studio, я произвел слияние с master , совершил и syn c 'd до Azure.

Я был немного удивлен, увидев " MyPipeline "выполняется. Кажется, это было вызвано, когда я перенес свои изменения в NewBranch в Azure. У меня нет политики ветки на "NewBranch". Триггер в файле YAML:

trigger:
- master

Что послужило причиной этого? Я скоро сожгу минуты моего свободного агента, если это продолжится ...

Обновление 26 февраля 2020

Согласно комментариям ниже:

История коммитов на ветке master :

1. Вт 21:10
2. Вт 19:47
3. Пн 14:46

История выполнения конвейера:

1. Ср. 9:14 "PR Automated"

Итак, ничего нового не было передано в ветку Мастер. Тем не менее, я думаю, я знаю, что вызывает это. Просто я не уверен в сроках ....

Итак, у нас есть две ветви: master и NewBranch .

Master имеет политику, которая требует двух проверяющих кода для утверждения, и для успешной сборки. Из-за этой политики разработчик не может слиться непосредственно с master - он должен сгенерировать запрос на извлечение.

Итак, разработчик A создает запрос на извлечение для слияния NewBranch до Мастер . Затем существует довольно длительный процесс проверки кода, который может потребовать несколько дополнительных коммитов на запрос извлечения «NewBranch», прежде чем он будет сочтен приемлемым.

Похоже, что происходит каждый раз, когда один из этих новых коммитов синхронизируется c При запросе на извлечение запускается сборка. Это хорошо? Может быть, может и нет. Если сборка будет запускаться только один раз, то компиляция должна произойти, когда весь код в запросе на извлечение будет одобрен, а не перед этим. Зачем запускать сборку на такой ранней стадии; ветвь master может быть обновлена ​​несколькими другими Pull-запросами до того, как это будет готово к слиянию. Однако, с неограниченными ресурсами, я думаю, что строить как можно чаще не повредит, но a) это может задерживать другие сборки (представляющие препятствие для других разработчиков) и б) это израсходует свободный лимит на время агента.

Answer 1

Подробная информация, которой вы поделитесь, очень помогает мне понять весь ваш рабочий процесс.

Хотя вы не express слишком ясно поняли, но, да, что ты угадаешь правильно Действие, с которым вы столкнулись, является ожидаемым и разработанным. Причина root в том, что вы используете branch policy и Build validation, также включенные в эту политику.

В двух словах, вы используете Триггер запроса на извлечение .

---

Пояснение :

Обратим внимание на его определение:

Триггеры запроса на извлечение (PR) заставляет сборку выполняться всякий раз, когда открывается запрос на извлечение с одной из указанных целевых ветвей, или , когда изменения передаются в такой запрос на извлечение .

На основе вашего добавленное содержание, ваши разработчики толкают изменения (новый коммит) в открывающий запрос извлечения ( Примечание: Ключевым моментом является то, что запрос вытягивания все еще будет открытие. ) Это относится к рабочей области PR trigger из-за вышеприведенного определения. Вот почему сборка срабатывает при каждом новом изменении, помещаемом в ветку NewBranch.

---

Обойти:

Я согласен с логикой c ответа @ devpro. Но его сценарий не доступен для вашего сценария. Потому что pr в YAML работают только для репозиториев GitHub и Bitbucket Cloud.

Здесь вы используете репозиторий VSTS и настроили для него политику. Таким образом, вы можете только через конфигурацию политики ветвей , чтобы избежать таких проблем с записью.

На панели проверки сборки вы устанавливаете политику сборки с Automatic, верно?

Пожалуйста, измените Automatic на Manual, также оставьте значение Policy requirement как Required.

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

---

За время задержки, которое вы заметили, вы не уверены, я думаю, это произойдет из-за конфликта.

Например, открывается запрос Pull P1, который объединяется с NewBranch до Master. Я фиксирую новое изменение C1 в NewBranch. НО, это вызывает конфликт. В настоящее время сборка не будет запущена, поскольку изменения фактически не помещаются в PR.

Примечание: Фиксация верна NewBranch. НО изменения еще не приняты PR, потому что PR обнаруживает конфликт, и вы должны сообщить PR, какие изменения вы хотите сохранить. Только изменения, вставленные в PR, могут работать с триггером PR.

Только разрешенный конфликт, изменения, может быть, я могу сказать, зафиксировать, действительно могут быть приняты и помещены в PR. Затем запускается триггерная сборка.

Это будет задержка периода времени, которую вы заметили.

Answer 2

Я думаю, что вам нужно добавить pr: none к определению конвейера, чтобы отключить автоматический запуск.

Если pr не задано, я думаю, что по умолчанию выполняется для каждого PR.

Это дало бы что-то вроде этого:

trigger:
  batch: true
  branches:
    include:
    - master
  paths:
    exclude:
    - README.md

pr: none

Answer 3

Я видел такое же поведение сегодня.

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

trigger:
  branches:
    include:
    - master

Помогает ли это? Я сам пока не могу это проверить, так как я сделал это изменение, но PullRequest еще не утвержден:)

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

trigger:
  - master

(обратите внимание на 2 пробела перед мастером)