timja
commented
10 years ago +1
attempting to manage the state of the Jenkins internal configuration without using the Jenkins webUI is hopeless. breaking out application/user data would be a nice start. I would also love to see a `conf.d` style configuration loading process. if there was a system configuration API with GET/SET operations, a Puppet module could be created to inspect and enforce the Jenkins configuration, notably enabling/configuring security, email settings and users/permissions.
Jenkins has only one top level folder containing everything. Many third-party web applications have a top level distinction between application/configuration and user data. Take for example Sonatype Nexus. It has two main folders - "nexus-x.x.x" and "nexus_data".
More specifically, within Jenkins the file config.xml contains items that could be considered user data (most notably view definitions) as well as application-level configuration (pretty much everything else). This becomes problematic when attempting to manage a Jenkins instance programmatically (e.g. via Puppet). User changes must be added upstream before applying a configuration update.
Originally reported by nweiler, imported from: Separate Application/Configuration and User Data