Configuration-as-code-plugin: JCasC templating and inheritance support

[oleg-nenashev]

Currently JCasC does not support YAML templating or inclusion in any means. For example, in https://github.com/oleg-nenashev/demo-jenkins-config-as-code/blob/master/init_scripts/src/main/groovy/scripts/Docker.groovy I create multiple Docker Cloud templates for different agent types. The configuration would be huge and difficult to maintain in JCasC.

I would suggest having an engine similar to what https://github.com/probot/probot-config does using Deepmerge:

• Independent YAML files can be created for configuration snippets and templates
• External configuration files can be referenced via _extends notion at any level. Local files or other configuration providers (once implemented) can be referenced
• JCasC reads references when loading or validating configs

[vx-github]

@oleg-nenashev does your suggestion include the order in which yaml files are loaded?
I have an use case where I want to override configuration that was loaded earlier (load 000.yml 001.yml, merge config for the same plugin with 000.yml but keep values from 001.yml, much like what is doen with "shared2" in https://github.com/probot/probot-config#setup).

The use case is to have some default config available in the Jenkins docker container that can be updated (overridden) by another file or location. A Jenkins job manages the update and config check +reload.

[jetersen]

file order should already be taken into account

[bioshazard]

Found this issue while trying to determine how best to atomize my many many jobs outside of a single gigantic jenkins.yaml, is it possible or on the roadmap? (EDIT: I will be leveraging Ansible and Jinja to compile the resulting jenkins.yaml for now to get the include functionality I want)

[timja]

It’s currently supported via multiple files in a directory, there’s an open PR to allow merge strategies as well for advanced use

[tobias-ericsson]

At work we have a somewhat working solution in place for merging and templating JCasC yaml files. During summer I might get time to improve/replace that solution. Maybe focus could/should go into contributing back to JCasC? Or maybe the PR with advanced merging strategies @timja is talking about is the way to go?