Какую часть HUDSON_HOME следует поставить под контроль источника?

Я хотел бы управлять конфигурационными файлами Хадсона с подрывной копией для резервного копирования. Hudson Wiki перечисляет структуру каталогов $HUDSON_HOME так:

HUDSON_HOME
 +- config.xml     (hudson root configuration)
 +- *.xml          (other site-wide configuration files)
 +- fingerprints   (stores fingerprint records)
 +- plugins        (stores plugins)
 +- jobs
     +- [JOBNAME]      (sub directory for each job)
         +- config.xml     (job configuration file)
         +- workspace      (working directory for the version control system)
         +- latest         (symbolic link to the last successful build)
         +- builds
             +- [BUILD_ID]     (for each build)
                 +- build.xml      (build result summary)
                 +- log            (log file)
                 +- changelog.xml  (change log)

Очевидно, что задания/[JOBNAME]/сборки не должны входить в исходный элемент управления, но config.xml является хорошим кандидатом. Плагины и отпечатки пальцев менее очевидны.

Как вы управляете конфигурациями Хадсона?

Ответы

Ответ 1

Я использую SCM для управления моей конфигурацией Хадсона. Я сохраняю файл config.xml верхнего уровня и файл config.xml для каждого задания. У меня есть немного script, которые я использую для получения конфигураций из Hudson и фиксации/добавления/удаления их по мере необходимости (наряду с некоторыми другими колокольчиками и свистами, облегчающими управление конфигурацией).

Re Rob Hruska указывает, для моей конкретной установки:

  • Конфигурации
  • часто меняются (уведомления, особенно)
  • (см. выше re a script, чтобы сделать обновления)
  • Я все время разбираюсь. У нас есть несколько администраторов, которые могут обновлять конфигурацию, и эти различия полезны.

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

Ответ 2

SCM, вероятно, не лучший инструмент для резервного копирования рабочего пространства Hudson - это будет похоже на использование Subversion для хранения предпочтений для игры или содержимого таблиц базы данных для веб-приложения. Наряду с этим, это не кажется необходимым по следующим причинам:

  • Файлы конфигурации не изменяются (или не должны) часто (например, код), поэтому достаточно ночных резервных копий.
  • Когда вы вносите изменения через графический интерфейс, что-то придется выходить в систему и делать svn commit. Так как это, вероятно, будет ручной шаг, он оставляет место для человеческой ошибки.
  • Вам, вероятно, никогда не понадобится изменять ваши изменения конфигурации и, если возможно, вы можете просто извлечь и посмотреть соответствующие резервные копии (см. ниже).

В целом, для этой задачи было бы просто непросто использовать Subversion. Для резервного копирования я бы рекомендовал просто настроить работу cron, которая выполняет tar cvzf $HUDSON_HOME. Вы можете опционально опустить каталоги сборки, но это кажется немного ненужным, если у вас достаточно свободного места на диске.

Изменить: Что касается различий между этим и oeuftete answer, мой ответ - это просто из моего опыта использования Хадсона. Его/ее ответ определенно дает другую перспективу, что приятно. Я определенно согласен с этим в том, что каждая ситуация различна и может потребовать разные средства для достижения цели.

Ответ 3

Я нашел хорошую кулинарную книгу для настройки резервной копии SVN для Hudson: http://javaadventure.blogspot.com/2010/07/keeping-hudson-configuration-and-data.html

Я адаптировал его для своих собственных нужд, но все, что вам нужно сделать для резервного копирования из домашнего каталога Hudson:

  • config.xml для каждого задания (jobs/*/config.xml)
  • все в каталоге пользователей
  • список плагинов, которые вы установили

У ссылки также есть дополнительная поддержка SVN, например удаление несуществующих конфигураций заданий и т.д.