Feature Request: Support config as code options in the crd

[tuxhamb]

Thanks for working on the jenkins operator... I'd like the option to put configuration as code in the jenkins custom resource, instead of having to create a file in a configmap first:

apiVersion: jenkins.io/v1alpha1
kind: Jenkins
metadata:
  name: example
spec:
  master:
   image: jenkins/jenkins
  config:
    jenkins:
      systemMessage: "Hello world"

I think this follows the philosophy of operator a bit closer and does not need to be mutually exclusive with existing approach.

[pawelprazak]

yes, the CaC is either CasC plugin yaml configs or Groovy scripts, so they are basically files embedded in a yaml, so according with k8s best practices, that's what ConfigMap is for

to go a step further with the operator way, it would require to create two types e.g. GroovyScript and ConfigurationAsCode to then could be either embedded or referenced in the Jenkins type

the problem with that is would not provide useful schema anyway and would require a lot of work for not much gain

please remember that we don't have a lot of resources, so we need to be laser focused on what we implement and what we left out to have a lean codebase

today you can have a single file with just basic yaml, not sure how a custom type would be better

a multi-document yaml is created by separating the document with --- in a single file, e.g.:

---
kind: Jenkins
apiVersion: jenkins.io/v1alpha1
metadata:
  name: infrastructure
  namespace: jenkins
spec:
  ...

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-operator-user-configuration-infrastructure
  namespace: jenkins
  labels:
    app: jenkins-operator
    jenkins-cr: infrastructure
    watch: "true"
data:
  ...

[pawelprazak]

as for configuration improvements, I would personally see a list of references to config maps in the Jenkins type to avoid confusion as to how the files are connected and to label them automatically, with the default being:

configurations:
- kind: ConfigMap
  apiGroup: v1
  name: jenkins-operator-user-configuration-infrastructure
- kind: Secret
  apiGroup: v1
  name: jenkins-operator-user-configuration-infrastructure

@tomaszsek if I'm not mistaken this should remove the requirement for "magic labels":

  labels:
    app: jenkins-operator
    jenkins-cr: infrastructure
    watch: "true"

[tomaszsek]

The best option is to add explicit source to CR:

kind: Jenkins
apiVersion: jenkins.io/v1alpha1
metadata:
  name: infrastructure
  namespace: jenkins
spec:
  configurationAsCode:
    secret: 
      name: blah
    configurations:
    - name: jenkins-operator-user-configuration-casc-infrastructure
  groovyScripts:
    secret:
      name: blah
    configurations:
    - name: jenkins-operator-user-configuration-groovy-infrastructure

But this requires new approach in how run groovy scripts in Jenkins. We want to get rid of configuration jobs and apply groovy code via Jenkins API.

[tomaszsek]

Added in https://github.com/jenkinsci/kubernetes-operator/releases/tag/v0.2.0