Триггер нескольких репозиториев Azure. Почему он срабатывает несколько раз для одной и той же фиксации?
Образец из файла yml:
pool:
name: Managed
demands:
- agent.name -equals Agent2
# Overrides the value for Build.BuildNumber, which is used to name the artifact (ZIP file) that is produced
name: '$(Date:yyyyMMdd)T$(Hours)$(Minutes)$(Seconds)'
resources:
repositories:
- repository: RepoA
type: git
ref: release/X
name: company/RepoA
trigger:
branches:
include:
- release/X
- repository: RepoB
type: git
ref: release/X
name: company/RepoB
trigger:
branches:
include:
- release/X
... <more repos and other stuff to build the app> ...
Наше приложение разделено на несколько репозиториев. Всякий раз, когда выполняется фиксация любого репозитория, конвейер должен запустить и построить приложение (с использованием всех репозиториев).
Проблема возникает, когда я работаю над функцией, где мне приходится вносить изменения в оба репозитория здесь. Технически это приводит к двум фиксациям (одному для RepoA и одному для RepoB), что означает, что этот конвейер сработает дважды. Само по себе это не так уж и плохо, поскольку мы размещаемся самостоятельно и не платим за запуск, но проблема в том, что иногда первый запуск завершается неудачно, поскольку в нем нет обновленного кода из другого репозитория. Должно быть, это какое-то внутреннее ограничение работы Azure.
Это означает, что в сценарии с фиксацией обоих репозиториев (которая выполняется одновременно) произойдет два запуска. Первый запуск завершается неудачно, затем сразу после него начнется второй запуск, который будет успешным.
Два вопроса:
- Почему это происходит?
- Как, если возможно, это исправить?
Ответы 2
Что касается вашего первого вопроса, обратитесь к этому разделу документации:
Для триггерного репозитория — фиксация, которая запустила конвейер. определяет версию извлекаемого кода. Для других репозитории, ссылка определена в YAML для этого ресурса репозитория. определяет версию по умолчанию, которая извлекается.
Другими словами, когда ваш конвейер запускается RepoA, он проверяет последний коммит из ветки release/X в RepoB. Конвейер может выйти из строя, если проверка в конвейере произойдет до того, как новый коммит будет завершен в RepoB. Однако как только второй конвейер запускается RepoB, фиксация в RepoA уже завершена, что приводит к успешному выполнению конвейера.
Что касается вашего второго вопроса, то маловероятно, что такое поведение можно исправить в Azure DevOps, поскольку система работает должным образом. Единственным потенциальным обходным решением, хотя и не самым элегантным решением, было бы включение задержки и клонирование неактивирующего репозитория в последующем сценарии.
Если эта проблема представляет собой серьезную проблему для вашего рабочего процесса, вам, возможно, придется пересмотреть и адаптировать свою стратегию в отношении ваших репозиториев.
- Почему это происходит?
Указание раздела триггера для нескольких ресурсов репозитория означает, что любое изменение этих ресурсов инициирует новый запуск. Когда вы фиксируете изменения как в RepoA, так и в RepoB, Azure Pipelines запускает сборку для каждой фиксации. Для получения более подробной информации вы можете обратиться к документу о триггерах для нескольких репозиториев.
Вы упомянули сценарий с коммитом в оба репозитория (который делается одновременно), в системе это два коммита, которые обрабатываются независимо друг за другом. Таким образом, первая сборка не содержит последних изменений из другого репозитория, что приводит к сбою.
- Как, если возможно, это исправить?
Из документа:
Это полезно, например, в следующих сценариях:
- Вы используете инструмент или библиотеку из другого репозитория. Вы хотите запускать тесты для своего приложения при каждом обновлении инструмента или библиотеки.
- Вы храните свой файл YAML в отдельном репозитории от кода приложения. Вы хотите запускать конвейер каждый раз, когда обновление отправляется в репозиторий приложения.
Эта функция предназначена для описанных выше сценариев.
В настоящее время нет возможности отключить первый запуск вашего сценария. В качестве обходного пути вы можете:
- Установите запланированный триггер для выполнения конвейера через заданные интервалы времени.
- Отключите автоматические триггеры и вручную запустите конвейер после обновлений в обоих репозиториях.
- Объедините два репозитория в один репозиторий.
Если описанный выше обходной путь не соответствует вашим потребностям, вы можете запросить эту функцию для Azure DevOps здесь, чтобы улучшить эту функцию. Инженеры обычно отдают приоритет функциям, которые срочны или имеют больше голосов.