Emit the warning first to ensure it's always logged. This clarifies that any following errors are due to using a local chart instead of a remote repository.
Signed-off-by: Feng Cao <24779889+shfc@users.noreply.github.com>
If a resource exists in the cluster and is to be adopted by helm install
--take-ownership, it is left unchanged while helm reports the
installation to have succeeded.
This is due to CRs and CRDs being merged without three-way-merge, which
results in an empty patch.
By using a three-way-merge transparently when --take-ownership is used,
the helm behaves as expected without breaking previous behavior.
Fixes#30622
Signed-off-by: Patrick Seidensal <pseidensal@suse.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>
Allow the SDK actions to adopt existing resources. This allows install
and update to overwrite resources. If TakeOwnership is not set, adoption
is only possible if they existing resources have the right labels
(managed-by) and annotations (release-name, ...).
Signed-off-by: Mario Manno <mmanno@suse.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>
When username/password parameters are passed in via the CLI
they are not passed down to the client handling requests to
OCI registries. This change ensures this happens
Signed-off-by: Evans Mungai <mbuevans@gmail.com>
There are a few changes to the new dry-run handling:
1. Some documentation is added to help clarify what is happening
and what is expected.
2. DryRun is never changed by internal handling. If an API user
sets the property it is not changed by our code.
3. The behavior on contacting the server with false/none is made
consistent between install and upgrade.
Signed-off-by: Matt Farina <matt.farina@suse.com>
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 a new flag `--plain-http` to the following commands:
* `helm install`
* `helm pull`
* `helm push`
* `helm template`
* `helm upgrade`
* `helm show`
This flag instructs the registry client to use plain HTTP connections,
thus enabling upload/download of charts from OCI registries served at
an HTTP endpoint.
Signed-off-by: Sanskar Jaiswal <jaiswalsanskar078@gmail.com>
During the install process there was a place where an install
process could be stuck trying to write to a channel. This would
happen when a context had completed prior to performInstall
finishing. In a short running Helm Client this was not a problem.
But, for long running applications that use Helm as an SDK there
are problems where a memory leak ends up happening due to
goroutines never being able to complete.
This fix provides a means for performInstall to write to its
channel using the method already used to fix the upgrade
issue of the same kind.
Fixes#11805
Signed-off-by: Matt Farina <matt.farina@suse.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes helm#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
At this time both Go 1.19 and 1.20 are supported. The version
specified in the go.mod file is the minimum version we expect Helm
to be compiled against. This is the oldest supported version to
support environments where others compile Helm. The Helm project
is using Go 1.20 to build Helm itself.
Updating to Go 1.19 also includes dealing with io/ioutil
deprecation and some additional linting issues around staticcheck.
All the staticcheck issues were in test files so linting was
skipped for those.
Signed-off-by: Matt Farina <matt.farina@suse.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes helm#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
As the CRDs are installed before the capabilities are gathered, the
current call to invalidate the discovery client is premature and
expensive.
What actually is required is an invalidation of the REST mapper, as
otherwise the Helm install action may later on fail with a `resource
mapping not found` error. More specifically when the caller of the
action is making use of a persisting[1] `RESTClientGetter`.
Which is not something done by the Helm CLI (albeit it could, and this
would potentially save quite some resources?). But is a default
configuration offered by the Helm SDK via `kube.New` when a nil value
is provided as the `getter`.
[1]: https://github.com/kubernetes/cli-runtime/blob/v0.26.2/pkg/genericclioptions/config_flags.go#L118
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
If enabled the registryClient is set using a helper that accepts the TLS
flags. This keeps the client creation consistent accross the different
commands.
Signed-off-by: Soule BA <bah.soule@gmail.com>
If implemented, users will be able to use custom certificates and CA to
while interacting with OCI registries.
Signed-off-by: Soule BA <bah.soule@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run-option=server flag, it will try to connect to the cluster
to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes helm#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
