Jan, "Allow to show difference before commit to SCM or update from SCM"
- doesn't this allso sets dependecy on this pul request? See this link: http://jenkins.361315.n4.nabble.com/Pre-SCM-poll-extension-td4631662.html 2012/7/6 Jan Ruzicka <jan.ruzi...@comtechmobile.com> > Hi > > have you looked at SCM Sync configuration plugin[1]? > > It may be a worth to have the JobConfigHistory+Plugin and SCM Sync > cooperate. > Job Config history showing differences in the SCM captured configs. > Allow to show difference before commit to SCM or update from SCM. > > Jan > > [1] > https://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin > Jan > On Jul 6, 2012, at 9:56 AM, Michaël Pailloncy wrote: > > > 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 <jgl...@cloudbees.com> > > 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'. > > > > Jan Ruzicka > Senior Software Engineer > Comtech Mobile Datacom Corporation > 20430 Century Blvd, Germantown, MD 20874 > Office: 240-686-3300 > Fax: 240-686-3301 > > The information contained in this message may be privileged and/or > confidential. If you are not the intended recipient, or responsible for > delivering this message to the intended recipient, any review, forwarding, > dissemination, distribution or copying of this communication or any > attachment(s) is strictly prohibited. If you have received this message in > error, please so notify the sender immediately, and delete it and all > attachments from your computer and network. > > -- A.C. Linards L.
