So we should use dynamic handler to set the log level after. With this
patch we can clearly see the output. Before we were always stuck in log
level "info" and not seeing debug log level
```
bin/helm upgrade --install --debug --wait frontend \
--namespace test \
--set replicaCount=2 \
--set backend=http://backend-podinfo:9898/echo \
podinfo/podinfo
level=DEBUG msg="getting history for release" release=frontend
level=DEBUG msg="preparing upgrade" name=frontend
level=DEBUG msg="performing update" name=frontend
level=DEBUG msg="creating upgraded release" name=frontend
level=DEBUG msg="checking resources for changes" resources=2
level=DEBUG msg="no changes detected" kind=Service name=frontend-podinfo
level=DEBUG msg="patching resource" kind=Deployment name=frontend-podinfo namespace=test
level=DEBUG msg="waiting for resources" count=2 timeout=5m0s
level=DEBUG msg="waiting for resource" name=frontend-podinfo kind=Deployment expectedStatus=Current actualStatus=Unknown
level=DEBUG msg="updating status for upgraded release" name=frontend
Release "frontend" has been upgraded. Happy Helming!
NAME: frontend
LAST DEPLOYED: Thu Apr 10 09:56:25 2025
NAMESPACE: test
STATUS: deployed
REVISION: 6
DESCRIPTION: Upgrade complete
```
Signed-off-by: Benoit Tigeot <benoit.tigeot@lifen.fr>
TestInstallRelease_Atomic_Interrupted needs the same wait
as TestInstallRelease_Wait_Interrupted (see helm/helm#12088).
The installation goroutine started by
TestInstallRelease_Atomic_Interrupted proceeds in the background and
may interfere with other tests (see helm/helm#30610)
Also see helm/helm#12086 and helm/helm#12109 which are describe and address the root
cause.
Signed-off-by: Rostyslav Polishchuk <rostyslavp@google.com>
Place APIService before webhooks, with MutatingWebhookConfiguration
before ValidatingWebhookConfiguration to match standard admission control.
Signed-off-by: Mike Delucchi <git@zanuka.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>