Skip to content
This repository has been archived by the owner on Jun 1, 2022. It is now read-only.

brigadecore/charts

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

⚠️  This repo contains Helm charts for components of the Brigade v1.x ecosystem. Brigade v1.x reached end-of-life on June 1, 2022 and as a result, this repository is no longer maintained.

Note that each Brigade v2.x-compatible component now keeps its chart source with the rest of its source code and uses OCI registries to host the charts.

Brigade Charts

Helm charts for the Brigade project.

Note: the charts in this repo are for Brigade v1. For Brigade v2 charts, see the charts directory in the v2 branch of the main brigadecore/brigade repository.

Contributing Guidelines

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

Versioning

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.

Signed commits

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.

Release Process

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