Architecture and design

The Operator Service for Jenkins design incorporates the following concepts:

• watching any changes to manifests and maintaining the desired state according to the deployed custom resource manifests
• implementing multiple reconciliation loops that ensure the state of particular resources matches the desired state defined in the manifests.

The Operator Service for Jenkins supports the following manifests:

• Jenkins

  • allows you to control options specific to the Jenkins Controller (Jenkins Master) as well as Kubernetes-specific options such as Roles or PodSpec,
  • it uses an InitContainer to ensure initial configuration,
  • it provides a mechanism for caching plugins, so when the pod restarts, it won’t have to download them again,
  • it uses a Persistent Volume for Jenkins home to preserve build history and artifacts. But, because Operator Service for Jenkins® is built upon the idea of an immutable state, the Jenkins state is being cleared on restart.

• JenkinsKubernetesAgent

  • allows you to control options specific to the Jenkins Agents as well as Kubernetes-specific options such as Roles or PodSpec,
  • allows you to define agents using custom images,
  • a seedJob agent is required when using JenkinsSeedJobs, if it isn’t present, one will be created by the operator.

• JenkinsSeedJob

  • uses Jenkins Job DSL plugin,
  • it is a recommended way to define your jobs,
  • jobs defined as JenkinsSeedJobs will be recreated on Jenkins restart.

• JenkinsConfigurationAsCode

  • uses Jenkins Configuration as Code plugin,
  • allows you to control the Jenkins' state directly. This will be re-applied when Jenkins restarts.

• JenkinsGroovyScript

  • allows you to control the Jenkins' state directly. This will be re-applied on Jenkins restart,
  • if your scripts need to be executed in a particular order, you can use the DependsOn field in Custom Resource,
  • JenkinsGroovyscripts are executed after JenkinsConfigurationAsCode.