Probably this has been affecting strategicMergePatches and dependencies as well, as the source of the problem is the underlying common feature called helm-x that previsouly used `helm template --output-dir`, which turned out to be not working as intended.
Ref #1279
A kustomization has not been properly chartified when a kustomization is specified on `releases[].chart` but there were no `releases[].strategicMergePatches` and `jsonPatches` specified.
This fixes that.
This is the GA version of the helm-x integration #673 developed last year.
You get all the following benefits without an extra helm plugin:
- Ability to add ad-hoc chart dependencies/aliases, without forking the chart (Fixes#876 )
- Ability to patch resulting K8s resources before installing the helm chart
- Ability to install a kustomization as a chart (Requires `kustomize` binary to be available in `$PATH`
- Ability to install a directory of K8s manifests as a chart
- etc.
Fixes https://github.com/roboll/helmfile/issues/1142
desired_state_file_loader.go
- Will now normalize the content before splitting it to parts
context:
Me & and a fellow dev have tried to figure out why helmfile didn't fill in certain values on his machine;
turns out, he'd mistakenly checked out our project w/ CRLF line endings, which had caused part splitting to not work (as it's hard coded to look for '\n').
The following was acted on as a single part, causing values from the bases not to be available in the next yaml part:
```
bases:\r\n
- base.yaml\r\n
---\r\n
releases:
- name: external-secrets-crd
... some templated yaml ...
```
I've thought about regex-ing it out instead of replace-all, but benchmarks had shown that a plain replace is faster.
I've also considered splitting by "\n---" instead of "\n---", but that would break if the dashes were to continue with some other text.
This prevents typos in helmfiles from silently preventing operations
from running. The default behavior is to print a warning, to preserve
backwards compatibility.
Resolves#1232
CHANGES:
* Disable repo update when installed is false
When install is false, we do not need to update the repositories and get
the chart.
Signed-off-by: Guillaume Perrin <guillaume28.perrin@gmail.com>
- createNamespace is a new attribute that can be added to helmDefaults
or an individual release to enforce the creation of a release namespace
during sync if the namespace does not exist. This leverages helm's
(3.2+) --create-namespace flag for the install/upgrade command. If
running helm < 3.2, the createNamespace attribute has no effect.
Resolves#891Resolves#1140
* feat(tmpl): added fetchSecretValue template function
This adds a tmpl `fetchSecretValue` and `expandSecretRefs` function by:
- Adding:
- `expandSecretRefs` function in tmpl package that uses vals
package to fetch secrets
- `fetchSecretValue` function in tmpl package like below but for
single string value
- gomock for tests purpose
- Changing:
- move init of vals package to function (so the same instance can be used for template values and rendering the whole template)
* doc(secret): added doc how to use new tmpl methods
Added example usage of `fetchSecretValue` and `expandSecretRefs`
* New output flag for list command
Support output as json
Add new formatters file to handle extrac formatting to its own concern
New config interface to support list command specification
* Fix usage message
* Add error handling for formatters
This commit proposes a potential solution for
https://github.com/roboll/helmfile/issues/1201
The gist is that, if prestate rendering fails, for any reason,
we do not populate the .Values in the second pass renderer.
I think that what have been expected in this case is to populate the
.Values irregardless.
pkg/app/two_pass_renderer.go
- Migrated to use finalEnv.GetMergedValues()
pkg/environment/environment.go
- Introduced GetMergedValues, which merges the environment's defaults
and current values, and then casts the keys to string;
This was previously defined in HelmState.Values() - however, as this
method is only concerned with the environment, I think it's more
appropriate for it to sit here.
pkg/state/state_exec_tmpl.go
- Extracted out HelmState.Values() to environment.go, see above
since mergo had been bumped to 0.3.9 an environment value like:
```
affinity: {}
```
was not merged properly (not merged at all) instead it threw an error
that it cannot find the key "affinity" in the environment values even
though it was outputted in debug output as read in properly.
Enhances Helmfile to print more helpful message on error while calling `exec` template function.
Helmfile has been printing error messages like the below:
```
in ./helmfile.yaml: error during helmfile.yaml.part.0 parsing: template: stringTemplate:5:8: executing "stringTemplate" at <exec "./exectest.sha" (list)>: error calling exec: exit status 1
```
Adding captured stdout and stderr, with some indentation to make it readable, it now produces the following message on missing executable:
```
$ make build && ./helmfile build
go build
in ./helmfile.yaml: error during helmfile.yaml.part.0 parsing: template: stringTemplate:5:8: executing "stringTemplate" at <exec "./exectest.sha" (list)>: error calling exec: fork/exec ./exectest.sha: no such file or directory
COMMAND:
./exectest.sha
ERROR:
fork/exec ./exectest.sha: no such file or directory
```
On non-zero exit status without output:
```
$ make build && ./helmfile build
go build
in ./helmfile.yaml: error during helmfile.yaml.part.0 parsing: template: stringTemplate:5:8: executing "stringTemplate" at <exec "./exectest.sh" (list)>: error calling exec: exit status 1
COMMAND:
./exectest.sh
ERROR:
exit status 1
```
On non-zero exit status with output:
```
$ make build && ./helmfile build
go build
in ./helmfile.yaml: error during helmfile.yaml.part.0 parsing: template: stringTemplate:5:8: executing "stringTemplate" at <exec "./exectest.sh" (list)>: error calling exec: exit status 2
COMMAND:
./exectest.sh
ERROR:
exit status 2
COMBINED OUTPUT:
out1
err1
```
Resolves#1158
`--retain-values-files` prevents temporary values files that were passed to Helm commands run by Helmfile for debugging purpose.
With that, you can manually rerun helm commands that were logged when `--log-level=debug` is enabled.
Resolves ##1117
* Add option to suppress diff on apply
Add --supress-diff option on apply. Usable for fresh installs when a
lot of output is produces by diff.
Resolves#458
* fix tests for suppress-diff
When chart is not set, an exception without any hints occure due
normalizeChart tries to access the first character of a 0 length string.
Properly inform user of missing chart.
This makes it possible to pass the API Capabilities to helmfile when executing a task that does not render against an actual cluster (diff, template, apply).
Resolves#1014
Adds support for indexed key arguments and escaped dot arguments to `--state-values-set`.
Things like `--state-values-set config\.yml.something=abc` or `--state-values-set config.something[0]=abc` can be passed in the command line.
Resolves#899
It looks like during the beta phase the testing functionality was tweaked / changed back during the beta phase but has since been returned back to how it worked originally.
RE: a6f4bc1bc0
Signed-off-by: Jake Hill <jake@naphta.uk>
When helmfile is run with `--environment NAME` and there was a base hemlfile that misses `environments`, helmfile had been trying to load env values for NAME and failing.
A base helmfile is allowed to reference values from within itself, but that's optional. In other words, a base helmfile that misses the env is okay as long as it doesn't self-reference env values.
So, this change allows missing env and env values while loading base helmfile. After loading, a base helmfile can fail due to referencing missing env values, but that's okay.
Fixes#1008
Those are not actually random but would have looked like so. We use an external go pkg `variantdev/vals` to expand urls like `ref+vault://foo/bar` contained in release values into their respective secret values.
There was a bug in `vals` that it tries to expand unintended types of strings which resulted in confusing errors like reported in #973.
`vals` fixed the issue in ba4c7a2987. This commit upgrades `vals` to accomodate that.
Fixes#973
Runs `helm version` in helmexec.New, and exposes a method on Interface to allow other packages to use the detected version. Preserves compatibility with previous HELMFILE_HELM3 mechanism.
Resolves#923
* Fix regression since 0.90.0 that Helmfile becomes too slow when there are many releases
Fixes#959
* Ensure that the up-to-date helm-diff is installed and used in integration tests
The problem was that `--namespace NS` had been not taken into account while deleting releases, that resulted in releases that should be deleted are not deleted.
The recent addition of the DAG support(`needs`) and the fixes on it broke the delete-on-sync functionality. And there were two more bugs. One is that it was not correctly running `helm delete` when needed and the another is that it was failing when `--selector` is specified and the releases to delete by sync found, but nothing actually got deleted. This fixes all of them.
Fixes#941
This ports the fix for `helfmile apply` to `sync`, so that specifying `--selector` doesn't break `helmfile sync`.
Also make `helmfile template` DAG-aware, so that the manifests are rendered in the order of dependency.
Ref #919
`helmfile delete` is designed to be idempotent. That is, it is safe to be run when there is nothing to delete. A change in helm v3 broke that behavior. This enhances Helmfile to be able to behave the same for helm v2 and v3.
Until now `helmfile delete` with helm v3 had been failing when `--namespace` is provided. Helmfile was missing the fact that in helm v3 namespace must be passed instead of tiller-namespace to scope releases to be deleted.
```
err: release "b-1" failed: helm3rc2 exited with status 1:
Error: uninstall: Release not loaded: b-1: release: not found
in ./helmfile.yaml: release "b-1" failed: helm3rc2 exited with status 1:
Error: uninstall: Release not loaded: b-1: release: not found
```
This overrides the default helm command, if provided, as soon as possible.
This way it is already used in `visitStates`.
I ran into an issue using `HELM3` and `--helm-binary` together with helm-secrets.
I previously used tillerless, which i could now remove. This however caused `DecryptSecret` to fail, as it would still use the helm2 binary; because it runs before the first `helm.SetHelmBinary` call.
While helm-secrets is not fully helm3 compatible yet, its uses within helmfile are, and i was able to just install it as a helm3 plugin.
* fix: Fix `needs` to work for upgrades and when selectors are provided
Fixes#919
* Add test framework for `helmfile apply`
* Various enhancements and fixes to the DAG support
- Make the order of upgrades/deletes more deterministic for testability
- Fix the test framework so that we can validate log outputs and errors
- Add more test cases for `helmfile apply`, along with bug fixes.
- Make sure it fails with an intuitive error when you have non-existent releases referenced from witin "needs"
Introduces DAG-aware installation/deletion ordering to Helmfile.
`needs` controls the order of the installation/deletion of the release:
```yaml
relesaes:
- name: somerelease
needs:
- [TILLER_NAMESPACE/][NAMESPACE/]anotherelease
```
All the releases listed under `needs` are installed before(or deleted after) the release itself.
For the following example, `helmfile [sync|apply]` installs releases in this order:
1. logging
2. servicemesh
3. myapp1 and myapp2
```yaml
- name: myapp1
chart: charts/myapp
needs:
- servicemesh
- logging
- name: myapp2
chart: charts/myapp
needs:
- servicemesh
- logging
- name: servicemesh
chart: charts/istio
needs:
- logging
- name: logging
chart: charts/fluentd
```
Note that all the releases in a same group is installed concurrently. That is, myapp1 and myapp2 are installed concurrently.
On `helmdile [delete|destroy]`, deleations happen in the reverse order.
That is, `myapp1` and `myapp2` are deleted first, then `servicemesh`, and finally `logging`.
Resolves#715
At the moment, if you have a helmfile.yaml like so:
```
releases:
- name: metrics-server
namespace: kube-system
chart: stable/metrics-server
```
If you try to run `helmfile deps`, you will get a 0 exit code and no log
output at whatsoever, signaling that there weren't any problems, but no
lock file will get created.
For example:
```
root@316073d4a104:/# helmfile deps
root@316073d4a104:/#
```
This behavior doesn't appear to be documented and is unintuitive to the
user.
This change adds a warning output for this same use case:
```
root@316073d4a104:/# helmfile deps
There are no repositories defined in your helmfile.yaml.
This means helmfile cannot update your dependencies or create a lock file.
See https://github.com/roboll/helmfile/issues/878 for more information.
root@316073d4a104:/#
```
Fixes#878
Kevin J. Qiu
KUOKA Yusuke
Ilya Vassyutovich
Danny Shemesh
Craig Furman
Guillaume Perrin
刘相轩
Victor Noël
nejtr0n
Craig Dunford
Marcin Kaciuba
Ash Caire
chenrui
Rene Hernandez
RaymondKYLiu
Daniel Elo
Eric Bailey
Gleidson Nascimento
Anton Trifonov
Emil
Daniel Poelzleithner
Christoph Hösler
a-hat
eddycharly
Jake Hill
Harshal Shah
Jeroen Demeyer
Andrew Drake
Andrew Drake
Jan Möller
Tom Duffield
Kyrylo Lebediev
Jarryd Tilbrook
Aaron Batilo
Mike Splain
Theo Meneau
art kon