DOCSEARCHbyAlgolia
Submit Docs

chart-testing (ct)

repository·main·Indexed 23 days ago

https://github.com/helm/chart-testing

A tool for testing Helm charts, optimized for linting and validating pull requests by automatically detecting changed charts. It provides subcommands to lint, install, and test charts, including support for upgrade testing, custom values files in ci/ directories, and integration with CI/CD pipelines like Google Cloud Build and CircleCI.

Tokens
14.2K
Snippets
14
Records
35
Agent score
81%

What's inside chart-testing

  1. Use the ct CLI to lint and test Helm charts

    main

    The ct tool is used to lint and test Helm charts. It can be configured to run against changed charts, specific charts, or all charts within provided chart directories.

    To see all available commands and options, use the --help flag.

  2. Understand the simple-deployment-different-selector integration test

    main

    This test chart is designed to verify failure scenarios during Helm upgrades. The integration test workflow follows these steps:

    1. Install the simple-deployment chart.
    2. Attempt to upgrade the release to the simple-deployment-different-selector chart.
    3. The upgrade is expected to fail because the Deployment in this chart uses a different selector than the one initially installed, which is a breaking change in Kubernetes/Helm.

  3. Build chart-testing from source

    main

    The tool is built using Go 1.13 or higher. Use the provided build.sh script, which utilizes Goreleaser.

    MacOS Requirement: You must have GNU Coreutils readlink installed. You can install it via Homebrew and add the gnubin directory to your PATH:

    brew install coreutils
echo 'export PATH="$(brew --prefix coreutils)/libexec/gnubin:$PATH"' >> ~/.bash_profile
bash --login

    Build Command:

    ./build.sh -h

    Build Options:

    • -h, --help: Display help
    • -d, --debug: Display verbose output and run Goreleaser with --debug
    • -r, --release: Create a release using Goreleaser (creates GitHub release and pushes Docker image). If not specified, runs with --snapshot.

  4. Lint and validate Helm charts with `ct lint`

    main

    The ct lint command is used to perform a comprehensive validation suite on Helm charts. It performs the following actions:

    1. Helm Linting: Runs helm lint on the chart.
    2. Version Checking: Verifies chart versioning.
    3. YAML Schema Validation: Validates Chart.yaml against a schema.
    4. YAML Linting: Lints Chart.yaml and all values.yaml files.
    5. Maintainer Validation: Validates maintainer account names (supporting GitHub, GitLab, and Bitbucket).

    By default, ct lint processes only the charts that have changed relative to a Git reference. It also automatically detects custom values files matching the glob pattern *-values.yaml located in a ci/ directory within the chart's root. If these files exist, the chart is linted against each one; otherwise, it uses the default values.

    To target specific charts, use the --charts flag. To process every chart in the provided directories, use the --all flag.

    ct lint [flags]

  5. Install and test Helm charts with `ct install`

    main

    The ct install command automates the process of running helm install, helm test, and optionally helm upgrade on Helm charts.

    By default, it identifies and tests only the charts that have changed. You can also target specific charts or all charts in your directories.

    Testing with Custom Values

    Charts can use custom values files for testing. If a directory named ci exists at the root of a chart's directory, ct install will look for files matching the glob pattern *-values.yaml. The command will perform an install and test for each of these files. If no such files are found, it uses the chart's default values.

    Upgrade Testing

    If the --upgrade flag is provided, ct install validates that helm test passes for the following upgrade paths:

    1. Previous chart revision $\rightarrow$ current chart version: Only if the change is a non-breaking SemVer change.
    2. Current chart version $\rightarrow$ current chart version.
    ct install [flags]

  6. Install chart-testing (ct)

    main

    You can install ct using several methods depending on your environment:

    Binary Distribution

    1. Download the release distribution for your OS from the GitHub Releases page.
    2. Unpack the ct binary.
    3. Add it to your PATH.

    Docker Image (Recommended)

    Use the official Docker image which comes pre-installed with all necessary tools (Helm, Git 2.17.0+, Yamllint, Yamale, and Kubectl): quay.io/helmpack/chart-testing

    Homebrew

    brew install chart-testing

  7. Run chart testing using Google Cloud Build

    main

    This example demonstrates how to integrate chart-testing into a Google Cloud Build pipeline to lint and test Helm charts.

    Important Note on Git: Because Google Cloud Build ignores the .git directory by default during the build process, you must manually initialize git and add a remote within your build steps to ensure any git-dependent logic in your testing workflow functions correctly.

  8. Use the must-pass-upgrade-install test chart

    main

    The must-pass-upgrade-install chart is a test case designed to verify that a Helm chart can successfully undergo an upgrade process. It is generated using helm create nginx and is intended to validate that the chart passes both install and upgrade operations.

    To simulate an upgrade scenario, a fake "previous revision" is provided at ./ct_prev_revision/must-pass-upgrade-install.

  9. Configure private chart repositories and OCI registries

    main

    You can specify additional arguments for helm repo add using helm-repo-extra-args on a per-repo basis. This is useful for authenticating with private repositories or self-signed certificates. OCI registries are added via helm registry login and also support these extra arguments.

    chart-repos:
  - incubator=https://incubator.io
  - basic-auth=https://private.com
  - ssl-repo=https://self-signed.ca
  - oci-registry=oci://nice-oci-registry.pt
helm-repo-extra-args:
  - ssl-repo=--ca-file ./my-ca.crt

    To pass authentication for a specific repo via CLI:

    ct install --config config.yaml --helm-repo-extra-args "basic-auth=--username user --password secret"

  10. Configure chart-testing (ct) via flags, environment variables, or config files

    main

    The ct tool is a command-line application that supports configuration through three layers. If multiple sources are used, the order of precedence is:

    1. CLI flags (Highest priority)
    2. Environment variables
    3. Config file (Lowest priority)

    Environment Variables

    Environment variables must be prefixed with CT_. Use underscores instead of hyphens (e.g., --chart-dirs becomes CT_CHART_DIRS).

    Config Files

    ct supports any format compatible with Viper, including JSON, TOML, YAML, HCL, and Java properties files.

    If no config file is explicitly specified, ct searches for ct.yaml (or other supported formats) in the following order:

    1. Current directory
    2. $HOME/.ct
    3. /etc/ct

    Linting Configuration

    Linting requires configuration files for yamllint and yamale. If not specified, these are searched in:

    1. Current directory
    2. .ct directory in current directory
    3. $HOME/.ct
    4. /etc/ct

  11. Use ct install with a local repository via Docker

    main

    When running ct install inside a Docker container against local charts, ensure the workdir parameter matches the volume mount path. You must also mount your kubeconfig to allow ct to interact with Kubernetes clusters.

    docker run -it --network host --workdir=/data --volume ~/.kube/config:/root/.kube/config:ro --volume $(pwd):/data quay.io/helmpack/chart-testing:v3.14.0 ct install --chart-dirs . --charts .

  12. Chart testing with CircleCI and kind

    main

    This example demonstrates a workflow for linting and testing Helm charts using CircleCI and kind (Kubernetes in Docker). The setup utilizes kind to spin up a local Kubernetes cluster consisting of a single control-plane node and one worker node.

    To customize the cluster topology, you can modify the test/kind-config.yaml file. For a full list of available configuration options, refer to the official kind documentation.