<img src="https://camo.githubusercontent.com/2a2157c971b7ae1deb8eb095799440551c33dcf61ea3d965d86b496a5a65df55/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f4c6963656e73652d417061636865253230322e302d626c75652e737667" alt="License"
/>
ct is the tool for testing Helm charts. It is intended to be used for linting and testing extraction requests. Automatically detects modified charts in the target branch.
Installation prerequisites
It is recommended to use the provided Docker image that can be found on Quay. It comes with all the necessary tools installed.
- Helm
- Git (2.17.0 or later)
- Yamllint Yamale
- Kubectl
Binary
distribution
Download the version distribution for your operating system from the Versions: https://github.com/helm/chart-testing/releases page
Unzip the ct binary, add it to your PATH and voila!
Image of Docker
A Docker image is available in quay.io/helmpack/chart-testing with a list of tags available here.
Using
Homebrew See the documentation for individual commands
: ct ct install ct lint ct
- lint-and-install
- version
ct modified ct
of ct
For
a more extensive practical guide, see:
- charts-repo-actions-demo
Configuration
ct is a command-line application. All command-line flags can also be set via environment variables or configuration file. Environment variables must be preceded by CT_. Underscores should be used instead of hyphens.
You can mix CLI flags, environment variables, and a configuration file. The following order of priority applies:
- CLI flags Environment variables
Configuration file
Note that linting requires a configuration file for yamllint and yamale. If not specified, these files are searched in the current directory, the .ct directory in the current directory, $HOME/.ct, and /etc/ct, in that order. Samples are provided in the etc. folder.
Examples
The following example shows several ways to configure
the same thing:
CLI
Remote
repository With
remote
repository:
Local repository
If you have a chart in the current directory and ct installed on the host, you can run
:
With docker it works with
: Note that the
workdir parameter is important and must be the same as the mounted volume.
Environment
variable configuration file config.yaml:
Using the
configuration ct
supports any format that Viper can read, i.e. JSON, TOML, YAML, HCL, and Java property files.
Note that if
no configuration file is specified, 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 charts-repositories, you can specify additional arguments for the helm repo add command using helm-repo-extra-args per repo. This could be used, for example, to authenticate a private graphics repository.
config.yaml:
Build from Source
ct compiles with Go 1.13 or higher.
build.sh is used to compile and release the tool. Use Goreleaser under the covers.
Note: On MacOS you will need GNU Coreutils readlink. You can install it
with: Then
add gnubin to your $PATH, with
:
To use the build script:
Launch
Prepare for release
Before you create a version, the versions must be updated in the samples. A pull request must be created for this, which must be merged just before the version is cut. Here’s a previous for reference: #89
Create Release
The release workflow is distributed from github actions Versions should start with a lowercase v, for example, v3.7.1.
Supported versions
The previous MAJOR version
will be supported for three months after each new MAJOR version
.
Within this support window, pull requests for the previous MAJOR version must be made against the previous release branch. For example, if the current version of MAJOR is v2, the pull request base branch must be release-v1.
Upgrading
When upgrading from < v2.0.0, you will also need to change the usage of your scripts. This is because while v2.0.0 has parity with v1, it was refactored from a bash library to Go, so there are slight syntax differences. Compare the use of v1 with the README usage section of this previous release (v2).
