У нас есть собственный агент сборки на локальном сервере.
Обычно у нас большая кодовая база, и в прошлом мы использовали этот механизм с агентами сборки TFS2013:
- Ежедневные проверки были созданы в c: \ work \ tfs \ (занимает около 5 минут)
- Каждую ночь запускался командный файл, который создавал одну и ту же сборку для этих папок, используя одни и те же источники (они уже были «последними» из сборки CI), и собирал установщики. Скопируйте файлы в сетевое расположение и отправьте электронное письмо команде с подробным описанием успешной / неудачной сборки. (Это займет около 40 минут)
Ключевым моментом здесь является то, что для ночной сборки не нужно будет получать самые свежие исходные коды, а необходимое дисковое пространство не будет сильно увеличиваться. Просто по размерам установщика.
Чтобы воспроизвести это с помощью Azure Devops, я создал два конвейера. Один конвейер, который выполнял CI с помощью задач MSBuild в классическом редакторе - отлично работает Другой конвейер в классическом редакторе, который запускает наш существующий сценарий PowerShell, запланированный на 21:00 - отлично работает
Однако, несмотря на то, что мой агент не поддерживает параллельные сборки, происходит следующее: папка конвейера CI - это c: \ work \ 1 \ Папка ночной сборки - это c: \ work \ 2 \
Это удваивает объем необходимого нам дискового пространства (с 10 до 20 ГБ). Это те же файлы кода, только построенные по-разному.
Я изо всех сил пытался найти способ сказать агенту «пожалуйста, используйте одну и ту же папку источников для всех конвейеров».
Что это за настройка, иначе нам придется платить нашему поставщику услуг за дополнительное хранилище ГБ.
Или мне нужно изменить мои классические конвейеры на Yaml и каким-то образом условно разветвить сборку, чтобы она знала, что она запланирована, и сделать что-то другое? Или, может быть, прекратить использовать конвейер для запланированной сборки и использовать планировщик задач в Windows, как раньше?
(Я пытался найти тот же вопрос - уверен, что не могу быть единственным).
