I have a large number (dozens) of nearly identical Jenkins jobs. Instead of managing them in the Jenkins UI, I would prefer to manage them from source control. I was thinking of dynamically generating either config patches, or else the entire config, and pushing these dynamically using the Jenkins CLI client.
As an alternative, I thought about using parametrized builds, but I'm not sure how to do it in this case. Each job listens for changes to a job-specific SCM repo and then runs a sync job in response. Is there a way to use a single parametrized job in this sort of context?
As far as generating jobs, the challenge I'm running into here is that any given job configuration looks to be a combination of global and job-specific configuration. I want to manage job-specific config in source control but want automatically use whatever global config is in place.
Patching helps, but I still run into the same problem: the patches may include bits that are really part of the global config. As a concrete example, I want to push HipChat plugin configuration, but the Jenkins job doesn't yet have the plugin activated. Then to activate it, I'd have to create the /project/publishers/jenkins.plugins.hipchat.HipChatNotifier element, which has a globally-defined version attribute. In this case I could look up the version from another CLI call, but my point is that I'd like to avoid managing that kind of global config if possible.
This is all doable stuff, but is managing job configs from source control already a solved problem?
I saw this question but it's not the same. I don't want to flush Jenkins configs to source control; I want to manage the local stuff in source control and push it to Jenkins.
