The result is that when doing shell completion (bash and zsh only),
instead of getting no suggestions for commands that take no more
arguments, the user will instead be shown an informative message:
$ helm list <TAB>
This command does not take any more arguments (but may accept flags).
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
When --skip-schema-validation is set, any schema contain in the helm chart is ignored. Defaults to 'false'.
Closes#10398
Signed-off-by: anessi <16045045+anessi@users.noreply.github.com>
This change adds a new flag to the install and upgrade commands in
the Helm client and properties to the install and upgrade action.
The new flag is --hide-secret and can only be used with the
--dry-run flag.
The --dry-run flag is designed to send all chart rendered manifests to
stdout so that they can be inspected.
When the --hide-secret flag is used the Secret content is removed from
the output.
Signed-off-by: Matt Farina <matt.farina@suse.com>
The ordering should be:
1. User specified values (e.g CLI)
2. Parent chart values
3. Imported values
4. Sub-chart values
This enables parnet charts to import large set of values from a
child and then override select values.
This change is needed for backwards compatibility.
Fixes#12460
Signed-off-by: Matt Farina <matt.farina@suse.com>
Some charts don't need a templates directory. The warning appears to originate back when helm expected all charts to contain templates. In CI situations where linting is performed with --strict the lint warning causes unneccessary failures for charts that quite legitimately do not contain a templates directory.
As discussed in #8033 there are no longer any scenarios understood where this warning is helpful so this commit removes it.
Signed-off-by: James Blair <mail@jamesblair.net>
First, some notes about priority and how some code flow works.
For Helm handling values, the expected order of precidence is:
1. User specified values (e.g CLI)
2. Imported values
3. Parent chart values
4. Subchart values
Helm handles dependency values slightly differently. If there are dependencies
in the charts folder that are not marked as dependencies all of the values,
including nil values, are pulled in. If those charts are listed as a
dependency in the Chart.yaml file than they are processed for import handling.
Prior to the changes here, it caused nil values at the top level to NOT remove
values specified.
The changes:
1. The order of priority was chagned from the list above. Parnet chart values
would override specifically imported values. This is due to a change from
just over a year ago that introduced a bug. That was undone by changing the
precidence when maps were merged.
2. To handle merging while retaining the nil values, which was causing
inconsistent behavior, a new set of Merge functions were introduced. These
functions are just like coalesce except that they DO NOT remove nil/null values.
The new functions are used in a backward compatible manner meaning some new
functions were introduced that called them.
Specific issues fixed (that are known):
Closes#9027
Can now delete subkeys from charts when specified in the parent. This behavior
was previously inconsistent. Sometimes they could be deleted and other times
it did not work. Now it is consistent.
Closes#10899
Imported values (from library or other subcharts) are now used following the
order above.
The previous behavior was inconsistent. import-values using just a string
would import them. When named with a child/parent it did not work if the
parent already had a value. If string and named were mixed the imports
worked if the string happened first but just for the string not the named.
If the named parent/child went first then none of them worked for cases
where the parent already had a value. It was inconsistent and the tests
sometimes mirrored the functionality rather than expected behavior.
Tests for this fall into the sub-packages and are in the template tests
to verify it's happening in the output. Including having values passed
at the CLI as the ultimate highest priority to be used.
This relates to a fix that went in for #9940. The expected values there don't
fit the precedence above where the parent value would override the imported
value. That fix/change introduced more bugs.
Closes#10052
This is the case where imported values using the parent/child designation
just didn't work right. That has been fixed and there are tests. The underlying
issue had to do with the precedence order handling.
Note, a lot of tests were added. Hope we got it more right this time.
Signed-off-by: Matt Farina <matt.farina@suse.com>
Add new CLI flag --fail-on-no-result for failing the helm
search when there is no result found. This works with:
1. helm search repo
2. helm search hub
Signed-off-by: Bhargav Ravuri <bhargav.ravuri@infracloud.io>
Before, if a chart was uninstalled using the `--keep-history` flag, the
next attempt to upgrade/install the chart would result in an error.
This commit fixes that by correctly checking if the last release of the
chart stored in history has been uninstalled and running the install
with the `--replace` flag if that's the case.
Signed-off-by: Alex Petrov <alex.petrov.vt@gmail.com>
Creating a new PR based on this existing stale PR https://github.com/helm/helm/pull/7728
Signed-off-by: Soujanya Mangipudi <somangip@microsoft.com>
# Conflicts:
# go.sum
Add a new flags and associated environment variables to override
the TLS Settings used when constructing the Kube Client.
- `--kube-insecure-skip-tls-verify | HELM_KUBEINSECURE_SKIP_TLS_VERIFY`: if true, the kube api server's certificate will not be checked for validity. This will make your HTTPS connections insecure
- `--kube-tls-server-name | HELM_KUBETLS_SERVER_NAME`: server name to use for kube api server certificate validation. If it is not provided, the hostname used to contact the server is used
Signed-off-by: Justen Walker <justen.walker+github@gmail.com>
* feat: add configuration for client-side throttling limit
Client-side throttling seems to be an issue in larger environments such as OpenShift clusters, where
it is common to have several hundreds CRDs out-of-the-box.
From this view point, it is fair that clients should be able to fine tune this accordingly should the
environment they work on evolves, which is currently not possible, and quite frustrating.
This change introduces the --default-burst-limit option to helm (and its counterpart
HELM_DEFAULT_BURST_LIMIT environment variable) to address that issue, allowing clients to properly
tune their client usage as their environment evolves.
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* chore: change DefaultBurstLimit to BurstLimit
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* chore: add HELM_BURST_LIMIT to golden file
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* chore: add burst limit tests
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* docs: add burst limit default value to documentation
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
* refactor: change burst limit default value to 100 per review instructions
Signed-off-by: Igor Sutton <isuttonl@redhat.com>
Quiet flag reduce the verbosity, such that the only text
that is written to the console is lint warnings/errors
Closes#9994
Signed-off-by: Piotr Resztak <piotr.resztak@gmail.com>
We had made the assumption that when doing shell completion, we only
needed choices that had for *prefix* what the user had typed.
However, the zsh and fish shells have a more advanced matching system
which first matches on prefix, but if no match is found, then does
more advanced matching attempts, such as sub-strings; fish even matches
on descriptions of completions.
For example,
helm status nginx<tab>
would match releases such as
ingress-nginx
ingress-nginx-release
as long as no release had a prefix of "nginx".
Such fuzzy matching can make completion even more useful for users in
cases where identical prefixes are common.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>