Git Repository Contents

SUSE® Rancher Prime Continuous Delivery creates bundles from a git repository. This happens either explicitly by specifying paths, or when a fleet.yaml is found.

Each bundle is created from paths in a GitRepo and modified based on the discovered fleet.yaml. Bundle lifecycles are tracked between releases using the Helm releaseName field. If releaseName is not specified in fleet.yaml, it’s automatically generated as GitRepo.name + path. Long names are truncated and appended with a -<hash> suffix.

By default, bundle names will also be generated from the GitRepo’s name and the path from which the bundle is created. However, a bundle’s name can be overridden by using the name field in a fleet.yaml file.

The Git repository has no required structure. All scanned resources are stored as Kubernetes resources, so ensure scanned directories do not contain large files. Currently, resources must gzip to less than 1 MB.

How Repositories Are Scanned

Multiple paths can be defined for a GitRepo. Each path is scanned independently and becomes a managed bundle that SUSE® Rancher Prime Continuous Delivery deploys and monitors.

SUSE® Rancher Prime Continuous Delivery looks for the following files to determine deployment behavior:

File Location Meaning

File	Location	Meaning
Chart.yaml	Relative to `path` or custom path from `fleet.yaml`	The resources are deployed as a Helm chart. Refer to the `fleet.yaml` for more options.
kustomization.yaml	Relative to `path` or custom path from `fleet.yaml`	The resources are deployed using Kustomize. Refer to the `fleet.yaml` for more options.
fleet.yaml	Any subpath	If any `fleet.yaml` is found, a new bundle is defined. This allows mixing charts, Kustomize, and raw YAML in the same repository.
\.yaml*	Any subpath	If a `Chart.yaml` or `kustomization.yaml` isn’t found, any `.yaml` or `.yml` file is assumed to be a Kubernetes resource and is deployed.
overlays/{name}	Relative to `path`	When deploying using raw YAML (not Kustomize or Helm), `overlays` is a special directory for customizations.

Chart.yaml

Relative to path or custom path from fleet.yaml

The resources are deployed as a Helm chart. Refer to the fleet.yaml for more options.

kustomization.yaml

Relative to path or custom path from fleet.yaml

The resources are deployed using Kustomize. Refer to the fleet.yaml for more options.

fleet.yaml

Any subpath

If any fleet.yaml is found, a new bundle is defined. This allows mixing charts, Kustomize, and raw YAML in the same repository.

\.yaml*

Any subpath

If a Chart.yaml or kustomization.yaml isn’t found, any .yaml or .yml file is assumed to be a Kubernetes resource and is deployed.

overlays/{name}

Relative to path

When deploying using raw YAML (not Kustomize or Helm), overlays is a special directory for customizations.

Alternative Scan: Explicitly Defined by the User

SUSE® Rancher Prime Continuous Delivery also supports a user-driven method for defining Bundles directly.

In this mode, SUSE® Rancher Prime Continuous Delivery loads resources from a specified base directory. It looks for a fleet.yaml at the root only if an options file isn’t provided. This method is non-recursive and loads only explicitly defined Bundles.

Example File Structure

driven/
├── helm/
│   └── fleet.yaml
├── simple/
│   ├── configmap.yaml
│   └── service.yaml
└── kustomize/
    ├── base/
    │   ├── kustomization.yaml
    │   └── secret.yaml
    ├── overlays/
    │   ├── dev/
    │   │   ├── kustomization.yaml
    │   │   └── secret.yaml
    │   ├── prod/
    │   │   ├── kustomization.yaml
    │   │   └── secret.yaml
    │   └── test/
    │       ├── kustomization.yaml
    │       └── secret.yaml
    ├── dev.yaml
    ├── prod.yaml
    └── test.yaml

Corresponding GitRepo Definition

kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: driven
  namespace: fleet-local
spec:
  repo: https://github.com/0xavi0/fleet-test-data
  branch: driven-scan-example
  bundles:
    - base: driven/helm
    - base: driven/simple
    - base: driven/kustomize
      options: dev.yaml
    - base: driven/kustomize
      options: test.yaml

In this example:

driven/helm: contains a fleet.yaml that configures the Bundle.
driven/simple: contains only manifests; SUSE® Rancher Prime Continuous Delivery packages all resources by default.
driven/kustomize: reused for multiple environments using different options files (dev.yaml, test.yaml).

Example options file for driven/kustomize:

namespace: kustomize-dev
kustomize:
  dir: "overlays/dev"

All paths must be relative to the base directory. If base: driven/kustomize, paths in options files are relative to driven/kustomize.

Incorrect:

namespace: kustomize-dev
kustomize:
  dir: "."

Correct:

namespace: kustomize-dev
kustomize:
  dir: "overlays/dev"

This approach simplifies working with Kustomize and provides finer control compared to recursive scanning.

Excluding Files and Directories

SUSE® Rancher Prime Continuous Delivery supports .fleetignore files, similar to .gitignore, to exclude files and directories.

