Jenkins Configuration as Code (JCasC)

To run JMH benchmarks using Jenkins Configuration as Code, extend CascJmhBenchmarkState instead of the standard JmhBenchmarkState. You must override two specific methods to provide the necessary context for the JCasC engine:

1. getResourcePath(): Return the path to your YAML configuration file.
2. getEnclosingClass(): Return the class that contains the benchmark state.

Important: If you override the setup() method in your state class, you must call super.setup() to ensure the Configuration as Code initialization completes correctly.

@JmhBenchmark
public class MyBenchmark {
    public static class MyState extends CascJmhBenchmarkState {
        @Nonnull
        @Override
        protected String getResourcePath() {
            return "config.yaml";
        }
    
        @Nonnull
        @Override
        protected Class<?> getEnclosingClass() {
            return MyBenchmark.class;
        }
    }
    
    // ...
}

You can configure the LDAP plugin using Jenkins Configuration as Code by defining the jenkins.securityRealm.ldap hierarchy in your YAML configuration. This allows you to set up LDAP server details, search filters, and caching strategies without writing custom adapter code, as hudson.security.LDAPSecurityRealm is natively supported via its @DataBoundConstructor parameters.

jenkins:
  securityRealm:
    ldap:
      configurations:
        - server: ldap.acme.com
          rootDN: dc=acme,dc=fr
          managerDN: "manager"
          managerPasswordSecret: "${LDAP_PASSWORD}"
          userSearch: "(&(objectCategory=User)(sAMAccountName={0}))"
          groupSearchFilter: "(&(cn={0})(objectclass=group))"
          groupMembershipStrategy:
            fromGroupSearch:
              filter: "(&(objectClass=group)(|(cn=GROUP_1)(cn=GROUP_2)))"
      cache:
        size: 100
        ttl: 10
      userIdStrategy: CaseInsensitive
      groupIdStrategy: CaseSensitive

To use sensitive values in your Jenkins Configuration as Code (JCasC) YAML files within a Kubernetes environment, you can leverage Kubernetes Secrets and the SECRETS environment variable.

Prerequisites

1. Define the SECRETS environment variable in your container specification to point to the path where your secret volume is mounted.
2. Create Kubernetes Secrets containing the required sensitive values.
3. Ensure your Kubernetes manifest includes the necessary volumes and volumeMounts to mount these secrets into the Jenkins container.

Implementation Steps

1. Prepare the Secret: All values in the Kubernetes Secret must be provided in base64 encoding.
2. Reference Secrets in JCasC: Use the syntax ${VARIABLE_NAME} in your jenkins.yaml to reference environment variables that will be populated from the mounted secrets.
3. Configure the Container:
   • Set CASC_JENKINS_CONFIG to the path of your JCasC configuration file (e.g., from a ConfigMap).
   • Set SECRETS to the mount path of your secret volume.
   • Mount the ConfigMap and the Secret as volumes.

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: jenkins-casc
data:
  jenkins.yaml: |
    jenkins:
      location:
        url: http://jenkins/
        adminAddress: "${SECRET_JENKINS_ADMIN_ADDRESS}"
---
kind: Secret
apiVersion: v1
metadata:
  name: jenkins-secrets
type: Opaque
data:
  # All values for secrets should be provided in base64 encoding
  SECRET_JENKINS_ADMIN_ADDRESS: YWRtaW5AZXhhbXBsZS5jb20=
---
apiVersion: apps/v1beta1
kind: StatefulSet
spec:
  containers:
    - name: jenkins
      env:
        # Path to the JCasC ConfigMap file
        - name: CASC_JENKINS_CONFIG
          value: /var/jenkins_config/jenkins.yaml
        # Path to the mounted secret volume
        - name: SECRETS
          value: /secrets/jenkins
      volumeMounts:
        - name: jenkins-configuration-as-code
          mountPath: /var/jenkins_config
        - name: jenkins-secrets
          mountPath: /secrets/jenkins
          readOnly: true
  volumes:
    - name: jenkins-configuration-as-code
      configMap:
        name: jenkins-casc
    - name: jenkins-secrets
      secret:
        secretName: jenkins-secrets

You can configure how Maven accesses global settings and user settings using three different methods:

1. Default Files: Use the standard provider for both globalSettingsProvider and settingsProvider to use Maven's default behavior.
2. Given Files: Specify explicit file paths on the filesystem using the filePath.path key for both globalSettingsProvider and settingsProvider.
3. Config File Provider: Integrate with the Config File Provider plugin by referencing a configuration ID via mvn.settingsConfigId.

# Method 1: Using Maven default files
tool:
  mavenGlobalConfig:
    globalSettingsProvider: "standard"
    settingsProvider: "standard"

# Method 2: Using given files
tool:
  mavenGlobalConfig:
    globalSettingsProvider:
      filePath:
        path: "/conf/maven/global-settings.xml"
    settingsProvider:
      filePath:
        path: "/conf/maven/settings.xml"

# Method 3: Using a configured config file (Config File Provider)
tool:
  mavenGlobalConfig:
    globalSettingsProvider:
      mvn:
        settingsConfigId: "global-maven-settings"
    settingsProvider: "standard"

You can use Jenkins Configuration as Code (JCasC) to manage files managed by the Config File Provider plugin. For plugin version 3.4.1 and up, you can define global configuration files under the unclassified.globalConfigFiles.configs key in your YAML configuration.

Supported file types include custom, json, xml, and mavenSettings. Each entry requires an id, name, and content. Specific types like mavenSettings support additional fields such as isReplaceAll and serverCredentialMappings.

unclassified:
  globalConfigFiles:
    configs:
      - custom:
          id: custom-test
          name: DummyCustom1
          comment: dummy custom 1
          content: dummy content 1
      - json:
          id: json-test
          name: DummyJsonConfig
          comment: dummy json config
          content: |
            { "dummydata": {"dummyKey": "dummyValue"} }
      - xml:
          id: xml-test
          name: DummyXmlConfig
          comment: dummy xml config
          content: <root><dummy test="abc"></dummy></root>
      - mavenSettings:
          id: maven-test
          name: DummySettings
          comment: dummy settings
          isReplaceAll: false
          serverCredentialMappings:
            - serverId: server1
              credentialsId: someCredentials1
            - serverId: server2
              credentialsId: someCredentials2
          content: |
            <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
              <activeProfiles>
                <activeProfile>alwaysActiveProfile</activeProfile>
                <activeProfile>anotherAlwaysActiveProfile</activeProfile>
              </activeProfiles>
            </settings>