The new version of HelmRelease does not trigger the update instantly, it will wait until the timeout expires.

[Subetov]

For example, you have HelmRelease with a timeout of 30 minutes (waiting for a job that takes a long time to complete).
You make a change and apply the new version of HelmRelease while the previous installation with a timeout of 30 minutes is still running.
But the Helm controller does not stop the previous installation and will wait until the timeout ends, and only then it will begin installing the new version of HelmRelease.
In the previous version (helm-operator) it interrupted the current installation and started a new one.
Isn't the previous behavior better, when when a new version of HelmRelease appears, the controller stops installing the previous version and starts installing the new one?

[kingdonb]

xref: fluxcd/flux2#4923

Set timeout lower. I expect most deployments to complete in 2m so I set a timeout of 2.5m because that's plenty of time. If you're not sure how long the deployment should take to roll out, go with the engineering estimate: double it and add 50% more 🤣

[kingdonb]

There might be a case to make timeouts interruptible, it might be a possible change, but without users opting in via spec I don't think it's possible, it would represent a breaking change.

If you have a job that might take up to 30m routinely, I don't know if it makes sense in a GitOps workflow, frankly.