Good to know that you're reading this, as all open source software benefits from contributions by those wanting to collaborate. It might be helpful to outline what is expected here, but also what is already done for you, so you don't have to keep reinventing those wheels ;)
By now we expect you to have fully read our README and maybe looked a bit at the code. You will notice that we use some tooling to enforce consistent commits and releases:
- Commitizen: We use their
cz-cliandcz-conventional-changelog. - Standard Version: Generates CHANGELOG, bumps & releases image (also as git tag).
- Prettier: Almost all code is autoformatted when using vscode (except all the go templates, as these are unstructured by intent).
The bulk of the code in this repo consists of go templates. These are highlighted by the helm plugin, but not auto formatted (as they might contain any kind of code). In order to help you write consistent go templates we have written a special section about go templating.
Please make sure to add all the artifacts from the Definition of Done, which includes possible tests and test data.
- Spec validation of values happens automatically in the values repo by using
otomi commit - Linting of k8s output (manifests) that are generated from the
.demo/env/*input happens in the build pipelines. It tests k8s output from the stack for correct CRs based on their CRDs and OPA rules defined. Therefore it is very important to always add test data that generates all of your templates (to keep up coverage). - Scripting is done in
bash, and these shell scripts are available inbin/*. We use thebatstesting framework as explained in documentation about bats.
Coming soon!
After values are pushed the cluster's drone will do a deployment run. Helmfile diff is used targeting $CLOUD & $CLUSTER before the final deployment of the artifacts.
If you have any meaningful additions to this, please let us know!