Parses a new field in repositories named `skipTLSVerify` and if set to `true`, it appends `--insecure-skip-tls-verify` in `helm repo add` command.
This should be useful with internal self-signed repos, mitm proxies etc.
Resolves#1871
This adds the ability to include the --pass-credentials flag to the helm add repo command by:
- Adding repo.passCredentials to the helmfile yaml
- Changing state, helmexec, and app to include RepositorySpec.PassCredentials
Resolves#1898
Co-authored-by: almed4 <alexandre.meddin@ingka.ikea.com>
Secret files ending with .gotmpl are now also rendered as a gotemplate.
```
releases:
- name: myapp
secrets:
- secrets.yaml.gotmpl
```
Note that currently, .gotmpl files must be valid YAML files as well.
The expected use-case of this feature is to compose a YAML array from values and encrypted secrets.
Without this feature, you would have tried to do something like the below, which didn't work.
**Example (doesn't work!)**
`values.yaml.gotmpl`:
```
environment:
- name: MY_EXTERNAL_IP
value: |
{{ exec "./get-external-ip.sh" (list "") }}
```
`secrets.yaml`:
```
_sops:
#...
environment:
- name: MY_SECRET_VALUE
value: (encrypted by sops)
```
`helmfile.yaml`:
```
releases:
- name: foo
values:
- values.yaml
secrets:
- secrets.yaml
```
This doesn't work because `values.yaml` and the decrypted `secrets.yaml` are passed to `helm` to be merged, and helm overrides the array instead of merging or concatenating the arrays.
**Example (works!)**
Instead of `values.yaml` and `secrets.yaml`, you provide a single `secrets.yaml.gotmpl` that is a valid YAML and encrypted by sops:
```
_sops:
#...
environment:
- name: MY_EXTERNAL_IP
value: |
{{ exec "./get-external-ip.sh" (list "") }}
- name: MY_SECRET_VALUE
value: (encrypted by sops)
```
`helmfile.yaml`:
```
releases:
- name: foo
secrets:
- secrets.yaml.gotmpl
```
Helmfile decrypts the gotmpl by handing it over to helm-secrets and then renders the result as a gotmpl file. The end result is that you have a two-element array `environments` that can be just passed to helm.
Resolves#1700
Co-authored-by: Yusuke Kuoka <ykuoka@gmail.com>
`helmfile-diff` sorts multiple and concurrent helm-diff outputs and stabilizes writes to stdout.
It's required to use the stdout from helmfile-diff to detect if there was another change(s) between 2 points in time.
For example, terraform-provider-helmfile runs a helmfile-diff on `terraform plan` and another on `terraform apply`. `terraform`, by design, fails when helmfile-diff outputs were not equivalent. Stabilized helmfile-diff output rescues that.
While using the `--debug` option, the output of helm seems to be printed triple times:
```
Templating release=test, chart=charts/test
exec: helm template test charts/test --namespace staging --values /tmp/values266548685 --output-dir outputs//helmfile-test-staging-ed5e3c94-test --debug
helm:MRAjW> install.go:172: [debug] Original chart version: ""
helm:MRAjW> install.go:189: [debug] CHART PATH: /app/charts/test
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/templates/secret.yaml
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/configmap.yaml
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/health-configmap.yaml
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/headless-svc.yaml
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/metrics-svc.yaml
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/redis-master-svc.yaml
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/redis-master-statefulset.yaml
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/templates/ingress.yaml
helm:MRAjW> wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/metrics-prometheus.yaml
helm:MRAjW>
exec: helm template test charts/test --namespace staging --values /tmp/values266548685 --output-dir outputs//helmfile-test-staging-ed5e3c94-test --debug: wrote outputs//helmfile-test-staging-ed5e3c94-test/test/templates/secret.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/configmap.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/health-configmap.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/headless-svc.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/metrics-svc.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/redis-master-svc.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/redis-master-statefulset.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/templates/ingress.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/metrics-prometheus.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/templates/secret.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/configmap.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/health-configmap.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/headless-svc.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/metrics-svc.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/redis-master-svc.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/redis-master-statefulset.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/templates/ingress.yaml
wrote outputs//helmfile-test-staging-ed5e3c94-test/test/charts/redis/templates/metrics-prometheus.yaml
```
- The first with the prefixes `helm:MRAjW>` comes from <563fce4adf/pkg/helmexec/runner.go (L59-L65)>
- The second one with the format `exec: helm ... --debug: ...` comes from <563fce4adf/pkg/helmexec/exec.go (L369)>
- And the last are the logs of non-debug mode.
It sometimes makes the log a bit confusing, while I first time read the log, I thought helmfile executed helm command multiple times 😅.
Since we already piped helm outputs to stdout (the first), we remove the second logs.
Adds a basic support for Helm repositories hosted on Azure Container Registry (not OCI but classic ones). Add a new field to RepositorySpec to state that is externally managed and runs the `az-cli` command instead of the helm one to manage the repository.
* Parse and process helm version using github.com/Masterminds/semver/v3.
* Add --force-update only when Helm version >= 3.3.2, < 3.3.4.
See: https://github.com/helm/helm/pull/8777.
* Add test cases.
This is an attempt to log helm exec output as the helm exec command is running. It only prints if the --debug flag is set.
Co-authored-by: Yusuke Kuoka <ykuoka@gmail.com>
* Move kube-context from helmDefaults to 1'st argument to let kube-context per release override it
* fix tests
Co-authored-by: Alex Vorona <av@dysnix.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
* 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
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>
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
`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.
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"
Set `HELMFILE_HELM3=1` and run `helmfile` like `HELMFILE_HELM3=1 helmfile ...`.
When `HELMFILE_HELM3` is set, `test`, `template`, `delete`, `destroy` behave differently so that it works with Helm 3.
Note that `helmfile diff` doesn't work as `helm-diff` called under the hood doesn't support Helm v3 yet.
Ref #668
Related to #782 and #444
- Allows concurrent decryption of different secrets files
- Caches decrypted secrets by original file path and returns decrypted results from memory
- Secrets being run through an instance of helmexec will be cached and run as fast as possible concurrently
NB: This particular PR doesn't make _all_ calls to secrets cached and concurrent. Environment Secrets in particular seem to not be evaluated with a ScatterGather(), and doesn't use the same helmexec instance as other parts of the code, so it doesn't take advantage of these changes. Some reworking of the plumbing there would be needed.
helm-secrets uses the `HELM_SECRETS_DEC_SUFFIX` env var to define the name of the output file
we should have the same logic in helmfile, to come up with the same filename
It only affects people using the `HELM_SECRETS_DEC_SUFFIX` env var
Use-case: if you want to run multiple `helmfile` commands in parallel, without conflicts. in this case, you need to decrypt secrets with different suffixes.
yxxhero
Anton Bretting
Babis K
Aditya Menon
Alex Meddin
Philipp Hossner
Yusuke Kuoka
Chris Mellard
Andrey Tuzhilin
Jason Witkowski
Cameron Braid
Chris Mellard
Sven Schliesing
Wi1dcard
Javier Palacios
AdamClark
Anatoly Rugalev
Alex Vorona
刘相轩
Craig Dunford
Gleidson Nascimento
Emil
Jake Hill
Andrew Drake
Andrew Drake
Jan Möller
Theo Meneau
astorath
Travis Groth
OlivierB
Kevin J. Qiu
Vincent Behar