我应该将HUDSON_HOME的哪一部分置于源代码管理之下?

ent*_*nto 10 version-control continuous-integration hudson

我想用subversion管理Hudson的配置文件进行备份. 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)
Run Code Online (Sandbox Code Playgroud)

显然,job/[JOBNAME]/builds不应该进入源代码控制,但config.xml是一个很好的候选者.插件和指纹不太明显.

你如何管理你的Hudson配置?

Rob*_*ska 7

SCM可能不是备份Hudson工作区的最佳工具 - 就像使用Subversion存储游戏的首选项或Web应用程序的数据库表的内容一样.除此之外,由于以下原因,似乎没有必要:

  • 配置文件不会(或不应该)频繁更改(如代码),因此每晚备份就足够了.
  • 当您通过GUI进行更改时,某些东西必须转到系统并执行操作svn commit.由于这可能是一个手动步骤,因此为人为错误留下了空间.
  • 您可能永远不需要对配置更改进行区分,并且尽可能不用,您可以只提取并查看相应的备份(参见下文).

总而言之,将Subversion用于此任务似乎有点笨拙.对于备份,我建议只设置一个执行a的cron作业tar cvzf $HUDSON_HOME.您可以选择省略构建目录,但如果您有足够的磁盘空间,这似乎有点不必要.

编辑: 关于这个和oeuftete的答案之间的区别,我的回答只是根据我使用Hudson的经验.他/她的回答肯定提供了一个不同的视角,这很好.我绝对同意这一点,因为每种情况都不同,并且可能需要不同的方法来满足目的.


oeu*_*ete 7

我使用SCM来管理我的Hudson配置.我保留每个作业的顶级config.xml和config.xml.我有一个小脚本,我用来从Hudson获取配置并根据需要提交/添加/删除它们(以及其他一些使得管理配置更容易的花里胡哨).

Re Rob Hruska的观点,对于我的特殊设置:

  • 配置确实经常更改(特别是通知)
  • (参见上面的一个脚本来进行更新)
  • 我总是把事情弄得一团糟.我们有多个管理员可以更新配置,这些差异很有用

总而言之,每种情况都不同.我为配置所做的管理没有(也没有)免费提供.每晚拉上一切的cron工作肯定更便宜,也可能就足够了.