This guide explains how to set up your environment for developing on Helm.
- The latest version of Go
- A Kubernetes cluster w/ kubectl (optional)
We use Make to build our programs. The simplest way to get started is:
NOTE: This will fail if not running from the path
helm.sh should not be a symlink or
build will not find the
If required, this will first install dependencies, rebuild the
and validate configuration. It will then compile
helm and place it in
To run Helm locally, you can run
- Helm is known to run on macOS and most Linux distributions, including Alpine.
To run all the tests (without running the tests for
As a pre-requisite, you would need to have
We welcome contributions. This project has set up some guidelines in order to ensure that (a) code quality remains high, (b) the project remains consistent, and (c) contributions follow the open source legal requirements. Our intent is not to burden contributors, but to build elegant and high-quality open source code so that our users will benefit.
Make sure you have read and understood the main CONTRIBUTING guide:
Structure of the Code
The code for the Helm project is organized as follows:
- The individual programs are located in
cmd/. Code inside of
cmd/is not designed for library re-use.
- Shared libraries are stored in
scripts/directory contains a number of utility scripts. Most of these are used by the CI/CD pipeline.
Go dependency management is in flux, and it is likely to change during the
course of Helm's lifecycle. We encourage developers to not try to manually
manage dependencies. Instead, we suggest relying upon the project's
to do that for you. With Helm 3, it is recommended that you are on Go version
1.13 or later.
Since Helm 3, documentation has been moved to its own repository. When writing new features, please write accompanying documentation and submit it to the helm-www repository.
Helm CLI output (in English) is
generated from the
helm binary itself. See
Updating the Helm CLI Reference Docs
for instructions on how to generate this output. When translated, the CLI
output is not generated and can be found in
We use Git for our version control system. The
master branch is the home of
the current development candidate. Releases are tagged.
We accept changes to the code via GitHub Pull Requests (PRs). One workflow for doing this is as follows:
- Go to your
mkdir helm.sh; cd helm.shand
- Fork that repository into your GitHub account
- Add your repository as a remote for
- Create a new working branch (
git checkout -b feat/my-feature) and do your work on that branch.
- When you are ready for us to review, push your branch to GitHub, and then open a new pull request with us.
For Git commit messages, we follow the Semantic Commit Messages:
fix(helm): add --foo flag to 'helm install' When 'helm install --foo bar' is run, this will print "foo" in the output regardless of the outcome of the installation. Closes #1234
Common commit types:
- fix: Fix a bug or error
- feat: Add a new feature
- docs: Change documentation
- test: Improve testing
- ref: refactor existing code
- helm: The Helm CLI
- pkg/lint: The lint package. Follow a similar convention for any package
*: two or more scopes
- The Deis Guidelines were the inspiration for this section.
- Karma Runner defines the semantic commit message idea.
We follow the Go coding style standards very closely. Typically, running
go fmt will make your code beautiful for you.
We also typically follow the conventions recommended by
go lint and
make test-style to test the style conformance.
If you run the
make test target, not only will unit tests be run, but so will
style tests. If the
make test target fails, even for stylistic reasons, your
PR will not be considered ready for merging.