Azure DevOps - политики веток приводят к запуску нескольких сборок во время запросов на извлечение

Невозможно выполнить то, что вы хотите, с помощью триггеров или политик сборки. Когда есть изменения в папке X, нет опции Не строить. Есть несколько вариантов, но они требуют небольшого переосмысления:

Вариант 1. Используйте вакансии и условия

• Создайте единый конвейер со стадией сборки и 4 заданиями.
• Первое задание использует инструмент командной строки, чтобы определить, какие проекты необходимо перестроить, и устанавливает выходную переменную.
• Остальные 3 задания зависят от первого задания, и для них установлено условие, которое запускается только тогда, когда переменная (заданная в первом задании) имеет определенное значение.

Таким образом, вы можете полностью контролировать порядок сборки всех трех проектов.

Вариант 2. Используйте конвейер оркестровки

• На торговой площадке есть расширения для запуска следующей сборки и ожидания за результат.
• Выполните расчет, аналогичный варианту 1, и запустите соответствующую сборку, ожидая ее результата.

Вариант 3. Использование артефактов конвейера

Вместо построения A + B + C в сборке C загрузите результаты из A + B, затем выполните сборку C. Это потребует загрузки артефактов конвейера в конце каждого задания и для каждого последующего задания выполнять инкрементную сборку путем загрузки этих артефактов. и тем самым пропуская процесс сборки.

Вы даже можете загрузить последние успешные результаты, если хотите пропустить сборку кода.

Вариант 4: используйте NuGet

Вместо артефактов конвейера используйте пакеты nuget для публикации выходных данных из сборки A и использования их в сборке B. Или даже опубликуйте A в задании A и используйте его из задания B в том же определении сборки.

Вариант 5. Положитесь на инкрементные сборки

Если вы работаете с агентом, размещенным на собственном хостинге, вы можете отключить параметр« Очистить »для своего конвейера, позаботившись о том, чтобы тот же агент создавал вашу сборку раньше, если будет просто повторно использовать сборку вывод предыдущего запуска, если ни один из входных файлов не изменился (и вы не сделали никаких неправильных настроек msbuild). Будет по существу пропустите построение A, если msbuild может вычислить, что ему не нужно строить A.

Преимущество одной сборки с несколькими заданиями заключается в том, что вы можете указать порядок заданий A, B, C и контролировать, что происходит в каждом задании. Большой недостаток заключается в том, что каждое задание добавляет накладные расходы на выборку источников или загрузку артефактов. Вы можете немного оптимизировать это, четко установив подстановочные знаки для тех частей, которые вы хотите публиковать и восстанавливать.

Если вам не нужны исходные коды на последующих этапах (и вы не используете конвейеры YAML), вы можете использовать мой Не синхронизировать источники (даже с Git), чтобы пропустить этап синхронизации, позволяя вам точно контролировать, что происходит в каждом задании.

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

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