Introducing the Helm Org Maintainers

4 Oct 2018

The first major action under the new Helm governance was to elect a set of Helm Org Maintainers. In the initial election we were looking to select 7 people to represent Helm core, charts, and other projects under the Helm umbrella. The election is now complete and I would like to introduce the first set of Org Maintainers.

In alphabetical order, by first name, they are:

  • Adam Reese (adamreese)
  • Adnan Abdulhussein (prydonius)
  • Matt Butcher (technosophos)
  • Matt Farina (mattfarina)
  • Matt Fisher (bacongobbler)
  • Reinhard Nägele (unguiculus)
  • Vic Iglesias (viglesiasce)

Thanks to everyone who ran. Helm is off to a great start under the CNCF and this is another step in our journey.

What Do Org Maintainers Do?

Org Maintainers are responsible for maintaining the vision, mission, values, and scope of the broader Helm project. This includes the Helm client, the charts repository, ChartMuseum, and Monocular. While the org maintainers are not responsible for the technical direction of each individual project, they take on the higher level task of keeping the organization unified.

- Matt Farina & Matt Butcher

Using the Community Chart Testing Tools Yourself

25 Sep 2018

The Helm community charts, available as the stable and incubator repositories, have long had testing. That testing has grown and improved a significant amount in the past year; from Helm linting and testing if an application runs in a cluster to now include YAML linting, some validation on maintainers, Chart.yaml schema validation, tests on chart version increments, and more.

These testing tools are useful for more than the community charts. They could be used in development workflows, in other testing systems, and for private charts. To make the testing more accessible we (mostly Reinhard Nägele) refactored the tools into a container image that can be run outside of the community charts testing infrastructure.

This new image is now available as the Chart Testing project. This project is built and maintained by the Helm Charts Maintainers, powers the community chart testing process, and is being used elsewhere.

Example: Locally on Mac

One of the easiest ways to take a look at it is to try it out locally. To aid with that, one of the examples provided by the project shows you how to use it with Docker for Mac with the charts repository. An easy way to try it out is to make a change to a chart and run the following command from the root of the charts directory:

$ /path/to/chart-testing/examples/docker-for-mac/

To illustrate this I added a tag in the Chart.yaml file of the mariadb chart without incrementing the chart version. Running the test produced the following output:

Cluster "docker-for-desktop-cluster" set.
Cluster "docker-for-desktop-cluster" set.
Switched to context "docker-for-desktop".

CHART_DIRS=stable incubator

Charts to be installed and tested: stable/mariadb
Initializing Helm client...
Creating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL:
Adding local repo with URL:
$HELM_HOME has been configured at /root/.helm.
Not installing Tiller due to 'client-only' flag having been set
Happy Helming!
"incubator" has been added to your repositories

Processing chart 'stable/mariadb'...

Validating chart 'stable/mariadb'...
Checking chart 'stable/mariadb' for a version bump...
Chart version on k8s/master : 5.0.3
New chart version:  5.0.3
ERROR: Chart version not ok. Needs a version bump.
Linting 'stable/mariadb/Chart.yaml'...
Linting 'stable/mariadb/values.yaml'...
Validating Chart.yaml
Validating /workdir/stable/mariadb/Chart.yaml...
Validation success! 👍
Validating maintainers
Verifying maintainer 'bitnami-bot'...
ERROR: Chart validation failed.
Building dependencies for chart 'stable/mariadb'...
No requirements found in stable/mariadb/charts.
Chart does not provide test values. Using defaults...
Linting chart 'stable/mariadb'...
==> Linting stable/mariadb
Lint OK

1 chart(s) linted, no failures
✖︎ stable/mariadb

You’ll notice the chart failed to pass testing because the version was not incremented.


While the testing image contains defaults, it is configurable so it can be used without any association to the community charts setup. The configuration is handled via environment variables which are documented in the file.

For example, if you wanted to skip checking for a version increment on the chart for every change you can set CHECK_VERSION_INCREMENT to false. This will skip that check and is useful for cases where every change to a chart is not released.

Example: Using It with CircleCI

Linting, without trying to operate the chart, is easy to incorporate into a workflow. The following is a simple example CircleCI configuration to do so:

version: 2
      - image:
      - checkout
      - run:
          name: lint
          command: |
   --config .testenv --no-install
  version: 2
      - lint-charts

In this case the environment variables for the configuration are stored in a file name .testenv. This file holds the environment variables and is sourced into the environment. The following is an example from the community charts:

# The name of the Git remote

# The name of the Git target branch

# Chart directories separated by a space

# Charts that should be skipped

# Additional chart repos to add (<name>=<url>), separated by a space


Try It in Your Workflow

This toolchain, wrapped in a container image, is meant to be used in a wide variety of workflows. Please take it for a spin, give it a try, use it in your workflows, and provide feedback.

- Matt Farina

New Governance And Elections

7 Sep 2018

