Releases: blendle/kubecrt
v0.9.2
v0.9.1
v0.9.0
v0.8.0
- #13: Auto update repositories when running kubecrt
- #14: Add support for partials in charts.yml
- #15: Better error reporting details to stderr
Partial Templates
You can optionally split your charts.yml
file into multiple chunks, by using
partial templates. This works almost the same way as Helm's support for these
in charts. See the Helm documentation for more details.
To use these partials, you have to set the --partials-dir
flag when calling
kubecrt
, pass it the path to your partials directory, and then use those
partials in your charts.yml
.
Example:
charts.yml:
apiVersion: v1
name: my-bundled-apps
namespace: apps
charts:
- stable/factorio:
values:
resources:
{{ include "factorio/resources" . | indent 8 }}
partials/factorio/resources.yml
{{- define "factorio/resources" -}}
requests:
memory: 1024Mi
cpu: 750m
{{- end -}}
You can then run this as follows:
kubecrt --partials-dir ./partials charts.yml
And the result is a fully-parsed charts printed to stdout.
Some notes:
- you can use subfolders to organise your partials
- each named
define
has to be uniquely named, or risk being overwritten - you can define multiple
define
blocks in a single file - the files don't need to be yaml files, you can use any content you need
v0.7.0
v0.6.1
v0.6.0
v0.5.1
v0.5.0
You can now add repositories to Helms repository index without
defining them in the charts.yml.
This allows you, for example, to always add specific
repositories when executing kubecrt
on your CI server:
kubecrt --repo=myname=https://my-repo-address charts.yaml
apiVersion: v1
charts:
- myname/chart1: {}
- myname/chart2: {}
the above now works, because the myname
repository is already in the index, so you don't have to specify the repo
key for both charts.
v0.4.0
New charts.yml
API format:
note: this new format is incompatible with v0.3.0
old
apiVersion: v1
name: my-bundled-apps
namespace: apps
charts:
# Map instead of list means you can not define the same chart/version
# combination more than once.
#
# Using the `@x.y.z` version notation means versions are always pinned to a
# single version, making upgrades more painful.
stable/[email protected]:
# Having the chart template values live at the top level of the chart
# configuration means no other options can be added.
factorioServer:
name: hello world
# Using non "stable" repository charts (which is always active by default)
# means you have to add the repository first, usign `helm repo add NAME URL`.
opsgoodness/prometheus-operator:
sendAnalytics: false
new
apiVersion: v1
name: my-bundled-apps
namespace: apps
charts:
# Using a list allows duplicate charts with different configuration values.
- stable/factorio:
# Semantic version constraints allows compiling the latest acceptable chart
# version.
version: ~> 0.1.0
# Using a "values" object for chart configuration values allows using more
# chart configuration keys, and makes it more clear that the configuration
# under the "values" key is the same as Helm's "values.yml"
values:
factorioServer:
name: hello world
- opsgoodness/prometheus-operator:
# When using a non-standard repository, you can provide the repository URL,
# to have kubecrt add the repository to Helm's index, before searching for
# the chart.
repo: http://charts.opsgoodness.com
values:
sendAnalytics: false
I chose not to change the apiVersion
as only two internal services are using kubecrt in production so far, and it reduces the overhead of having to maintain two different API versions. I'll update those services manually.