Currently, if using the --atomic flag or deleting a release that failed due to an already existing
resource, Helm will deleting those resources that aren't managed by it. This PR fixes the issue
by checking for pre-existing resources during install and upgrade. This is done as a validation
step so the release will not even be started if resources currently exist. This PR is inspired by
@xchapter7x's work in #3477.
This also fixes a small bug in upgrade where deletes fail if the resource was already deletes
Fixes#6407
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
* Port Helm 2 PR 4088 to Helm 3
Not a direct port as is but refactored for Helm 3.
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
* Update unit test to test string retunred for different order
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
* Change release storage name to prefix helm storage type
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
* Add comments about the Kubernetes storage object type field content
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
As part of this port, I removed some now superfluous code from the `action` package.
This is technically a breaking change, but since the package was introduced in v3, it
is highly unlikely anyone is using it and we are still within the beta window.
Also closes#6437
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
If a user renames the helm binary, the shell needs to be told that this
new name corresponds to the helm completion function. For example if
the user decides to rename the helm v3 binary to 'helm3', then the
following command extra command would need be run by the user:
complete -o default -F __start_helm helm3.
This commit automates this by adding this extra command to the generated
shell completion script by looking at what binary was used to call the
helm completion command. For example, if the user renames the binary
to helm3 and then calls
helm3 completion bash
the completion script will include a hook for the binary 'helm3' to
the completion script.
A binary rename is one of the two options recommended when users need to
run both helm2 and helm3.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
This allows that any addition to the bash completion logic be
automatically added to the zsh logic.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
I made a few modifications from the original code to fit in with the new
code layout and to clarify a few things. This is a port of #3758
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
we want to force a cache invalidation to ensure that the Capabilities object always has the latest information from the server (Kubernetes server version, available API versions, etc). `kubectl version` forces a cache invalidation every time it's invoked, so this seems like a safe change that is identical to kubectl's behaviour.
Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>
This ports the functionality of cleanup on fail to v3 as introduced in #4871. This has been tested manually
and would be a good candidate for a new acceptance test.
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
The binary of Helm to use for dynamic completion should be the same
as the actual Helm binary being used. For example, if PATH points
to a version of helm v2, but the user calls bin/helm to use a local
v3 version, then dynamic completion should also use bin/helm.
If not, in this example, the dynamic completion will use the
information returned by helm v2.
This improvement is particularly useful for users that will run both
helm v2 and helm v3 at the same time.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
Taylor Thomas
Matthew Fisher
Bhavesh Sethi
Martin Hickey
Yusuke Kuoka
Marc Khouzam
Adam Reese
Adam Reese
Matt Farina
Cindy O'Neill