* Various U/X improvements for `helmfile apply`
This improves the U/X of `helmfile apply`, by allowing you to selectively apply sub-helmfiles.
When you have two or more sub-helmfiles processed, typing `n` to cancel the first doesn't automatically stop the whole helmfile execution.
Instead, it proceeds by diffing the next sub-helmfile, and asks you to apply it, which should be what the user would expect.
To support this workflow, I have suppressed useless exec logs, correct exit status when diff exists in sub-helmfiles but not in the parent helmfile, and made the final error message emitted by helmfile better.
More concretely, this moves more output from `helm` to STDERR and the `debug` log-level.
The overall output from `helmfile` should be a bit more cleaner especially for `apply`, `sync`, `diff` and perhaps other `helmfile` sub-commands, too.
For example, when one of release failed, `helmfile`'s final error message now includes the error message from the failed `helm` execution, like seen in the last line:
```
List of updated releases :
RELEASE CHART VERSION
envoy stable/envoy 1.5.0
List of releases in error :
RELEASE
envoy2
in ./helmfile.yaml: in .helmfiles[0]: in /Users/c-ykuoka/helmfile/helmfile.1.yaml: failed processing release envoy2: helm exited with status 1:
Error: UPGRADE FAILED: "envoy2" has no deployed releases
```
This way you can better understand what caused helmfile to finally fail.
`helmfile` has been streaminig a lot of stdout and stderr contents from the `helm` commands regardless of the helmfile's log-level. It has been suppressed by default and moved to the `debug` log-level.
You will see that it helps you focus on what was the cause of a failure.
While working on the above, I found an another bug that made `--detailed-exitcode` useless in some case.
That is, `helmfile diff --detailed-exitcode`, when any diff existed only in sub-helmfiles, has been returning an exit code of `1`. It should return `2` when any release had diff and no release had an error, regardless of the target is a sub-helmfile or a parent helmfile. Why? Because that's what `--detailed-exitcode` meant for!
After this PR gets merged, `helmfile diff --detailed-exitcode` propery return exit code `2` in such cases.
Fixes#543Resolves#540
Actually, 4 helm commands including "list", "diff", "status" and "delete" were not taking tiller-rerelated flags into account in helmfile. This fixes all these commands.
Fixes#534
This removes `release: "your_release_name" not found` errors seen for releases with `installed: false` when running `helmfile sync` and `helmfile apply`.
The problem was that helmfile had been running `helm status` to detect releases to be deleted. helmfile now use `helm list ^YOUR_RELEASE_NAME$` to detect if the release is currently installed or not, which emits no error-like logs on against uninstalled releases.
Fixes#507Fixes#507
* Improve code organization
To make sure it is still readable after upcoming changes to helmfile
* feat: `helmfile deps` to update dependencies of all the local charts
Resolves#450
* feat: helmfile updates repos and build deps by default
But not update deps. Use `helmfile deps` to update deps, and provide `--skip-deps` to skip updating repos and builds deps in sync/diff/apply/template
Resolves#415
* Improve integration test coverage
`helmfile template` runs `helm template` over releases within the helmfiles, and provide you a stream of generated yaml documents of Kubernetes resources via stdout.
Resolves#283
`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.