Repository Configuration

Each source control repository can optionally contain a signadot.yaml file at its root to configure how Signadot treats the contents of that repository. This page describes the available fields in that file.

Manifests

Kubernetes manifests are files containing one or more YAML documents (separated by --- as a line by itself) that each define an object, such as a Deployment or Service, to be sent to the Kubernetes API. These files can be sent directly with kubectl apply -f ... or processed first by a tool like Helm or Kustomize.

The manifests section of signadot.yaml allows you to tell Signadot where in a given repository you store raw Kubernetes manifests, or how to generate the final manifests with a processing tool. Signadot can then inspect the objects defined in those manifests to do things like automatically apply manifest changes from a branch or pull request to one or more workspaces.

You are free to store manifests either together with the source code or in a separate repository, and they can either be split up by service or stored in a central location. Once you tell Signadot how to find these manifests through signadot.yaml, you can preview configuration changes to supported objects like Deployment by simply opening a pull request.

The manifests list can contain any number of entries, each of which can be defined in any of the following ways. The manifests from all entries will be merged into a single result set before Signadot proceeds to analyze them.

Raw Manifests

If your repository contains raw Kubernetes manifests (suitable for sending directly to kubectl apply -f ...), you just need to specify the relative path to those manifests within the repository in the same format expected by the -f flag of kubectl apply.

The namespace field is used to fill in the namespace for any objects that don't specify one, similar to how kubectl uses the namespace of the current context (or the value of the -n|--namespace flag) as the default when applying manifests.

manifests:
  # Single file
  - path: deploy/k8s/service-1/deployment.yaml
    namespace: my-app

  # Include all *.yaml files in a directory (optionally recursive)
  - path: deploy/k8s/service-2/
    recursive: true
    namespace: my-app

Generated Manifests

If you usually generate manifests from templates stored in the repository, you can specify a command line or bash script to run within a checked-out copy of the repository.

The script runs within a Pod in your own Kubernetes cluster, using a container image with several common tools installed, such as helm (v3) and kustomize. The working directory will be set to the root of the checked-out repository, and the standard output of the script will be processed as a stream of YAML documents (separated by --- as a line by itself).

The namespace field is used to fill in the namespace for any objects that don't specify one, similar to how kubectl uses the namespace of the current context (or the value of the -n|--namespace flag) as the default when applying manifests.

manifests:
  # Example helm (v3) command
  - generate:
      run: helm template charts/service-1
    namespace: my-app

  # Example kustomize command
  - generate:
      run: kustomize build deploy/staging/service-1
    namespace: my-app

  # Example bash script
  - generate:
      run: |
        for file in $(find deploy/ -name '*.yaml'); do
          sed s/foo/bar/ $file
          echo ---
        done
    namespace: my-app

Did this page help you?