Чистые сборки в непрерывной интеграции

Question

Мы используем стек CruiseControl.Net/NAnt/Subversion для CI. Создание новой проверки для каждой сборки занимает слишком много времени, поэтому в настоящее время мы просто делаем обновление для рабочей копии. Однако это оставляет возможность того, что потерянные файлы могут остаться в рабочей копии после удаления в системе контроля версий. Мы попытались использовать задачу удаления NAnt, чтобы удалить все исходные файлы кода перед обновлением, но это может повредить рабочую копию. Кто-нибудь знает быстрый способ запустить сборку на чистой и современной рабочей копии? РЕДАКТИРОВАТЬ: Мы на SVN 1.3.2

Answer 1

Если вы просто «обновите», SVN удалит все файлы, которые были удалены в системе контроля версий. Однако файлы, созданные во время процесса сборки, могут все еще быть там и могут мешать новой сборке. Я не уверен, есть ли у SVN команда для их удаления, но я думаю, что вы могли бы сделать это с помощью небольшого сценария, SVN определенно может сказать вам, какие файлы находятся под контролем исходного кода, а какие нет.

Answer 2

У нас была похожая проблема с нашей реализацией CC.

Наше решение ... Мы уже создали ночную сборку в 3 часа ночи, которая выполняла более длительные интеграционные тесты в дополнение к тестам базовых модулей. Мы просто решили сделать в 3:00 полностью чистую сборку на свежем дереве. Так как это была середина ночи, это редко затрагивало кого-либо. Все остальные «обычные» проверки выполнялись инкрементными сборками.

Answer 3

Вы можете делать ежедневную полную сборку и оставить сборку при регистрации как есть. Кроме того, для сборок развертывания рекомендуется всегда использовать чистую полную сборку.

Answer 4

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

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

Answer 5

Если в вашей рабочей копии остались потерянные файлы после обновления svn, значит, в вашей версии Subversion есть ошибка.