slog.Error on line 157 passes printf-style positional args (%q, %s)
instead of key-value pairs. The slog API treats these as unkeyed
attributes, producing garbled log output.
Two nearby slog.Warn calls wrap fmt.Sprintf unnecessarily. Convert
all three calls to use proper structured key-value arguments.
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
Assisted-by: Grok/grok-4
- Close log stream after reading (prevents connection/fd leak)
- Strengthen tests to assert on output headers rather than error paths
- Remove unused import
Signed-off-by: Sebastien Tardif <SebTardif@ncf.ca>
When a test pod contains multiple containers (e.g. Istio/Consul/Vault
sidecars), 'helm test --logs' failed with 'a container name must be
specified'. This happened because GetPodLogs called the Kubernetes log
API without specifying a container name.
The fix fetches the pod spec first, then iterates over all containers
(init containers + regular containers) and requests logs for each one
explicitly. Errors from individual containers are collected and returned
together via errors.Join rather than aborting on the first failure.
Also fixes a typo: hooksByWight -> hooksByWeight.
Closes#6902
Signed-off-by: Sebastien Tardif <SebTardif@ncf.ca>
Helm now requires Go 1.26 (#32078); the cloner[T] type-assertion fallback
in transport.go was a defensive shim for Go versions before
http.Transport.Clone() existed. The fallback path is unreachable on
supported Go versions.
Refs: #31386
Signed-off-by: Ogulcan Aydogan <ogulcanaydogan@hotmail.com>
The previous change suppressed ctx.Err() whenever there were no
resource-specific errors, which incorrectly swallowed context.Canceled
and other non-deadline errors signalling an external interruption.
Refine the condition: only suppress context.DeadlineExceeded when there
are no resource-specific errors (resources are Unknown/NotFound, meaning
the delete wait succeeded or resources were already gone). Any other
context error — including context.Canceled — is always propagated.
Signed-off-by: Terry Howe <terrylhowe@gmail.com>
During informer initialization there is a brief window where watched
resources appear as Unknown before their real statuses are delivered.
The statusObserver skips Unknown resources when waiting for deletion
(they may have been deleted before the watch started), but if *all*
resources are in that transient Unknown state the skipped-resource list
is empty. AggregateStatus on an empty slice returns the desired status,
causing cancel() to be called immediately — before any real status event
has arrived.
Guard against this by tracking the count of Unknown-skipped resources.
When every resource was Unknown-skipped and none have a definitive status
yet, defer the early-cancel decision until at least one resource reports
a real status. This preserves the correct behaviour for resources that
were genuinely deleted before the watch started (they eventually receive
a NotFound or stay Unknown, and the aggregate succeeds), while fixing
the race for resources that are transiently Unknown at startup.
Also tighten the ctx.Err() check in waitForDelete: only append a
deadline error when there are resource-specific errors to accompany it.
A timeout while all resources are Unknown or NotFound is not itself an
error — the resources are in an acceptable state for a delete wait.
Fixes: TestStatusWaitForDelete/error_when_not_all_objects_are_deleted
Signed-off-by: Terry Howe <terrylhowe@gmail.com>
Only user-supplied nils should survive coalescing. Chart-default nils
defaults, not just user overrides. This caused:
- %!s(<nil>) in templates using Bitnami common.secrets.key (#31919)
- pluck fallbacks returning nil instead of falling through to globals
(#31971)
Fixes#31919Fixes#31971
Signed-off-by: Johannes Lohmer <jojo.dev@lohmer.com>
Three test cases that cover the regression scenarios introduced
by the #31644 nil preservation fix:
- subchart default nils should be cleaned up
when parent doesn't set those keys (#31919)
- user-supplied null should erase subchart defaults (#31919)
- subchart default nil should not shadow global values via pluck (#31971)
Tests are expected to fail until the regression is fixed.
Signed-off-by: Johannes Lohmer <jojo.dev@lohmer.com>
When running 'helm pull --debug', no debug output was printed because
the HTTP getter did not emit any slog.Debug messages. This adds
slog.Debug calls to log the URL being fetched and the response status
when debug-level logging is enabled.
Fixeshelm/helm#31098
Signed-off-by: Cairon <cairon-ab@users.noreply.github.com>
Move implementation to pkg/kubeenv per review; kube.RetryingRoundTripper
remains a type alias for API compatibility. pkg/cli uses kubeenv only.
Signed-off-by: Sumit Solanki <sumit.solanki@ibm.com>
The previous fix (increasing timeout / reducing deletion delay) did not
work because the flakiness is not a timing problem at all.
Root cause: fluxcd/cli-utils HasSynced() returns true after the initial
list item is *popped* from DeltaFIFO, which is before AddFunc delivers
the ResourceUpdateEvent to the collector. This creates a race where the
SyncEvent can arrive at the statusObserver *before* the pod's Current
status is recorded. When that happens:
- statusObserver sees pod as Unknown
- Unknown is skipped for WaitForDelete (by design, to handle resources
that were already deleted before watching started)
- AggregateStatus([], NotFoundStatus) == NotFoundStatus → cancel()
- The watch context is cancelled before DeleteFunc can fire
- Final check: pod still Current → error
The test intent is to verify that waitForDeleteCtx (not the cancelled
generalCtx) is selected. A non-existent resource satisfies this:
- With waitForDeleteCtx=Background(): informer syncs with empty list
→ Unknown → cancel → success ✓
- With generalCtx (cancelled, wrong): context immediately done
→ ctx.Err() appended → error returned ✓
Remove the goroutine-based deletion and the pod creation to eliminate
the race while preserving the context-selection assertion.
Signed-off-by: Terry Howe <terrylhowe@gmail.com>
TestMethodContextOverridesGeneralContext/WaitForDelete used a 1s
timeout with a 500ms deletion delay, leaving only ~500ms for the
fake watcher to propagate the delete event. On loaded CI runners
this window is too tight and causes intermittent failures.
Increase the timeout to 5s and reduce the deletion delay to 100ms
so there is ample headroom. Apply the same deletion-delay reduction
to TestStatusWaitForDelete which shares the same pattern.
Signed-off-by: Terry Howe <terrylhowe@gmail.com>
Karim Farid
Terry Howe
George Jenkins
Evans Mungai
Austin Abro
Robert Sirchia
Sebastien Tardif
Kai Tanaka
box4wangjing
Sumit Solanki
Ogulcan Aydogan
Matthieu MOREL
Matheus Pimenta
Johannes Lohmer
Johannes Lohmer
Jorge Rocamora
Cairon
Anmol Virdi