The use case is to have a list of helmfile releases version controlled together with all settings and have a CI pipeline that will lint all releases with settings before running sync. The new functionality was mostly copy pasted from the Diff implementation with some extra handling for fetching remote charts.
Notes:
* Added release name to chart path to avoid potential race condition when fetching the chart
**Feature**
An additional sub-command to the helmfile binary; helmfile test
**Why**
Helm provides helm test (https://github.com/kubernetes/helm/blob/master/docs/chart_tests.md) as a method to run automated tests post chart install to ensure things are working as they should be.
It would be nice to be able to run something like helmfile test against a particular helmfile in order to run helm tests against all charts/releases defined in the file. Either as part of the sync (i.e. helmfile sync --test) to be ran immediately after the corresponding chart is installed, or as a separate command ran after a sync (i.e. helmfile test).
A chart without tests will exit with a 0 status, so it can be safely ran against any charts.
**Notes**
`--cleanup` (bool) & `--timeout` (default: 300) are available as first class arguments. Additional arguments can be passed to the helm binary as with other sub commands using `--args=`
Resolves#144
`helmfile delete` has been implying `--purge` but it is not the case since this change.
The new behavior is `helmfile delete --purge` to actually purge releases.
Run just `helmfile delete` to delete releases but not purge them.
Resolves#71
This adds `releases[].labels` in which you can set arbitrary number of key-value pairs, so that commands like `helmfile sync --selector key=value` can be used to run the helmfile subcommand against a subnet of declared releases.
`labels` and `selector` are named as such on purpose of being consistent with terminology of Kubernetes and other tools in the K8S ecosystem, including kubectl, stern, helm, and so on.
Resolves#8
So that our user can start leveraging helmfile without too much confusion.
Includes two things:
- A "getting started" guide
- A basic description of the `sync` subcommand
This is important for deployments where the chart repo is protected by client cert validation.
helmfile.yaml is extended to support `certFile` and `keyFile`:
```
repositories:
- name: roboll
url: http://roboll.io/charts
certFile: optional_client_cert
keyFile: optional_client_key
```
Everything works the same if you don't provide values for them.
Regarding the implementation, the "helm repo add" command already supports the cert-file and key-file values, so we just have to pass them through.