Skip to main content
Version: Release 25.1

Customize Your Site - Release Custom Configuration

Introduction

Digital.ai Release configuration is managed through the conf directory in the Release folder. This directory contains all operational configuration files.

At startup, configuration files in conf are generated from templates in the default-conf directory. The system copies these templates into conf, replacing files only if they do not already exist—except for xl-release.conf, which is always replaced.

Prerequisites

Before customizing configuration, ensure you have:

  • A Digital.ai Release installation running on a Kubernetes cluster
  • kubectl connected to the cluster
  • Release operator version 23.3 or later

Updating Configuration Files

To update a configuration file (for example, xl-release.conf):

  1. Download the latest template from the Release pod.
    • Example: Download xl-release.conf.template from /opt/xebialabs/xl-release-server/default-conf/xl-release.conf.template:
    kubectl cp -c release \
    digitalai/dai-xlr-digitalai-release-0:default-conf/xl-release.conf.template \
    xl-release.conf.template
  2. Edit the template as needed.
    vi xl-release.conf.template
  3. Create a patch file for the custom resource (CR).
    c=$(cat xl-release.conf.template) \
    yq -n '.spec.configuration.default-conf_xl-release-conf-template.content = strenv(c)' \
    > xl-release-conf-patch.yaml
  4. (Optional) Backup the existing configuration from the pod.
    kubectl cp -c release \
    digitalai/dai-xlr-digitalai-release-0:conf/xl-release.conf \
    backup/xl-release.conf
  5. Apply the patch to update the configuration on the Release pods.
    kubectl patch -n digitalai digitalaireleases.xlr.digital.ai dai-xlr \
    --type=merge --patch-file xl-release-conf-patch.yaml
note

The system automatically restarts the Release pods after the update.

Updating Other Configuration Files Using Templates

You can update other configuration files in the application directory using the same approach. Common files include:

  • boot.conf.cloud.template
  • jmx-exporter.yaml
  • logback-access.xml
  • logback.xml
  • logging.properties
  • script.policy
  • script.policy.template
  • wrapper-daemon.vm
  • xl-release-security.xml
  • xl-release-server.conf.template
  • xl-release.conf.template
  • xl-release.policy
  • xlr-wrapper-linux.conf
  • xlr-wrapper-win.conf

Example: Update xlr-wrapper-linux.conf

  1. Set environment variables for the file to update:

    export FILE_TO_UPDATE=xlr-wrapper-linux.conf
    export TEMPLATE_DIR=default-conf
    export TARGET_DIR=conf
    export TARGET_FILE=xlr-wrapper-linux.conf
  2. Download the latest template:

    kubectl cp -c release \
    digitalai/dai-xlr-digitalai-release-0:$TEMPLATE_DIR/$FILE_TO_UPDATE \
    $FILE_TO_UPDATE
  3. Edit the template as needed:

    vi $FILE_TO_UPDATE
  4. Create a patch file for the CR:

    c=$(cat $FILE_TO_UPDATE) \
    contentPath=".spec.extraConfiguration.${TEMPLATE_DIR}_${FILE_TO_UPDATE//./-}.content" \
    f="${TEMPLATE_DIR}/$FILE_TO_UPDATE" \
    filePath=".spec.extraConfiguration.${TEMPLATE_DIR}_${FILE_TO_UPDATE//./-}.path" \
    yq -n 'eval(strenv(contentPath)) = strenv(c) | eval(strenv(filePath)) = strenv(f)' \
    > "$FILE_TO_UPDATE.patch.yaml"
  5. (Optional) Backup the existing file from the pod:

    kubectl cp -c release \
    digitalai/dai-xlr-digitalai-release-0:$TARGET_DIR/$TARGET_FILE \
    backup/$TARGET_FILE
  6. (If needed) Delete the configuration file from the pod to force recreation:

    note

    This step is only required if the target folder is mounted as a persistent volume. From version 24.1 onward, this is not the default.

    kubectl exec -c release -it sts/dai-xlr-digitalai-release -n digitalai \
    -- rm $TARGET_DIR/$TARGET_FILE
  7. Apply the patch to update the configuration:

    kubectl patch -n digitalai digitalaireleases.xlr.digital.ai dai-xlr \
    --type=merge --patch-file $FILE_TO_UPDATE.patch.yaml
note
  • The Release pods restart automatically after the update.
  • The new configuration is applied after the next operator reconciliation cycle (up to one minute), which triggers a rollout restart.