Community
Participate
Working Groups
Currently we chuck everything that Hudson uses to manage itself into a single home directory ~/.hudson or destination defined by $HUDSON_HOME. Thus a backup strategy for the configuration data either has to include a lot of stuff that is not really necessary, or has to scrape out the specific files relating solely to the configuration (like the ThinBackup plugin does) From an architectural point of view it would be better to allow configuration and data to be physically separated, although we could maintain the current behavior as the default. Note we'd have to look at the possible negative effects on something like ThinBackup but I would assume that it would be unaffected as long as HUDSON_HOME remains as the configuration base and we introduce a secondary location and environment variable (e.g. HUDSON_DATA)
This aligns well with the Enterprise mission for Hudson so it's well worth lookign into.
I think this RFE really make sense, I was thinking similar to this some thing like ${HUDSOn_HOME}/ _ /3.x/ | /platform-confs | /job-confs | Configuration Part /4.x/ | /platform-confs | /job-confs _| _ /builds/ | workspace/ | Data part _| The configuration files will be versioned and we provide some kind of upgrade utility to upgrade from previous version. This helps easily to move from one version to other. As you mentioned the data part could be kept else where using env variable HUDSON_DATA.
as discussed on the conf call, a few extra items needs to be considered * It should be easy for plugin developers to get a reference to either hudson_home or hudson_data preferable without resorting to environment variables. * This only solves versioning when the user upgrades the main hudson, but it might be beneficial to version the individual files? * Where do archived artifacts go ? should they be a 3. place so we have config, work area and archive ?
Ref: http://issues.hudson-ci.org/browse/HUDSON-8712 The configuration files and the workspace files should not be mixed in the same directory structure. At the moment it's unnecessary difficult to archive the configuration files (in Subversion) because they are mixed with the workspace. It would be nice if hudson could split up it's data in Configuration data. This would include all XML files, hudson and project configuration. Program files. This would contain the WAR file, the exploded WAR file and the plugins. User data. This would contain the workspace and builds and project specific data and log files. Such a setup would make it easier to backup and maintain a hudson installation. And then it would be even better if the workspaces could be balanced between a few mount points for performance reason. Like you could feed Hudson /workspace1 /workspace2 /workspace3 which are all individual disks and Hudson would split the projects between these three disks.
