ct is the tool for testing Helm charts.
It is meant to be used for linting and testing pull requests.
It automatically detects charts changed against the target branch.
Installation
Prerequisites
It is recommended to use the provided Docker image which can be found on Quay.
It comes with all necessary tools installed.
ct is a command-line application.
All command-line flags can also be set via environment variables or config file.
Environment variables must be prefixed with CT_.
Underscores must be used instead of hyphens.
CLI flags, environment variables, and a config file can be mixed.
The following order of precedence applies:
CLI flags
Environment variables
Config file
Note that linting requires config file for yamllint and yamale.
If not specified, these files are search in the current directory, the .ct directory in current directory, $HOME/.ct, and /etc/ct, in that order.
Samples are provided in the etc folder.
Examples
The following example show various way of configuring the same thing:
ct supports any format Viper can read, i. e. JSON, TOML, YAML, HCL, and Java properties files.
Notice that if no config file is specified, then ct.yaml (or any of the supported formats) is loaded from the current directory, $HOME/.ct, or /etc/ct, in that order, if found.
Using private chart repositories
When adding chart-repos you can specify additional arguments for the helm repo add command using helm-repo-extra-args on a per-repo basis.
You can also specify OCI registries which will be added using the helm registry login command, they also support the helm-repo-extra-args for authentication.
This could for example be used to authenticate a private chart repository.
$ ./build.sh -h
Usage: build.sh <options>
Build ct using Goreleaser.
-h, --help Display help
-d, --debug Display verbose output and run Goreleaser with --debug
-r, --release Create a release using Goreleaser. This includes the creation
of a GitHub release and building and pushing the Docker image.
If this flag is not specified, Goreleaser is run with --snapshot
Releasing
Prepare Release
Before a release is created, versions have to be updated in the examples.
A pull request needs to be created for this, which should be merged right before the release is cut.
Here’s a previous one for reference: https://github.com/helm/chart-testing/pull/89
The previous MAJOR version will be supported for three months after each new MAJOR release.
Within this support window, pull requests for the previous MAJOR version should be made against the previous release branch.
For example, if the current MAJOR version is v2, the pull request base branch should be release-v1.
Upgrading
When upgrading from < v2.0.0 you will also need to change the usage in your scripts.
This is because, while the v2.0.0 release has parity with v1, it was refactored from a bash library to Go so there are minor syntax differences.
Compare v1 usage with this (v2) version’s README usage section above.
Chart Testing
ctis the tool for testing Helm charts. It is meant to be used for linting and testing pull requests. It automatically detects charts changed against the target branch.Installation
Prerequisites
It is recommended to use the provided Docker image which can be found on Quay. It comes with all necessary tools installed.
Binary Distribution
Download the release distribution for your OS from the Releases page:
https://github.com/helm/chart-testing/releases
Unpack the
ctbinary, add it to your PATH, and you are good to go!Docker Image
A Docker image is available at
quay.io/helmpack/chart-testingwith list of available tags here.Homebrew
Usage
See documentation for individual commands:
For a more extensive how-to guide, please see:
Configuration
ctis a command-line application. All command-line flags can also be set via environment variables or config file. Environment variables must be prefixed withCT_. Underscores must be used instead of hyphens.CLI flags, environment variables, and a config file can be mixed. The following order of precedence applies:
Note that linting requires config file for yamllint and yamale. If not specified, these files are search in the current directory, the
.ctdirectory in current directory,$HOME/.ct, and/etc/ct, in that order. Samples are provided in the etc folder.Examples
The following example show various way of configuring the same thing:
CLI
Remote repo
With remote repo:
Local repo
If you have a chart in current directory and ct installed on the host then you can run:
With docker it works with:
Notice that
workdirparam is important and must be the same as volume mounted.Environment Variables
Config File
config.yaml:Config Usage
ctsupports any format Viper can read, i. e. JSON, TOML, YAML, HCL, and Java properties files.Notice that if no config file is specified, then
ct.yaml(or any of the supported formats) is loaded from the current directory,$HOME/.ct, or/etc/ct, in that order, if found.Using private chart repositories
When adding chart-repos you can specify additional arguments for the
helm repo addcommand usinghelm-repo-extra-argson a per-repo basis. You can also specify OCI registries which will be added using thehelm registry logincommand, they also support thehelm-repo-extra-argsfor authentication. This could for example be used to authenticate a private chart repository.config.yaml:Building from Source
ctis built using Go 1.13 or higher.build.shis used to build and release the tool. It uses Goreleaser under the covers.Note: on MacOS you will need
GNU Coreutils readlink. You can install it with:Then add
gnubinto your$PATH, with:To use the build script:
Releasing
Prepare Release
Before a release is created, versions have to be updated in the examples. A pull request needs to be created for this, which should be merged right before the release is cut. Here’s a previous one for reference: https://github.com/helm/chart-testing/pull/89
Create Release
The release workflow is dispatched from github actions Versions must start with a lower-case
v, e. g.v3.14.0.Supported versions
The previous MAJOR version will be supported for three months after each new MAJOR release.
Within this support window, pull requests for the previous MAJOR version should be made against the previous release branch. For example, if the current MAJOR version is
v2, the pull request base branch should berelease-v1.Upgrading
When upgrading from
< v2.0.0you will also need to change the usage in your scripts. This is because, while the v2.0.0 release has parity withv1, it was refactored from a bash library to Go so there are minor syntax differences. Compare v1 usage with this (v2) version’s README usage section above.