Actually it doesn't show them at all, because the output of helm --debug is only displayed at the end:
and bytes doesn't retrieve helm's debug logs.
helmfile should display helm debug logs in real time of course.
Why should it be displayed in real-time? Anyway, I'd be happy to review any PR related to this :)
Because Helm displays them in real time, and it is nice to get the progression of long running syncs from Helm perspective, to get the Deployment that hangs e.g. without having to look for it by yourself.
@mumoshu there are a couple of issues here:
I think the helm debug output is super important as without it you have zero visibility into the deployment status as @machine424 mentioned, so you would have to run something like kubectl get pods -w in a separate shell, which isn't viable as part of the CD process.
Example failed deployment output:
STDERR:
history.go:52: [debug] getting history for release amazing-app
install.go:159: [debug] Original chart version: "2.0.1"
install.go:176: [debug] CHART PATH: /Users/dudicohen/Library/Caches/helm/repository/amazing-app-2.0.1.tgz
client.go:108: [debug] creating 1 resource(s)
client.go:108: [debug] creating 3 resource(s)
wait.go:53: [debug] beginning wait for 3 resources with timeout of 5s
wait.go:225: [debug] Deployment is not ready: devops/amazing-app. 0 out of 1 expected pods are ready
wait.go:225: [debug] Deployment is not ready: devops/amazing-app. 0 out of 1 expected pods are ready
wait.go:225: [debug] Deployment is not ready: devops/amazing-app. 0 out of 1 expected pods are ready
Error: timed out waiting for the condition
helm.go:84: [debug] timed out waiting for the condition
Most helpful comment
Because Helm displays them in real time, and it is nice to get the progression of long running syncs from Helm perspective, to get the Deployment that hangs e.g. without having to look for it by yourself.