Being a top level incubating CNCF project requires having a governance structure to ensure that there is a publicly documented process for making decisions regarding the project and the community. While Helm was under Kubernetes, we relied on Kubernetes governance. As part of the transition to CNCF, the Helm project is required to have its own governance structure. To handle this we set up a provisional governance with a goal of creating a long term one. After a few months we are happy to announce that the new governance structure as been written and approved.

The gist of the new governance is that it organizes those responsible into a couple groups (org and project maintainers), spells out their responsibilities, and provides for decision making processes. You can read all the details in the governance doc (here).

Two Types of Maintainers

The new governance has two types of maintainers. Project Maintainers are those who maintain the code, documentation, websites, and so forth. There are currently several groups of maintainers for Helm core, Charts, ChartMuseum, Monocular, and Web/Docs. These are the same people who have been maintaining this work.

The second type of maintainer is the Helm Org Maintainer. These individuals are responsible for elements such as the scope, vision, brand, code of conduct, owning security issues, finances, and other aspects of this nature.

Next Step: Selecting Helm Org Maintainers

The next step in the process is to select the initial Helm Org Maintainers. To handle this selection we are using the documented process in the governance. Anyone who has contributed to the Helm GitHub organization can nominate one of the Project Maintainers to be a Helm Org Maintainer. This includes the Project Maintainers of Helm core, Charts, ChartMuseum, etc. The nomination period will be open for three weeks (closing on 9/28 at 12pm PT). We wanted Helm Org Maintainers to be project maintainers so that they have shown they are vested in Helm by their actions.

After that the project maintainers will vote. How that vote works will depend on the number of nominated individuals, who they work for as no one company can have a majority of members, and some other rules.

To provide for a diverse representation from the projects in the initial selection of Helm Org Maintainers the selected folks will include 3 Representatives from the Helm core project, 2 Representative from the Charts project, and 2 Representatives representing another Helm project. The initial election will create a total of 7 Helm Org Maintainers. The length of their terms is open ended and how changes happen is documented in the governance.

If you have questions about the process, or how to nominate someone, please use the Helm mailing list.

- Matt Farina

Helm Moves To DCO

27 Aug 2018

When Helm was part of the Kubernetes project it, like the rest of Kubernetes, used the CNCF Contributor License Agreement (CLA). This served Helm well for years. But, most of the CNCF projects use a Developers Certificate of Origin (DCO) instead of a CLA. The exceptions are Kubernetes and gRPC. Upon Helm becoming a CNCF project itself we were asked if we wanted to move Helm to a DCO. After some careful consideration and a little research, the Helm maintainers voted to move to a DCO.

What Does This Solve? Why Switch?

Making a change like this should have a good reason and we have one. It is often easier to get started contributing under a DCO than a CLA.

When one is developing software for a company they need to have the company sign the Corporate CLA prior to submitting contributions. That means there is a step after the business decides to contribute where legal documents need to be signed and exchanged. Once this is done there are steps to associate people with those legal documents. All of this takes time. In some companies this process can take weeks or longer.

We wanted to make it simpler to contribute.

What Is A DCO?

A DCO is lightweight way for a developer to certify that they wrote or otherwise have the right to submit code or documentation to a project. The way a developer does this is by adding a Signed-off-by line to a commit. When they do this they are agreeing to the DCO.

The full text of the DCO can be found at It reads:

Developer Certificate of Origin Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Developer’s Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

An example signed commit message might look like:

An example commit message

Signed-off-by: Some Developer [email protected]

Git has a flag that can sign a commit for you. An example using it is:

$ git commit -s -m 'An example commit message'

In the past, once someone wanted to contribute they needed to go through the CLA process first. Now they just need to signoff on the commit.


What About Existing Pull Requests Under The CLA

If a pull request was previously submitted under the CLA we will still honor those. All new contributions will need to be under the DCO and any pull requests that are updated will need to conform to the DCO prior to merging.

What About The Other Elements Of A CLA

The CNCF CLA has provisions for some areas other than right to contribute the code. For example, there is an explicit patent grant and that the contribution is “on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND”. The CNCF views elements like these as already being covered elsewhere. For example, through the code contributions being under the Apache 2 license which has patent grant and warranty clauses.

What About Commits With Multiple Contributors

If more than one person works on something it’s possible for more than one person to sign off on it. For example,

An example commit message

Signed-off-by: Some Developer [email protected] Signed-off-by: Another Developer [email protected]

If I Contribute As An Employee Does My Employer Need To Sign Anything

Nope. The DCO assumes you are authorized to submit the code. This is what makes the contributor experience simpler for many people.

What If I Forget To Sign-off On A Commit

There is a DCO check, similar to the previous CLA check, that will cause the status of the pull requests to be listed as failed. This will remind everyone that the commit was not signed off.

To update the last commit message with a sign off you can use the command:

$ git commit --amend -s

The -s flag is short for --signoff.

If you need to amend older commit message the process is a little more detailed. GitHub has a writeup detailing on changing commit messages that deals with numerous different cases.

- Matt Farina

Helm is supported by and built with a community of over 250 developers.

Microsoft Google Codefresh Bitnami Ticketmaster codecentric AG

...and many other wonderful helm and charts core maintainers.