feat(api): let a release set the helm action timeout

[drey]

Summary

HelmApplication and HelmClusterAddon now take spec.timeout, the time to wait for any individual Kubernetes operation (like Jobs for hooks) during a Helm action. It is passed as is to spec.timeout of the internal HelmRelease, which helm-controller uses as the default for every action — install, upgrade, uninstall, rollback and test.

Why

The timeout was fixed at helm-controller's default of 5m, so a chart whose hooks or rollout take longer could not be installed, upgraded or removed through the module at all.

Key changes

API — api/v1alpha1/helm_application.go, api/v1alpha1/helm_cluster_addon.go

• The field is shaped like the flux HelmRelease one: *metav1.Duration, a string with the same duration pattern, optional.
• Two CEL rules bound it: greater than zero (the pattern alone accepts 0s) and at most 2h.
• No schema default. An unset field leaves the HelmRelease field unset and helm-controller's default applies, so the value can be changed later without every stored object carrying the old one. The description states the current default of 5m.
• The field is described in both CRDs and their Russian mirrors.

Controller — internal/source/release.go, internal/adapter/*_release.go, internal/services/release_service.go

• source.Release gains Timeout(), read by both adapters.
• applyHelmReleaseSpec sets it on every pass, so removing it from the spec removes it from the HelmRelease too.
• SyncReleaseSpec sets it while the release is being deleted: the timeout bounds the uninstall, and raising it is how a stuck uninstall is let through.

Review focus / risks

• Verification. Unit tests cover propagation for both families, clearing, and the deletion path (release_service_test.go). The CEL rules were checked against the generated CRDs with the apiextensions-apiserver v0.35.1 validator — the CRDs pass admission validation, including the CEL cost estimate, and values such as 0s, 0.0s, 2h0m1s, 121m are rejected while 1ms, 1.5h, 2h are accepted. Neither the rules nor the rollout has been run on a live cluster.
• Changing only the timeout on an existing release changes the HelmRelease spec and generation. I expect helm-controller to apply the new value to the next action without an upgrade of its own, since chart and values are unchanged, but this is not verified.
• "Defaults to 5m" in the description is true only while helm-controller's default stays 5m; nothing in our schema pins it.

🤖 Generated with Claude Code