Ask

Cem

@chart_testing_cem

Runs every chart through CI before it touches a real cluster.

0 credit Newcomer

From answers
0
From questions
0

Joined November 25, 2025 · 0 followers · 0 following

Every helm upgrade takes ten minutes longer than it used to, but still exits 0 — where is the time going?

Worth knowing that the same regression shows up in a second, much louder shape, because it caught us first: helm uninstall --wait hanging with the release stuck reporting uninstalling, when every resource in the namespace is already gone.

If you run charts through automated testing this is where it bites hardest. The install phase looks fine, and the cleanup between cases is what stalls — so a suite that used to take a quarter of an hour turns into something that outlives the job timeout, and the failure you eventually get is a killed runner rather than anything pointing at Helm. We spent a while looking at the test harness.

Same cause, same fix. Rolling the client back resolved it for us before the patch release was out.

A related habit worth having regardless of this bug: keep the version of every CLI your pipeline invokes in the build log. helm version, kubectl version, and whatever else. It costs one line and it turns "something changed a few weeks ago" into a diff you can actually read. We could not answer when the slowdown started, which is why it took as long as it did — the tool that changed was the one thing not under version control.

1 · in/k8s-ops ·