* 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
Fixes#344 by allowing explicit selectors to be specified for composed helmfiles using the following structure
```yaml
helmfiles:
- path: helmfile.d/a*.yaml
selectors:
- name=prometheus
- name!=zipkin
- helmfile.d/b*.yaml
- path: helmfile.d/c*.yaml
selectors: {}
```
2 modes here :
* legacy mode when no the env var HELMFILE_EXPERIMENTAL is not set to true
* no selector : inherit from the command line.
* selector: is specified then it is used (an emty means no inheritance from command line and take everything).
* experimental when the env var HELMFILE_EXPERIMENTAL=true
* no selector : nothing is inherited from the command line so use all releases.
* selector: is specified then it is used (an emty means no inheritance from command line and take everything).
* feat(report): display summary of upgraded, deleted and error releases
* feat(#502): adds dep target in makefile
* feat(#502): removes vendor and fixes pristine in makefile
Since #526, `helmfile apply` have been really able to detect deletion of the last release only, and `sync` has been unable to mark releases with `installed: false` for removal.
Fixes#554
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
* feat: `helmfile destroy` deletes and purges releases
This adds `helmfile destroy` that is basically `helmfile delete --purge`.
I've also tweaked the behavior of `delete` and `destroy` for releases with `installed: false`, so that it becomes consistent with other helmfile commands.
It now delete releases only when `installed: true` AND the release is already installed.
**Why an another command?**
Because it's easy to remember, and it also makes it easier to iterate on your helmfile.
We've been using `helmfile delete` from the beginning of helmfile,
and several months have been passed since we've added `--purge` to it.
We noticed that we always prefer to use `--purge` so that we can quickly iterate on helmfile by
e.g. `helmfile delete --purge && helmfile sync`. But making `--purge` default makes the `delete` command inconsistent with the helm's `delete`.
`destroy`, on the other hand, doesn't have such problem, and is still easy to remember for terraform users.
Resolves#511
* Update docs about `helmfile delete` and `helmfile destroy`
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
Options specified in releases (e.g. `recreatePods`) should override the respective options set in `helmDefaults`. Currently, `helmDefaults` takes precedence.
In the below example, `--force` should not be passed as an additional deployment argument:
```
helmDefaults:
force: true
releases:
- name: example
namespace: example
chart: some/repo
version: ~1.24.1
force: false
```
Fixes#492
* 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 test --concurency N` to set a concurrency number.
It is automatically ceiled at the number of releases just to reduce wasting computing resources.
Also, I've refactored the scatter-gather logic scattered across the code-base.
Resolves#433
This feature is supposed to help advanced use-cases like Conventional Directory Structure explained in several issues like #428.
Newly added configuration keys `templates`, `missingFileHandler`, and the ability to defer executing template expressions in `values`, `secrets`, `namespace`, and `chart` of releases allows you to abstract away repetitions into a reusable template:
```yaml
templates:
default: &default
missingFileHandler: Warn
namespace: "{{`{{ .Release.Name }}`}}"
chart: stable/{{`{{ .Release.Name }}`}}
values:
- config/{{`{{ .Release.Name }}`}}/values.yaml
- config/{{`{{ .Release.Name }}`}}/{{`{{ .Environment.Name }}`}}.yaml
secrets:
- config/{{`{{ .Release.Name }}`}}/secrets.yaml
- config/{{`{{ .Release.Name }}`}}/{{`{{ .Environment.Name }}`}}-secrets.yaml
releases:
- name: envoy
<<: *default
```
See the updated documentation for more details.
Resolves#428
fixes https://github.com/roboll/helmfile/issues/412
the `apply` command first runs the `diff` command, which triggers the execution of the `cleanup` hooks at the end of the `diff`.
Prevents helmfile from consuming unnecessarily much time in running `helm repo update` over and over.
helmfile now marks which repository was updated, and skip second and further `helm repo update` when all the `repositories` found in a helmfile.yaml was marked as already updated.
Let's say you had two helmfiles, the first one with repositories `foo` and `bar`, an the second one with only `bar`. `helmfile repos` will run `helm update repo` for the first helmfile, marking `foo` and `bar` as already updated. The second helmfile.yaml contains only `bar`, which is marked as already updated. So helmfile won't run `helm repo update` for the second.
This applies to all the helmfile command that results in `helm repo update`, like `repos`, `sync`, `diff` and so on.
Resolves#335
This allows using the environment values defined in the environments: section of helmfile.yaml to be used from other sections of the file.
This works by having two template renderers, the first-pass and the second-pass renderer.
The first-pass render renders a helmfile.yaml template with replacing template functions has side-effects with noop. So, use only funcs that don't have side-effects to compose your environment values.
Then the second-pass renderer renders the same helmfile.yaml template, but with the environment values loaded by the first-pass renderer.
The implementation uses a buffer instead of re-reading the file twice.
Resolves#297
This enables `helmfile lint` and `helmfile template` commands to fetch and untar all the required charts concurrently. The concurrency is configurable via the `--concurrency` flag, that defaults to `0`.
Ref #292
Enhance the `diff` functionality to be able to return affected releases that has any changes,
so that the succeeding `sync` can be run against only the affected releases.
This provides us extra idempotency.
Resolves#277
Yusuke KUOKA
Raj Perera
sgandon
Patrick Valsecchi
Mike Eves
Shane Starcher
Vincent Behar
Hung Tran Duc
Eric Chin
Anatoly Rugalev
Terry Corley
David Genest
Karl Stoney