You are absolutely right, if I would like to just merge jobs configuration, this would be probably the best solution.
But jobs configurations in production and pre-production environment have many differences. For exemple, I have disabled triggers, emails notifications and initialize the number of days of keeping builds to 1 (with a Groovy scripts). Furthermore, it will surely happen that jobs configuration are changed intentionally. For example, when adding a feature in pre-production before use it in production. So in all my configuration files, I've changes that I want to keep, and others I do not want. With this plugin, I would like to keep the control when importing a job and choose manually the parts of the configuration file I want to keep in the production environment. Maybe I'm wrong, but I think it will be difficult to have this flexibility with a version control system. What do you think ? 2012/7/6 Jesse Glick <[email protected]> > On 07/06/2012 04:17 AM, Michaël Pailloncy wrote: > >> I would like to compare file line by line and merge part of them [...]. >> This plugin will allow me to apply some modifications directly without >> repeating manual actions >> in the production environment [...] >> > > At the low level, this is a task best handled by version control. > Reinventing three-way merge is not a good use of your time. > > Whether done as a plugin or directly via some scripts run on the two > Jenkins masters, you would want to set up a baseline repository, e.g. using > Git, which manages */config.xml and so on for the first draft of the > staging master. Now copy that repository to the production master, make the > minimal changes needed to reflect the production environment (such as a > different "Jenkins URL"), and commit the result to a 'production' branch. > In the future, when making job or general configuration changes in the > staging master, commit those to a 'staging' branch; pull the branch over to > the production master and merge 'staging' into 'production'. >
