Testkube Cloud Charts is a collection of internal charts.
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests. See the above stated requirements for PR on this project.
We lint the title of your pull request to ensure it follows the Conventional Commits specification. This is done using GitHub actions and the action-semantic-pull-request workflow. We require the scope of the change to be included in the title. The scope should be the name of the chart you are changing. For example, if you are changing the testkube-enterprise
chart, the title of your pull request should be fix(testkube-enterprise): Fix typo in values.yaml
.
The documentation for each chart is generated with helm-docs. This way we can ensure that values are consistent with the chart documentation.
We have a script on the repository which will execute the helm-docs docker container, so that you don't have to worry about downloading the binary etc. Simply execute the script (Bash compatible, might require sudo privileges):
./scripts/helm-docs.sh
Testkube Enterprise includes the Testkube Cloud API and Testkube Cloud UI Helm charts.
On every update to either of the subcharts, the sync script should be executed which makes sure Testkube Enterprise Helm chart is up to date.
./scripts/sync.sh
After the sync script is executed, regenerate the docs by running:
./scripts/helm-docs.sh
Note When creating your own
README.md.gotmpl
, don't forget to add it to your.helmignore
file.
When updating the README.md.gotmpl
inside a chart directory you must to run the helm-docs
script to generate the updated README.md
file. To reiterate, you should not edit the README.md
file manually. It will be generated by the following command:
./scripts/helm-docs.sh
Note If you see changes to unrelated chart
README.md
files you may have accidentally updated aREADME.md.gotmpl
file in another chart's folder unintentionally or someone else failed to run this script. Please revert those changes if you do not intend them to be a part of your pull request.
Each chart's version follows the semver standard.
New charts should start at version 1.0.0
, if it's considered stable. If it isn't considered stable, it must be released as prerelease
.
Any breaking changes to a chart (backwards incompatible) require:
- Bump of the current Major version of the chart
Any other manual change to a chart require:
- Bump of the current Minor version of the chart
When selecting new application versions ensure you make the following changes:
values.yaml
: Bump all instances of the container image versionChart.yaml
: EnsureappVersion
matches the above container image and bumpversion
Please ensure chart version changes adhere to semantic versioning standards:
- Major: Large chart rewrites, major non-backwards compatible or destructive changes
- Minor: New chart functionality (sidecars), major application updates or minor non-backwards compatible changes
- Patch: App version patch updates, backwards compatible optional chart features
Each release for each chart must be immutable. Any change to a chart (even just documentation) requires a version bump. Trying to release the same version twice will result in an error.
Currently, we require a chart version bump for every change to a chart, including updating information for older versions. This may change in the future.
Clean-up:
helm delete testkube-enterprise --purge --namespace enterprise
Pre-requisites:
helm repo add dex https://charts.dexidp.io
helm repo add mongodb https://charts.bitnami.com/bitnami
helm repo add common https://charts.bitnami.com/bitnami
helm repo add nats https://nats-io.github.io/k8s/helm/charts/
helm dependency update
Minimally:
helm install testkube-enterprise ./charts/testkube-enterprise --namespace enterprise --create-namespace
kubectl port-forward service/testkube-cloud-ui --namespace enterprise 8080
As part of the Continuous Integration system we run Helm's Chart Testing tool.
The checks for Chart Testing are stricter than the standard Helm requirements. For example, fields normally considered optional like maintainer
are required in the standard spec and must be valid GitHub usernames.
Linting configuration can be found in ct-lint.yaml
The linting can be invoked manually with the following command:
./scripts/lint.sh
Changes are automatically publish whenever a commit is merged to the main
branch by the CI job (see ./.github/workflows/publish.yml
).