Невозможно определить, какой агент будет использоваться для какой конфигурации сборки в параллельных сборках с несколькими конфигурациями.
Мы используем мультиконфигурацию в соответствии с переменной BuildConfiguration и запускаем выпуск и отладку параллельно с Clean:false в одной из наших сборок. В очереди агентов у нас есть два агента, которые отвечают требованиям для этого конкретного определения сборки.
Проблема в том, что агенты не могут быть установлены в этой сборке.
Вот почему вы не можете с уверенностью сказать, что отладка всегда будет строиться на агенте x и выпускаться на агенте y. Если теперь, когда релиз на агенте x собран, то файлы там и не будут удалены. Если это приводит к тому, что он копирует что-то поверх него при заполнении перетаскивания, тогда "устаревшие" файлы окажутся там.
Одним из вариантов будет "Очистить: все", но мы не хотим пропустить добавочный режим.
Есть ли решение этой проблемы?
1 ответ
Нет, ваш сценарий просто не поддерживается. Вы можете обойти это, имея одну очередь / набор тегов, чтобы в основном иметь группу ОДНОГО агента, но это так.
В противном случае вы просто вне области. Задачи агентов должны быть автономными. CLean all = false, как предполагается, является чисто настройкой производительности (не нужно компилировать вещи, не измененные и т. Д.), НЕ ДОЛЖНЫ позволять ссылкам последующих заданий ссылаться как состояние, в котором агент оставил другое задание.
В некоторых сценариях я использую свой собственный файловый сервер в качестве буфера. Учитывая, что мои агенты работают локально и имеют ОЧЕНЬ высокоскоростное соединение (200 гигабит на сервер), я могу просто переместить скомпилированные результаты в буферную папку и обратно с практически нулевыми издержками (как в случае: нулевые неоплаченные накладные расходы). Это особенно помогает в работе с несколькими агентами (загрузка тестов селена для 16 агентов 16 раз - нет, спасибо).