You're viewing documentation for Anthos Config Management 1.3. This version has reached end of life and is no longer supported. View the latest documentation.

Using an unstructured repo

Creating an unstructured repo allows you to organize your repo arbitrarily, without following the default repo directory structure. Anthos Config Management syncs the same set of Kubernetes objects to your cluster as in the default, hierarchical, repo.

This allows you to sync your existing Kubernetes configuration to your Anthos Config Management repo. For example, if you want to sync a Helm chart to your cluster, you can run helm template and commit the rendered manifest to your repo.


Unstructured repos do not support all Anthos Config Management features. This section describes the primary differences between hierarchical and unstructured repos.

Unsupported objects

You cannot use the Repo and HierarchyConfig Kubernetes Objects in an unstructured repo.

Namespace-scoped objects

Abstract namespaces are not supported in unstructured repos.

In an unstructured repo, all namespace-scoped objects should declare either the metadata.namespace or the NamespaceSelector annotation. Declaring both annotations is invalid. If namespace-scoped resources don't declare metadata.namespace or the NamespaceSelector annotation, then Anthos Config Management uses the cluster's "default" namespace. See Selectors below for NamespaceSelector semantics.


You can declare ClusterSelectors and NamespaceSelectors in an unstructured repo.

In an unstructured repo, ClusterSelectors function normally.

In an unstructured repo, Objects that declare the NamespaceSelector annotation are applied to all namespaces that satisfy the NamespaceSelector's conditions. Before you create an unstructured repo with Objects that were previously used in a hierarchical repo, verify that your NamespaceSelectors do not apply to additional resources.

Configuring an unstructured repo

To configure an unstructured repo, set the value of spec.sourceFormat to unstructured in config-management.yaml.

For example, the config-management.yaml below sets up the example Continuous Integration pipeline.

# config-management.yaml

kind: ConfigManagement
  name: config-management
  # clusterName is required and must be unique among all managed clusters
  clusterName: my-cluster
    syncBranch: 1.0.0
    secretType: ssh
    policyDir: ci-pipeline-unstructured
  sourceFormat: unstructured

What's next