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 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
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-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 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>
When #8156 was merged it had the side effect that all hooks were
run all the time. All the hooks were put in the flow of the
content rendered and sent to Kubernetes on every command.
For example, if you ran the following 2 commands the test hooks
would run:
helm create foo
helm install foo ./foo
This should not run any hooks. But, the generated test hook is run.
The change in this commit moves the writing of the hooks to output
or disk back into the template command rather than in a private
function within the actions. This is where it was for v3.2.
One side effect is that post renderers will not work on hooks. This
was the case in v3.2. Since this bug is blocking the release of v3.3.0
it is being rolled back. A refactor effort is underway for this section
of code. post renderer for hooks should be added back as part of that
work. Since post renderer hooks did not make it into a release it
is ok to roll it back for now.
There is code in the cmd/helm package that has been duplicated from
pkg/action. This is a temporary measure to fix the immediate bug
with plans to correct the situation as part of a refactor
of renderResources.
Signed-off-by: Matt Farina <matt@mattfarina.com>
If two `helm upgrade`s are executed at the exact same time, then one of
the invocations will fail with "already exists".
If one `helm upgrade` is executed and a second one is started while the
first is in `pending-upgrade`, then the second invocation will create a
new release. Effectively, two helm invocations will simultaneously
change the state of Kubernetes resources -- which is scary -- then two
releases will be in `deployed` state -- which can cause other issues.
This commit fixes the corrupted storage problem, by introducting a poor
person's lock. If the last release is in a pending state, then helm will
abort. If the last release is in a pending state, due to a previously
killed helm, then the user is expected to do `helm rollback`.
Closes#7274
Signed-off-by: Cristian Klein <cristian.klein@elastisys.com>
* fix(template):Issue:helm template with --output-dir doesn't write template with a hook to file
Close#7836
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
* fix go file style
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
* fix go file style
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
Upgrade Kubernetes libraries to v0.18.0
Add new lazy load KubernetesClientSet to avoid missing kubeconfig error
In kubernetes v1.18 kubeconfig validation was added. Minikube and Kind
both remove kubeconfig when stopping clusters. This causes and error
when running any helm commands because we initialize the client before
executing the command.
Signed-off-by: Adam Reese <adam@reese.io>
The memory driver is used for go tests. It can also be used from the
command-line by setting the environment variable HELM_DRIVER=memory.
In the latter case however, there was no way to pre-provision some
releases.
This commit introduces the HELM_MEMORY_DRIVER_DATA variable which
can be used to provide a colon-separated list of yaml files specifying
releases to provision automatically.
For example:
HELM_DRIVER=memory \
HELM_MEMORY_DRIVER_DATA=./testdata/releases.yaml \
helm list --all-namespaces
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
This blocks a particular error (caused by upstream discovery client),
printing a warning instead of failing. It's not a great solution, but is
a stop-gap until Client-Go gets fixed.
Closes#6361
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
This package mainly exists to workaround an issue in Go
where the serializer doesn't omit an empty value for time:
https://github.com/golang/go/issues/11939. This replaces all
release and hook object time references with the new time package
so things actually marshal correctly
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
The recent init action config switched the order of how variables get bound
and where. This led to the namespace variable not being propagated down into
the calls to kubernetes.
Co-authored-by: Matthew Fisher <matt.fisher@microsoft.com>
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>