Тег SVN "Ночные" строит с CruiseControl.Net - PullRequest
Новая
       24

Тег SVN "Ночные" строит с CruiseControl.Net

4 голосов
/ 05 марта 2010

Как бы я сделал ночную или другую запланированную сборку для CruiseControl.NET без дублированного проекта?

В моей текущей конфигурации каждые 60 секунд я проверяю транк с помощью Subversion, запускаю MSBuild, затем либо NUnit, либо MSTest.

Я хотел бы зафиксировать в SVN в качестве тега, но я не хочу его делать при каждой успешной сборке. Я хочу, чтобы он делал ночные сборки или какое-то другое расписание. Мне кажется несколько утомительным иметь два проекта CruiseControl.Net с одинаковыми опциями. Как лучше всего справиться с этим?

В качестве бонуса, я бы хотел, чтобы он создавался как сборка релиза и фиксировал бинарные файлы в одном теге.

Ответы [ 2 ]

2 голосов
/ 16 марта 2010

Единственный способ, который я нашел до сих пор, - это создать еще один проект в файле ccnet.config, который основан на выводе первого ... вот что я имею в виду.

Первый проект создается какнормально, когда разработчик регистрирует какой-либо код.

Второй проект запускается только после определенного времени (например, 11 вечера) и запускается, только если первый проект показывает успешную сборку.

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

Вот что я сделал для этого: В моем файле ccnet.config мой второй проект имеет следующие настройки: 

<triggers>  
        <multiTrigger operator="And"> 
            <triggers> 
                <projectTrigger project="NameOfProject1" /> 
                <scheduleTrigger time="23:00" buildCondition="ForceBuild">
                    <weekDays>
                        <weekDay>Monday</weekDay>
                        <weekDay>Tuesday</weekDay>
                        <weekDay>Wednesday</weekDay>
                        <weekDay>Thursday</weekDay>
                        <weekDay>Friday</weekDay>
                        <weekDay>Saturday</weekDay>
                    </weekDays>
                </scheduleTrigger>
            </triggers> 
        </multiTrigger>
    </triggers>

Кроме того, мой раздел управления исходным кодом имеет следующее: 

<sourcecontrol type="multi">
<sourceControls>   
    <svn>
        <trunkUrl>http://<my-svn-url>:81/svn/<my-project-name>/branches/1.13</trunkUrl>
        <workingDirectory>c:\ccnet\<my-system-name>\<my-project-name></workingDirectory>
        <cleanCopy>false</cleanCopy>
    </svn>

... ...

При этом для свойства устанавливается значение false, чтобы проект не удалял код, а использовал то, что уже есть.

Затем в своей задаче чуть дальше я передаю флаг NAnt, чтобы сказать ему, что нужно запускать только тесты пользовательского интерфейса для моих проектов, так как первый проект в файле ccnet.config уже запущенпроцесс сборки, но затем игнорирует тесты пользовательского интерфейса.

Помогает ли это вообще?Я могу расширяться дальше, если вы хотите идти в этом направлении.

0 голосов
/ 05 марта 2010

У меня нет решения вашей проблемы с дублирующимися ccnet-проектами. но я расскажу вам, как мы используем ccnet (и мы очень довольны этим).

у нас есть 20 проектов на сервере сборки и несколько веток релизов предыдущих версий. мы только начинаем сборку по требованию, используя приложение cctray. поэтому после того, как разработчик завершил реализацию функции, он нажимает кнопку «принудительная сборка», и ccnet начинает делать свое дело (сборка, тестирование, тегирование, копирование результатов сборки на сетевой диск, уведомление других разработчиков, ...).

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

Одна идея, которая приходит на ум при запуске ночных сборок, - это использовать интерфейс удаленного взаимодействия ccnet (который также используется cctray), подключить его к экземпляру ccnet и вызвать метод force-build-метод в полночь.

относительно "назначения двоичных файлов одному и тому же тегу":

В ccnet существует проблема, из-за которой он иногда помечает ревизию из ствола, а иногда - рабочую копию. он делает это в зависимости от того, были ли изменения со времени последней сборки (в этом случае он помечает ревизию из ствола), или если не было изменений со времени последней сборки (в этом случае он помечает рабочую копию).

это довольно раздражает, потому что вы никогда не знаете, что будет зафиксировано - в первом случае ваши двоичные файлы не будут зафиксированы, во втором случае они будут.

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

...