jenkins: update to 2.568.1 LTS and chart

Change-Id: Ib6b48599a09dee669d77441c12b354240ef257b8
diff --git a/charts/jenkins/README.md b/charts/jenkins/README.md
index 4ddd1fa..b54c28b 100644
--- a/charts/jenkins/README.md
+++ b/charts/jenkins/README.md
@@ -5,7 +5,7 @@
 [![Releases downloads](https://img.shields.io/github/downloads/jenkinsci/helm-charts/total.svg)](https://github.com/jenkinsci/helm-charts/releases)
 [![Join the chat at https://app.gitter.im/#/room/#jenkins-ci:matrix.org](https://badges.gitter.im/badge.svg)](https://app.gitter.im/#/room/#jenkins-ci:matrix.org)
 
-[Jenkins](https://www.jenkins.io/) is the leading open source automation server, Jenkins provides over 1800 plugins to support building, deploying and automating any project.
+[Jenkins](https://www.jenkins.io/) is the leading open source automation server, Jenkins provides over 2000 plugins to support building, deploying and automating any project.
 
 This chart installs a Jenkins server which spawns agents on [Kubernetes](http://kubernetes.io) utilizing the [Jenkins Kubernetes plugin](https://plugins.jenkins.io/kubernetes/).
 
@@ -23,8 +23,13 @@
 ## Install Chart
 
 ```console
-# Helm 3
-$ helm install [RELEASE_NAME] jenkins/jenkins [flags]
+helm install [RELEASE_NAME] jenkins/jenkins [flags]
+```
+
+Since version `5.6.0` the chart is available as an OCI image and can be installed using:
+
+```console
+helm install [RELEASE_NAME] oci://ghcr.io/jenkinsci/helm-charts/jenkins [flags]
 ```
 
 _See [configuration](#configuration) below._
@@ -70,7 +75,7 @@
 $ helm show values jenkins/jenkins
 ```
 
-For a summary of all configurable options, see [VALUES_SUMMARY.md](https://github.com/jenkinsci/helm-charts/blob/main/charts/jenkins/VALUES_SUMMARY.md).
+For a summary of all configurable options, see [VALUES.md](https://github.com/jenkinsci/helm-charts/blob/main/charts/jenkins/VALUES.md).
 
 ### Configure Security Realm and Authorization Strategy
 
@@ -103,7 +108,7 @@
 This chart allows the user to specify plugins which should be installed. However, for production use cases one should consider to build a custom Jenkins image which has all required plugins pre-installed.
 This way you can be sure which plugins Jenkins is using when starting up and you avoid trouble in case of connectivity issues to the Jenkins update site.
 
-The [docker repository](https://github.com/jenkinsci/docker) for the Jenkins image contains [documentation](https://github.com/jenkinsci/docker#preinstalling-plugins) how to do it.
+The [Docker repository](https://github.com/jenkinsci/docker) for the Jenkins image contains [documentation](https://github.com/jenkinsci/docker#preinstalling-plugins) how to do it.
 
 Here is an example how that can be done:
 
@@ -218,12 +223,12 @@
   jenkinsAdminEmail: example@mail.com
 ```
 
-Further JCasC examples can be found [here](https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/demos).
+Further JCasC examples can be found in the [configuration-as-code repository](https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/demos).
 
 #### Breaking out large Config as Code scripts
 
-Jenkins Config as Code scripts can become quite large, and maintaining all of your scripts within one yaml file can be difficult.  The Config as Code plugin itself suggests updating the `CASC_JENKINS_CONFIG` environment variable to be a comma separated list of paths for the plugin to traverse, picking up the yaml files as needed.  
-However, under the Jenkins helm chart, this `CASC_JENKINS_CONFIG` value is maintained through the templates.  A better solution is to split your `controller.JCasC.configScripts` into separate values files, and provide each file during the helm install.
+Jenkins Config as Code scripts can become quite large, and maintaining all of your scripts within one yaml file can be difficult. The Config as Code plugin itself suggests updating the `CASC_JENKINS_CONFIG` environment variable to be a comma separated list of paths for the plugin to traverse, picking up the yaml files as needed.  
+However, under the Jenkins helm chart, this `CASC_JENKINS_CONFIG` value is maintained through the templates. A better solution is to split your `controller.JCasC.configScripts` into separate values files, and provide each file during the helm install.
 
 For example, you can have a values file (e.g values_main.yaml) that defines the values described in the `VALUES_SUMMARY.md` for your Jenkins configuration:
 
@@ -242,7 +247,7 @@
   controller:
     JCasC:
       configScripts:
-        jenkinsCasc:  |
+        jenkinsCasc: |
           jenkins:
             disableRememberMe: false
             mode: NORMAL
@@ -263,7 +268,7 @@
             ...
 ```
 
-When installing, you provide all relevant yaml files (e.g `helm install -f values_main.yaml -f values_jenkins_casc.yaml -f values_jenkins_unclassified.yaml ...`).  Instead of updating the `CASC_JENKINS_CONFIG` environment variable to include multiple paths, multiple CasC yaml files will be created in the same path `var/jenkins_home/casc_configs`.
+When installing, you provide all relevant yaml files (e.g `helm install -f values_main.yaml -f values_jenkins_casc.yaml -f values_jenkins_unclassified.yaml ...`). Instead of updating the `CASC_JENKINS_CONFIG` environment variable to include multiple paths, multiple CasC yaml files will be created in the same path `var/jenkins_home/casc_configs`.
 
 #### Config as Code With or Without Auto-Reload
 
@@ -290,27 +295,36 @@
 This plugin is **not** installed by default but may be added to `controller.additionalPlugins`.
 
 ### Change max connections to Kubernetes API
+
 When using agents with containers other than JNLP, The kubernetes plugin will communicate with those containers using the Kubernetes API. this changes the maximum concurrent connections
+
 ```yaml
 agent:
   maxRequestsPerHostStr: "32"
 ```
+
 This will change the configuration of the kubernetes "cloud" (as called by jenkins) that is created automatically as part of this helm chart.
 
 ### Change container cleanup timeout API
+
 For tasks that use very large images, this timeout can be increased to avoid early termination of the task while the Kubernetes pod is still deploying.
+
 ```yaml
 agent:
   retentionTimeout: "32"
 ```
+
 This will change the configuration of the kubernetes "cloud" (as called by jenkins) that is created automatically as part of this helm chart.
 
 ### Change seconds to wait for pod to be running
+
 This will change how long Jenkins will wait (seconds) for pod to be in running state.
+
 ```yaml
 agent:
   waitForPodSec: "32"
 ```
+
 This will change the configuration of the kubernetes "cloud" (as called by jenkins) that is created automatically as part of this helm chart.
 
 ### Mounting Volumes into Agent Pods
@@ -320,9 +334,9 @@
 ```yaml
 agent:
   volumes:
-  - type: Secret
-    secretName: jenkins-mysecrets
-    mountPath: /var/run/secrets/jenkins-mysecrets
+    - type: Secret
+      secretName: jenkins-mysecrets
+      mountPath: /var/run/secrets/jenkins-mysecrets
 ```
 
 The supported volume types are: `ConfigMap`, `EmptyDir`, `HostPath`, `Nfs`, `PVC`, `Secret`.
@@ -375,11 +389,11 @@
 2. Create the PersistentVolumeClaim
 3. [Install](#install-chart) the chart, setting `persistence.existingClaim` to `PVC_NAME`
 
-#### Long Volume Attach/Mount Times
+#### Long Volume Attach-/Mount Times
 
 Certain volume type and filesystem format combinations may experience long
 attach/mount times, [10 or more minutes][K8S_VOLUME_TIMEOUT], when using
-`fsGroup`.  This issue may result in the following entries in the pod's event
+`fsGroup`. This issue may result in the following entries in the pod's event
 history:
 
 ```console
@@ -387,7 +401,7 @@
 ```
 
 In these cases, experiment with replacing `fsGroup` with
-`supplementalGroups` in the pod's `securityContext`.  This can be achieved by
+`supplementalGroups` in the pod's `securityContext`. This can be achieved by
 setting the `controller.podSecurityContextOverride` Helm chart value to
 something like:
 
@@ -419,6 +433,7 @@
 The secret may then be referenced in JCasC configuration (see [JCasC configuration](#configuration-as-code)).
 
 `values.yaml` controller section, referencing mounted secrets:
+
 ```yaml
 controller:
   # the 'name' and 'keyName' are concatenated with a '-' in between, so for example:
@@ -428,7 +443,7 @@
   # existingSecret existing secret "secret-credentials" and a key inside it named "github-username" should be used in Jcasc as ${github-username}
   # When using existingSecret no need to specify the keyName under additionalExistingSecrets.
   existingSecret: secret-credentials
-  
+
   additionalExistingSecrets:
     - name: secret-credentials
       keyName: github-username
@@ -436,7 +451,7 @@
       keyName: github-password
     - name: secret-credentials
       keyName: token
-  
+
   additionalSecrets:
     - name: client_id
       value: abc123
@@ -476,6 +491,7 @@
 These `Secrets` can then be referenced in the same manner as Additional Secrets above.
 
 This can be achieved by defining required Secret Claims within `controller.secretClaims`, as follows:
+
 ```yaml
 controller:
   secretClaims:
@@ -569,11 +585,11 @@
 
 ```yaml
 controller:
-   ingress:
-       enabled: true
-       paths: []
-       apiVersion: "extensions/v1beta1"
-       hostName: jenkins.example.com
+  ingress:
+    enabled: true
+    paths: []
+    apiVersion: "extensions/v1beta1"
+    hostName: jenkins.example.com
 ```
 
 This snippet configures an ingress rule for exposing jenkins at `jenkins.example.com`
@@ -588,20 +604,20 @@
 
 ```yaml
 controller:
-   ingress:
-       enabled: true
-       apiVersion: "extensions/v1beta1"
-       hostName: "jenkins.internal.example.com"
-       annotations:
-           kubernetes.io/ingress.class: "internal"
-   secondaryingress:
-       enabled: true
-       apiVersion: "extensions/v1beta1"
-       hostName: "jenkins-scm.example.com"
-       annotations:
-           kubernetes.io/ingress.class: "public"
-       paths:
-        - /github-webhook
+  ingress:
+    enabled: true
+    apiVersion: "extensions/v1beta1"
+    hostName: "jenkins.internal.example.com"
+    annotations:
+      kubernetes.io/ingress.class: "internal"
+  secondaryingress:
+    enabled: true
+    apiVersion: "extensions/v1beta1"
+    hostName: "jenkins-scm.example.com"
+    annotations:
+      kubernetes.io/ingress.class: "public"
+    paths:
+      - /github-webhook
 ```
 
 ## Prometheus Metrics
@@ -655,15 +671,16 @@
 
 ```yaml
 controller:
-   httpsKeyStore:
-       enable: true
-       jenkinsHttpsJksSecretName: ''
-       httpPort: 8081
-       path: "/var/jenkins_keystore"
-       fileName: "keystore.jks"
-       password: "changeit"
-       jenkinsKeyStoreBase64Encoded: ''
+  httpsKeyStore:
+    enable: true
+    jenkinsHttpsJksSecretName: ""
+    httpPort: 8081
+    path: "/var/jenkins_keystore"
+    fileName: "keystore.jks"
+    password: "changeit"
+    jenkinsKeyStoreBase64Encoded: ""
 ```
+
 ### AWS Security Group Policies
 
 To create SecurityGroupPolicies set `awsSecurityGroupPolicies.enabled` to true and add your policies. Each policy requires a `name`, array of `securityGroupIds` and a `podSelector`. Example:
@@ -673,7 +690,7 @@
   enabled: true
   policies:
     - name: "jenkins-controller"
-      securityGroupIds: 
+      securityGroupIds:
         - sg-123456789
       podSelector:
         matchExpressions: