Helm charts for the Brigade project.

This Brigade project accepts contributions via GitHub pull requests. This section outlines the process to help get your contribution accepted.

Do not include changes to the version field of any chart's Chart.yaml file in your PRs. This field is set automatically through this project's release process.

A DCO sign-off is required for contributions to repos in the brigadecore org. See the documentation in Brigade's Contributing guide for how this is done.

Experience has demonstrated that automatically publishing updated charts upon every merge to the master branch while simmultaneously respecting the immutability of existing (i.e. previously published), semantically versioned charts can be challenging. In such a scheme, every PR effectively represents a release, which then requires the version field to be appropriately incremented in the Chart.yaml file of any chart modified by a given PR. This requirement promotes race conditions dependent on the order in which PRs are merged and is onerous both for contributors to comply with and for maintainers to enforce. A particularly undesirable consequence of mis-managing this requirement (i.e. forgetting to increment the version number) is that an existing (i.e. previously published), semantically versioned chart may be overwritten violating any reasonable expectation of its immutability. These challenges aside, such a scheme is also inflexible, as it prevents maintainers from arbitrarily grouping multiple discrete changes to a single chart into a single release.

For the reasons stated above, the maintainers have elected not to continuously publish the charts in this repository. Instead, as is common for many projects (though less common for chart projects), releases are facilitated through the application of git tags to a specific commit.

Since this repository contains the source code for multiple charts which are versioned independently of one another, the tags that are applied to effect releases must include not only the semantic version we wish to assign to the release, but must also contain the name of the chart which is to be released (published). Tags therefore take the form <chart name>-v<semantic version>.

To effect the release of Kashti 1.0.0 from the head of the master branch, for example:

$ git checkout master
$ git pull upstream master
$ git tag kashti-v1.0.0
$ git push upstream --tags

Note that only a project maintainer is able to perform the steps above.

Note also that the semantic version extracted from the tag will be automatically inserted into the version field of the indicated chart's Chart.yaml file when the chart is packaged for release. Effectively, this absolves contributors and maintainers from ever manually modifying that field, however, it does require that maintainers conducting a release take great care to be aware of what the latest release of a given chart was and whether the changes staged for release necessitate incrementing the major, minor, or patch components of the previous version to arrive at the new version.

Maintainers might utilize a workflow such as that shown below to facilitate a release. Here, we imagine a scenario where the most recent release of the Kashti chart was semantically versioned 1.1.0 and the maintainer is aware that the release they are conducting contains new features, but no breaking changes:

$ helm repo up
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "brigade" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈ 
$ helm search kashti
NAME          	CHART VERSION	APP VERSION	DESCRIPTION                
brigade/kashti	1.1.0        	           	A Helm chart for Kashti
$ git checkout master
$ git pull upstream master
$ git tag kashti-v1.2.0
$ git push upstream --tags