Какую часть HUDSON_HOME я должен поставить под контроль исходного кода? - PullRequest
10 голосов
/ 22 октября 2009

Я бы хотел управлять файлами конфигурации Hudson с помощью Subversion для резервного копирования. 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)

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

Как вы управляете своими настройками Hudson?

Ответы [ 3 ]

7 голосов
/ 22 октября 2009

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

Очки Роба Хруски, для моей конкретной настройки:

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

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

7 голосов
/ 22 октября 2009

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

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

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

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

2 голосов
/ 08 декабря 2010

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

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

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

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

...