Git Repository Contents

Fleet 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 further by reading the discovered fleet.yaml file. Bundle lifecycles are tracked between releases by the helm releaseName field added to each bundle. If the releaseName is not specified within fleet.yaml it is generated from GitRepo.name + path. Long names are truncated and a -<hash> prefix is added.

The git repository has no explicitly required structure. It is important to realize the scanned resources will be saved as a resource in Kubernetes so you want to make sure the directories you are scanning in git do not contain arbitrarily large resources. Right now there is a limitation that the resources deployed must gzip to less than 1MB.

How repos are scanned

Multiple paths can be defined for a GitRepo and each path is scanned independently. Internally each scanned path will become a bundle that Fleet will manage, deploy, and monitor independently.

Fleet looks for the following files to determine how the resources will be deployed.

File Location Meaning

File	Location	Meaning
Chart.yaml	/ relative to `path` or custom path from `fleet.yaml`	The resources will be 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 will be deployed using Kustomize. Refer to the `fleet.yaml` for more options.
fleet.yaml	Any subpath	If any fleet.yaml is found a new bundle will be defined. This allows mixing charts, kustomize, and raw YAML in the same repo
.yaml	Any subpath	If a `Chart.yaml` or `kustomization.yaml` is not found then any `.yaml` or `.yml` file will be assumed to be a Kubernetes resource and will be 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 will be 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 will be deployed using Kustomize. Refer to the fleet.yaml for more options.

fleet.yaml

Any subpath

If any fleet.yaml is found a new bundle will be defined. This allows mixing charts, kustomize, and raw YAML in the same repo

.yaml

Any subpath

If a Chart.yaml or kustomization.yaml is not found then any .yaml or .yml file will be assumed to be a Kubernetes resource and will be deployed.

overlays/{name}

/ relative to path

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

Excluding files and directories from bundles

Fleet supports file and directory exclusion by means of .fleetignore files, in a similar fashion to how .gitignore files behave in git repositories:

Glob syntax is used to match files or directories, using Golang’s filepath.Match
Empty lines are skipped, and can therefore be used to improve readability
Characters like white spaces and # can be escaped with a backslash
Trailing spaces are ignored, unless escaped
Comments, ie lines starting with unescaped #, are skipped
A given line can match a file or a directory, even if no separator is provided
A match may be found for a file or directory at any level below the directory where a .fleetignore lives
Multiple .fleetignore files are supported

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

This currently comes with a few limitations, the following not being supported:

Double asterisks (**)
Explicit inclusions with !

`fleet.yaml`

The fleet.yaml is an optional file that can be included in the git repository to change the behavior of how the resources are deployed and customized.

Helm chart dependencies:

It is up to the user to fulfill the dependency list for the Helm charts. As such, you must manually run:

helm dependencies update $chart
helm dependencies build $chart

See Fleet docs.

The available fields are documented in the fleet.yaml reference.

See Using Private Helm Repositories.

Using Helm Values

How changes are applied to values.yaml:

Most recent changes override previous values
Order: helm.values → helm.valuesFiles → helm.valuesFrom

See Helm values templating.

Credentials in Values

If the chart generates certificates or passwords in its templates, these values must be overriden.

Credentials loaded with valuesFrom are encrypted when Kubernetes encryption is enabled.

Using ValuesFrom

Example ConfigMap:

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

Example Secret:

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

kubectl create secret generic secret-values --from-file=values.yaml=secretdata.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

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

targetCustomizations:
- name: prod
  clusterName: fleetname

See Mapping to Downstream Clusters.

Raw YAML Resource Customization

deployment.yaml
svc.yaml

overlays/custom/configmap.yaml
overlays/custom/svc.yaml
overlays/custom/deployment_patch.yaml

Cluster and Bundle State

See Cluster and Bundle State.

Nested GitRepo CRs

Fleet supports nested GitRepo resources repositories containing other GitRepo definitions. This allows complex GitOps setups or multi-level repository structures.

Example: Multi-GitRepo Example.

[08:51:58.904] ERROR (asciidoctor): dropping cells from incomplete row detected end of table file: /home/runner/work/fleet-product-docs/fleet-product-docs/community-docs/v0.12/modules/ROOT/pages/explanations/gitrepo-content.adoc:47 source: /home/runner/work/fleet-product-docs/fleet-product-docs (branch: HEAD <worktree> | start path: community-docs/v0.12)

[08:51:59.102] ERROR (asciidoctor): dropping cells from incomplete row detected end of table file: /home/runner/work/fleet-product-docs/fleet-product-docs/community-docs/v0.12/modules/ROOT/pages/explanations/gitrepo-content.adoc:47 source: /home/runner/work/fleet-product-docs/fleet-product-docs (branch: HEAD <worktree> | start path: community-docs/v0.12)

[08:51:58.935] WARN (asciidoctor): unterminated example block file: /home/runner/work/fleet-product-docs/fleet-product-docs/community-docs/v0.12/modules/ROOT/pages/reference/ref-fleet-yaml.adoc:228 source: /home/runner/work/fleet-product-docs/fleet-product-docs (branch: HEAD <worktree> | start path: community-docs/v0.12)

[08:51:59.500] WARN (asciidoctor): unterminated example block file: /home/runner/work/fleet-product-docs/fleet-product-docs/community-docs/v0.12/modules/ROOT/pages/reference/ref-fleet-yaml.adoc:228 source: /home/runner/work/fleet-product-docs/fleet-product-docs (branch: HEAD <worktree> | start path: community-docs/v0.12)