Автоматизация сборок от тегов подверсии
Вы были близки, однако пара вещей пошла наперекосяк. Во-первых, DOM оценивается по порядку, поэтому обработчик onclick не знал о вашей функции, так как она была объявлена после элемента; это вызвало Uncaught ReferenceError: copyPassage не определено .
Далее, неправильный метод был использован для фактического выбора текста. Вы использовали .select(), что вызвало Uncaught TypeError: copyText.select не является функцией .
Вместо этого вы должны использовать selectAllChildren MDN sup> .
Смотрите это в действии здесь:
Harry Potter
7 ответов
Мне нравится hudson - легко настраивается и работает с SVN из коробки.
Вы можете настроить его на сборку при каждом коммите.
Я скачал его и начал собирать с ним в течение одного дня. Он прошел через множество доработок, но я бы рекомендовал его всем.
Я также использовал cruise control, но он мне не очень нравится. У меня нет никаких конкретных причин, кроме проблемы кроссплатформенности.
EDIT
Недавно я добавил задание на мой сервер hudson build, который слушает джаббер-чат google/gmail. С помощью этого механизма я могу "продвигать" "обычную" сборку в релизную. Я только что создал новую работу, которая выполняет шаги, необходимые для продвижения/публикации обычной сборки в релиз-кандидат.
CruiseControl. Сеть может легко автоматизировать автоматические сборки из репозиториев подверсии.
Это может контролировать репозиторий (Svn и несколько других типов) и запустить автоматические сборки с помощью множества инструментов. (NAnt, MSBuild, и т.д.)
Кажется, что Вы после непрерывного механизма сборки интеграции что-то как CruiseControl или Гудзон (Гудзон записал в Java, но ОЧЕНЬ прост в использовании в окнах).
Теперь Вы могли уклониться от своих сценариев сборки для этих инструментов для наблюдения каталога тегов, но это будет немного против мелкой частицы, поскольку они предназначаются, чтобы наблюдать определенное местоположение и разработать проект в том местоположении. Если бы Вы смотрите целый каталог тегов, Вы могли бы легко закончить со всеми тегами, был бы проверен на машину сборки, и Вам будет нужен высокоуровневый сценарий для решения который тег создать.
Поскольку, что Вы хотите, механизм сборки может смотреть, определенное местоположение (скажите что '/branches/release'). Если Вы затем объединитесь в то ответвление, то Гудзон автоматически разработает проект, заархивирует артефакты и создаст тег для Вас, если это было все успешно (см., что Подверсия Отмечает Плагин).
Мне не нравится делать этот вид вещи от рычага постфиксации, потому что это заставляет фазу фиксации занять слишком много времени. Однако TeamCity является системой управления исходным кодом, которая имеет функцию, которая делает точно, что, не держа Вас, пока он фиксирует.
Я рекомендовал бы Гудзон для этого.
Коммерческий продукт рекламировался на этом сайте для точно этой цели!
http://www.finalbuilder.com/Default.aspx?tabid=314
Вы, возможно, должны добавить, что пострычаг к SVN для инициирования сборки запускается, если Вы не хотите, чтобы это было выполнено расписание.
Я использую NAnt (и NAntContrib) для автоматизированных сборок. Это автоматически проверяет репозиторий подверсии на изменения и (если существует кто-либо), получает последнюю версию исходного кода и запускает сборку.
Я не уверен, позволяют ли существующие задачи делать точно, что Вы хотите, но возможно Вы могли использовать его в качестве запуска и при необходимости, расширить его с помощью задач для Ваших особых потребностей (Это разрабатывается с.NET).
Как говорили другие ребята, вам нужен сервер непрерывной интеграции (CruiseControl, CruiseControl.Net, Hudson и т. Д.). Хотя вы можете поработать над сценарием сборки и обработчиками фиксации для выполнения описанных вами функций, в конце концов вы обнаружите, что заново изобрели колесо (сервер непрерывной интеграции). В этом нет необходимости, есть бесплатные решения для этой цели.
Процесс будет работать несколько иначе, чем вы описали выше. Сервер сборки:
- Обнаруживает новую фиксацию
- Проверяет исходный код
- Запускает ваш сценарий сборки
- Тег при успешной сборке
Фиксация запускает процесс и создает тег, а не запуск тега процесс. Сервер делает это моим мониторингом репозитория svn, а не фиксацией.
Ознакомьтесь с документацией CruiseControl.Net по этому вопросу, особенно с параметрами tagOnSuccess и tagBaseUrl. Hudson и CruiseControl должны иметь аналогичные параметры.
http://confluence.public.aughtworks.org/display/CCNET/Subversion+Source+Control+Block
Я сделал это с помощью Hudson. В обычном слоте subversion checkout у меня есть checkout для ствола:
http://dryad.googlecode.com/svn/trunk/dryad
Затем в качестве первого действия сборки у меня есть "execute shell" и в этой оболочке я использую svn switch для изменения на последний тег в репозитории:
svn switch http://dryad. googlecode.com/svn/tags/'svn ls http://dryad.googlecode.com/svn/tags | tail -n 1' dryad
Следующий шаг сборки - команда maven 'clean install', которая запускает сборку, используя код из версии с метками.
Я пока не придумал, как заставить Hudson начинать сборку с последней помеченной версии вместо того, чтобы делать переключение, но переключение работает. Вы можете сделать так, чтобы триггер срабатывал при обновлении каталога тегов.
Это автоматизировано... немного сложно, но работает...
переключатель должен включать обратный знак для второй команды svn, но пришлось использовать ', потому что обратный знак здесь не отображается.