Not familiar with "Jobs SCM" and unclear as to what you are trying to do - or how Redis or Docker fits it here. If you have some idea, you are welcome to write a plugin and make it work however you want, which is why the plugin system exists - and answers your question as to why this is done with plugin. But onestly, it sounds like you are making it far more complicated than it needs to be. Generally the setup would be a single, static Jenkins Master server that manages job scheduling and coordination and a number of "slave" nodes" that execute the job. Ideally slave nodes would be pristine and disposable and not have any code/tools installed on them - with master managing any code/tools requires - meaning they do not ever need to be versioned on the slave.
Modern way of managing your jobs is via Pipelines. You just store your jobs along with your code (I assume your code is in some sort of a SCM to begin with) and for shared libraries use global library repo(s). Jenkins does not really have a lot of configuration on Jenkins Master side after this, the only thing you really need here is a decent backup strategy - but if you are really interested in tracking individual job changes, there is a "Job Configuration History" plugin that will track each change and who did it, but with most of the job coming with source code, it is not all that critical/necessary. HTH, -M On Monday, November 7, 2016 at 4:45:57 AM UTC-8, Rinaldo DiGiorgio wrote: > > Hi, > > I tried to version my jobs with the Jobs SCM plugin for example and it > often gets confused and ends up making my system unusable. Perhaps an > entire rewrite is needed and the backend store needs to move to something > like redis. I don't think version control should be done with optional > plugins. It should be part of the core system and all configuration data > should be in a network store. > > I can see a solution using docker where one makes a base image. What > happens when you change the configuration however. Do you make a new docker > base image? Some organizations want all the source code to generate an > image in some type of SCM and this is the issue. If you change job > configurations or config params you just incurred the hit of a new image > generation cycle. Perhaps I am not looking it in the right way or in the > future when everything is pipeline the configuration is pipeline with > supporting json and property files. > > Rinald > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9547956d-bf32-4827-ab38-bbaf41b971f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