Uses Go’s [filepath.Match](https://pkg.go.dev/path/filepath#Match) syntax.
Supports comments (#), escaped characters, and multiple .fleetignore files.
Applies recursively under each .fleetignore directory.

Example:

root/
├── .fleetignore            # contains `ignore-always.yaml`
├── something.yaml
├── bar/
│   ├── .fleetignore        # contains `something.yaml`
│   ├── ignore-always.yaml
│   ├── something2.yaml
│   └── something.yaml
└── foo/
    ├── ignore-always.yaml
    └── something.yaml

Unsupported: * ** wildcards * Explicit inclusions (!)

The `fleet.yaml` File

fleet.yaml modifies how resources are deployed and customized. It’s located at the root relative to the GitRepo.path. If found in a subdirectory, it defines a new bundle configured independently.

Helm chart dependencies SUSE® Rancher Prime Continuous Delivery automatically updates Helm chart dependencies unless disableDependencyUpdate: true is set. If disabled, manually update dependencies using:

helm dependencies update $chart
helm dependencies build $chart

For field details, see SUSE® Rancher Prime Continuous Delivery YAML Reference. For private Helm repositories, see Using Private Helm Repositories.

Using Helm Values

When applying changes to values.yaml:

The most recently applied changes to the values.yaml override any previously existing values.
When changes are applied to the values.yaml from multiple sources at the same time, the values update in the following order:
1. helm.values
2. helm.valuesFiles
3. helm.valuesFrom

This means that valuesFrom always overrides both valuesFiles and values.

Templating

The targeting step can treat the values as a template and fill in information from the clusters.fleet.cattle.io resource. For more information, refer to [Helm values templating].

You can turn this off in fleet.yaml, by setting disablePreProcess. This is useful to avoid conflicts with other templating languages.

It is not necessary to reference a chart’s own values.yaml via valuesFiles:. The values.yaml file contained in the chart is always used as a default when the agent installs the chart.

If the chart generates certificates or passwords in its templates, these values must be overridden. Otherwise, the chart could be continuously deployed as these values change.

Credentials loaded from the downstream cluster with valuesFrom are, by default, encrypted at rest when data encryption is enabled in Kubernetes. Credentials contained in the default values.yaml file, or defined via values: or valuesFiles, are not encrypted, as they are loaded from the repository when the bundle is created.

Hardened clusters should add the Fleet CRDs to the resources encrypted at rest list on the upstream cluster when storing credentials in the bundles.

Understanding Helm `values.yaml` vs Fleet `valuesFiles`

Installing Helm charts with Fleet offers multiple ways of configuring and referencing values, using the chart’s built-in values.yaml and additional values files referenced in fleet.yaml. These files serve different purposes, and it’s important to understand how they interact.

Example directory structure

.
├── Chart.yaml
├── fleet.yaml
├── README.md
├── templates/
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml   # chart defaults

You can use a Helm chart’s values.yaml file to:

Provide default settings and allow users to override defaults without modifying the chart itself.
Define common Kubernetes resource defaults.

A Helm chart’s values.yaml does not support templating. Any substitutions happen during chart rendering before Fleet applies the chart.

You cannot use shell-style variables (for example, ${var}) inside this file.
If ${var} appears, Helm treats it as plain text—you don’t need to escape it.

Fleet valuesFiles referenced from fleet.yaml

Fleet lets you reference additional values files through fleet.yaml. These files override or extend the chart’s baseline defaults.

A valuesFiles entry is equivalent to copy-pasting the contents of that file into the values section of fleet.yaml.
It’s mainly a convenience feature for splitting values into multiple files.
Unlike Helm chart values.yaml, Fleet’s values files support templating, which enables dynamic configuration per environment.

Example fleet.yaml

helm:
  valuesFiles:
    - values.prod.yaml   # overrides baseline

You can use Fleet valuesFiles referenced from fleet.yaml to:

Apply environment-specific overrides (dev, staging, prod).
Enable advanced features not included in chart defaults.

Whether you use Helm values.yaml, Fleet values: or valuesFiles, never store credentials in these files.

The recommended and safer approach is to use valuesFrom, which references Kubernetes Secrets or ConfigMaps. Although this requires creating the Secrets on downstream clusters, it ensures sensitive data is stored securely.

Using valuesFrom

Example ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap-values
  namespace: default
data:
  values.yaml: |-
    replicas: 2
    serviceType: NodePort

Example Secret:

apiVersion: v1
kind: Secret
metadata:
  name: secret-values
  namespace: default
stringData:
  values.yaml: |-
    replicas: 3
    serviceType: NodePort

Create the secret:

kubectl create secret generic secret-values --from-file=values.yaml=secretdata.yaml

Reference them in fleet.yaml:

helm:
  chart: simple-chart
  valuesFrom:
    - secretKeyRef:
        name: secret-values
        namespace: default
        key: values.yaml
    - configMapKeyRef:
        name: configmap-values
        namespace: default
        key: values.yaml
  values:
    replicas: "4"

Per-Cluster Customization

SUSE® Rancher Prime Continuous Delivery customizes resources per cluster using targetCustomizations in fleet.yaml.

Cluster matching uses any combination of:

clusterSelector
clusterGroupSelector
clusterGroup

Example:

targetCustomizations:
  - name: all
    clusterSelector: {}
  - name: none
    clusterSelector: null

To match a specific cluster, use the clusters.fleet.cattle.io resource name.

targetCustomizations:
  - name: prod
    clusterName: fleetname

See Customization per Cluster for details.

Raw YAML Customization

When using raw YAML instead of Helm or Kustomize, you can apply overlays via the overlays/ directory.

deployment.yaml
svc.yaml
overlays/custom/configmap.yaml         # added
overlays/custom/svc.yaml               # replaces svc.yaml
overlays/custom/deployment_patch.yaml  # patches deployment.yaml

Files ending in _patch. (for example, deployment_patch.yaml) patch matching base files. Patching uses JSON Merge, Strategic Merge, or JSON Patch, depending on content.

Cluster and Bundle State

See Cluster and Bundle State.

Nested GitRepo CRs

SUSE® Rancher Prime Continuous Delivery supports nested GitRepo resources repositories containing other GitRepo definitions. This allows complex GitOps setups or multi-level repository structures.

Example: Multi-GitRepo Example.