* fix(helm): fix golint warning due to ApiVersionV1 constant name
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm): fix golint warning due to ResolveChartVersionAndGetRepo comment
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm): fix golint warnings on HttpGetter type and SetCredentials method missing a comment
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm):fix golint warning due to comment on FindChartInAuthRepoURL function
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm): fix golint warning due to RepoFile type name
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm): fix golint warning due to ParseString comment
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
Existing helm.sh/hook-delete-policy annotation variables (hook-failed, hook-succeeded) do not allow to leave failed jobs for debugging without blocking the next job launching: every failed job must be deleted manually before the next related release is launching (installing, updating or rolling back).
New policy, before-hook-creation, removes the hook from previous release if there is one before the new hook is launched and can be used with another variable.
When Helm v2.8.2 was released, we made a change to the default connection timeout by supplying a value passed from pkg/helm/environment. This broke support for third party clients relying on pkg/helm because now the default connection timeout is zero. Adding a default 5 second timeout back retains old behaviour, while not breaking backwards compatibility because the connection timeout can still be configured.
When using `helm upgrade --install`, if the first release fails, Helm will respond with an error saying that it cannot upgrade from an unknown state.
With this feature, `helm upgrade --install --force` automates the same process as `helm delete && helm install --replace`. It will mark the previous release as DELETED, delete any existing resources inside Kubernetes, then replace it as if it was a fresh install. It will then mark the FAILED release as SUPERSEDED.
* add test for rolling back from a FAILED deployment
* Update naming of release variables
Use same naming as the rest of the file.
* Update rollback test
- Add logging
- Verify other release names not changed
* fix(tiller): Supersede multiple deployments
There are cases when multiple revisions of a release has been
marked with DEPLOYED status. This makes sure any previous deployment
will be set to SUPERSEDED when doing rollbacks.
Closes#2941#3513#3275
Between grpc 1.2.x and 1.7.x there was an API change. The
previous MaxMsgSize is now a wrapper around MaxRecvMsgSize. This
change now sets the MaxRecvMsgSize and MaxSendMsgSize which need
to be set independently.
CRDs and other objects seen as unstructured cannot use strategic
merge patching. It has never been supported on CRDs. Previously,
cases like unstructured objects could have caused an unregistered
error. This is no longer the case.
This change explicitly looks for unstructured objects and handles
those using json merge patching.
Closes#3382