`helmfile lint` works with relative chart reference (#252)
The tempalte function `readFile` accepts the path relative to helmfile.yaml
Resolves#246Fixes#252
Closes#93
Summary of changes:
- Adds the [uber-go-/zap](https://github.com/uber-go/zap) library for leveled logging (69040996e0bcbd2f211d0d8d576147027e928e3b)
- A new CLI arg `--log-level` which can take the values `debug` `info` `warn` `error` `fatal` `panic`. The default is `info`, and the existing `--quiet` flag is treated as `--log-level warn`
- All `helm.exec` calls are preceded by a one-line summary. The current information on the full helm command line arguments `exec: helm exec ... ` is only output at `debug` level. This means sensitive command line arguments which may include passwords and `--set` arguments should be hidden by default.
`helm` may not be version compatible. Add an option to specify an alternative `helm` command on runtime, possibly according to the version of tiller running on your cluster.
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 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.
So that we can just reuse release names after `helmfile delete`.
This is verified to work by confirming that `helmfile delete` does add `--purge` flag to `helm delete`:
```
$ helmfile delete
exec: helm delete --purge brigade-project
release "brigade-project" deleted
```
And by confirming that I can now re-install releases from the same charts.yaml without any modification of release names:
```
PROJECT=deis/empty-testbed ENV=staging IMAGE=mumoshu/golang-k8s-aws:1.9.1 COMMAND='go' SERVICE_ACCOUNT=default helmfile sync
Release "brigade-project" does not exist. Installing it now.
NAME: brigade-project
LAST DEPLOYED: Tue Feb 27 15:59:38 2018
NAMESPACE: kube-system
STATUS: DEPLOYED
RESOURCES:
*snip*
```
Fixes#33
This aims to improve on relative, absolute and <repo>/<chart>
resolution for several of Helmfile manifest attributes as well as
command line arguments.
- Uusers may now utilize the `-f <filepath>` flag to reference
a helmfile manifest outside of their PWD and have relative paths
in the the `charts[*].values` and `charts[*].chart` attribute resolve
relative to the manfiest's location properly
- Values provided in the `--values` argument are no longer automatically
assumed as relative path references from PWD but instead are
conditionally joined with the PWD if it is determined they are relative
file paths
- Users may still signify a chart in the `.charts[*].chart` attribute
as they do now by having an explicit `<repo>/<chart>` value
- Simple copy-paste for the most part from sync job. I had started down
the path of adding in a meta PluginCommand directive and trying to make it
more modular, but in the end there are some small differences between
the execution that were a bit difficult to model and it just got ugly.
Figured keeping it simple would be easier to manage
If the chart is in directory, for example, `./my/chart` the `helmfile -f my.yaml sync` will fail.
This PR will check if the chart starts with `/`, `./` or `../` and will transform it in a full path of the chart directory.