Синхронизация проектов CruiseControl на платформах Linux и Windows с зависимостями

Question

У меня есть набор приложений для нескольких платформ, некоторые из которых работают в Linux, а некоторые в Windows. Я хочу выполнить следующую сборку:

Сервер L запускает CruiseControl с Project A, серверным приложением только для Linux. Это должно построить сначала.

Если проект А успешно строится, его нужно каким-то образом запустить ...

Project B, клиентское приложение только для Windows, работающее на сервере W, с CruiseControl.NET Project B включает некоторые модульные тесты, которые дают конечный эффект генерации некоторых данных в базе данных сервера. Проект B занимает около 10 минут, чтобы построить и выполнить тесты.

Если проект B успешно создается, сервер L, который терпеливо ждал, запускает проект C, который содержит несколько тестов, которые ищут и проверяют записи базы данных, сгенерированные проектом B.

Есть идеи, как мне это сделать? Я нашел эту ссылку , но, похоже, она нацелена на создание одной и той же базы кода на нескольких платформах без зависимостей.

Конечно, кто-то должен был сделать это в какой-то момент?

Answer 1

Наличие проекта Сборка прямолинейна. На этапе публикации запишите файл на сетевой диск.

Project B может использовать блок управления исходным кодом файловой системы для мониторинга сетевой файловой системы и инициировать сборку на основе изменений из Project A. После этого он записывает другой файл в файловую систему (другой каталог).

Project C использует систему контроля версий файловой системы для отслеживания изменений в Project B.

Все довольно просто.

Если у вас нет общей файловой системы, вы также можете использовать ftp, scp или http для перемещения файлов триггера.

Если вы предпочитаете, вы можете запустить сборку, используя веб-интерфейсы, вызываемые на этапах публикации проектов A и Project B.

---

В ответ на вопросы в комментариях вы можете получить информацию о проекте B, который потерпел неудачу (как минимум) двумя различными способами.

Можно было бы иметь проект B под CC, который служил бы прокси для удаленного проекта B. Удаленный проект B записывал файл на этапе публикации, и в этом файле указывалось, прошел он или нет. Проект proxy-B будет отслеживать этот файл, а на этапе «сборки» будет считывать файл и передавать или не выполнять работу в зависимости от содержимого. Проект C теперь просто контролирует прокси-B, используя элемент BuildStatus CC.

Другим способом решения этой проблемы является замена Проекта B в CC.net на DistributedBuilder CC, который использует JavaSpaces для распространения сборок удаленным агентам: http://confluence.public.thoughtworks.org/display/CC/Using+distrib+from+the+CruiseControl+contrib

В распределенном подходе Project B по-прежнему будет запускаться на компьютере с Windows, но DistributedBuilder будет запускать сценарий удаленно и затем возвращать результаты обратно на сервер CC.

Answer 2

Вы смешиваете CruiseControl и CruiseControl.Net? Для настройки CruiseControl.Net только используйте Project Trigger .