Release v1.14.0

[gianlucam76]

🚀 New Features

Job-Based Health Checks
ValidateHealth gains JobCheck, a third check type alongside the existing Lua Script and CEL evaluation: point it at a Job manifest (via JobRef, stored in a Secret or ConfigMap) and its Complete/Failed outcome becomes the check result, mutually exclusive with the other two. Since ValidateHealth is embedded by both ClusterProfile/Profile and ClusterPromotion, it's available to PreDeployChecks, ValidateHealths, PreDeleteChecks, PostDeleteChecks, and PostDelayHealthChecks with no further changes.
PRs: libsveltos #654, sveltos #775

Per-Resource Force Recreate
KustomizationRef.Force/PolicyRef.Force applied all-or-nothing to every resource in a reference. A single resource can now opt into force-recreate on its own by carrying the projectsveltos.io/forceRecreate annotation, even when the reference-level Force is false.
PR: libsveltos #655

Gzip-Compressed and bsdtar-Produced OCI RemoteURL Layers
RemoteURL's oci:// path had two gaps that caused real-world OCI artifacts to fail or get misread: a gzip-compressed tar layer failed the tar parse and fell through to the raw-blob path, so the compressed bytes were handed downstream as if they were YAML; and AppleDouble/PAX sidecar entries produced by tools like macOS's bsdtar (e.g. ._ns.yaml next to ns.yaml) were matched by extension alone and swept into the manifest as binary garbage. Both are now filtered and decompressed correctly.
PR: addon-controller #1911

RemoteURL Tarball Support and Insecure-Connection Options
PolicyRefs' remoteURL over HTTP/HTTPS now accepts a tarball of multiple YAML/JSON files (gzip-compressed or plain), not just a single raw document. RemoteURL/RemoteKustomizeURL also gain two optional fields: plainHTTP to connect to an OCI registry over plain HTTP, and insecureSkipTLSVerify to skip server certificate verification, matching the trust options already available for Helm OCI registries.
PRs: sveltos #780, addon-controller #1913

dependsOn Also Protects Deletion Order
dependsOn already blocked a dependent ClusterProfile from deploying until its prerequisites reached Provisioned. Nothing enforced the reverse on delete: a prerequisite (e.g. cert-manager) and its dependent (e.g. kyverno, via dependsOn) would undeploy concurrently as soon as their own ClusterProfiles were deleted, in random order. dependsOn is now a two-way contract, the same pattern Kubernetes itself uses for a CRD with live CRs, or a PVC still mounted by a pod: a ClusterSummary's undeploy is now blocked while another ClusterSummary for the same cluster still exists and still lists this profile in its own dependsOn. The blocked ClusterSummary surfaces why via Status.Dependencies.
PR: addon-controller #1918

---

⚙️ Improvements

Reduced CRD Watcher Memory Usage
WatchCustomResourceDefinition kept every CustomResourceDefinition on the cluster in a local indexed cache for the life of the process, even though every caller only reads the GVK carried by the event that fires and none of them ever read the cache back. It's now backed by a Reflector that forwards each event straight to the handler and discards it, keeping the same list-then-watch/relist-on-error behavior without the resident memory. Most visible on sveltos-agent, in clusters with many CRDs installed.
PR: libsveltos #659

Helm Drift Redeploy Scoped Per Chart
With syncMode: ContinuousWithDriftDetection deploying multiple Helm charts from one ClusterProfile, drift on a single resource used to mark the entire Helm feature for redeploy and unconditionally upgrade every chart, regardless of whether it had drifted or even changed. Redeploy now checks a per-chart flag first, so a chart that neither drifted nor changed is left alone.
PR: addon-controller #1915

sveltos-agent: Reduced ConfigMap Memory Usage in Agentless Mode
In agentless mode, sveltos-agent's cache already scoped ConfigMaps by cluster namespace, but cached every ConfigMap in that namespace in full, including unrelated Helm-values or raw-YAML ConfigMaps deployed via policyRefs. It's now filtered by name to just the ConfigMap relevant to that cluster.

---

🐞 Bug Fixes

addon-controller: DeploymentType Local Cleanup on a Self-Managed Cluster
When the managed cluster is a self-managed SveltosCluster (its remote client/config resolve back to the management cluster itself), the remote-cluster stale-resource cleanup pass scanned the management cluster with no per-ClusterSummary scoping, deleting same-GVK resources deployed there by other ClusterSummary instances via deploymentType: Local. Every deployed resource is now tagged with its owning ClusterSummary, and both cleanup passes honor that tag, checking it only as a protective signal so pre-upgrade resources without it still fall through to the existing ownership checks.
PR: addon-controller #1892

sveltos-agent: Watching GVKs From Other Clusters in Agentless Mode
The GVK-watch-building path for Reloaders, EventSources, and HealthChecks listed every instance in the management cluster instead of scoping to the managed cluster an agent instance is responsible for, so an agent could enable ConfigMap/Secret watches or start informers for kinds only relevant to a different cluster's policies. Now filtered against each cluster's own tracking ConfigMap, matching the scoping the reconcilers already applied.

addon-controller: Reloader Not Cleaned Up on ClusterProfile Delete
Deleting, or unmatching, a Helm-based ClusterProfile with spec.reloader: true left its Reloader instance, and in agentless mode its per-cluster ConfigMap entry, behind indefinitely, referencing Deployments from a chart no longer deployed. The undeploy path was tagging the cleanup with the Kustomize feature instead of Helm, so both lookups silently missed. Resources- and Kustomize-based profiles were unaffected.
PR: addon-controller #1898

healthcheck-manager: Stale ClusterHealthCheck Conditions and Notifications
Three compounding bugs kept Status.Conditions and notifications frozen even as the underlying HealthCheckReport kept updating: Spec.HealthCheckName was never populated on HealthCheckReport, the watch mapper relied on that same empty field and resolved to zero ClusterHealthChecks to reconcile, and re-evaluation was skipped for clusters already Provisioned. Also fixes related Discord/Slack formatting bugs.
PR: healthcheck-manager #421

addon-controller: Failed Helm Upgrade Could Silently Uninstall the Release
A failed Helm upgrade still leaves a release record behind, stamped with the version it tried, and failed, to reach. That made the install/upgrade decision misread the release as already handled, and after a couple more failures deleted it and reinstalled from scratch. The decision now checks whether a release exists at all instead of inferring it from version/status, and the install-retry threshold is now its own setting, HelmInstallOptions.RecoverAfterConsecutiveFailures (default 5), instead of being borrowed from Helm's revision-retention MaxHistory.
PR: addon-controller #1912

addon-controller: Three ClusterSummary Reconcile Bugs
A transient, non-NotFound error checking whether a cluster still exists was treated as "cluster present," which could stall a ClusterSummary in Terminating indefinitely. One cluster's stale ResourceSummary cleanup could be blocked by an unrelated cluster's same-named ResourceSummary. And Helm chart downloads via LocateChart had no timeout and could wedge a deployer worker permanently.
PR: addon-controller #1918

Expired Kubeconfig Tokens Not Evicted From Cache
An expired token only surfaces on first actual use of a cached client, not when the client is built, so classifier, event-manager, and healthcheck-manager kept retrying the same stale credentials indefinitely. The client is now evicted from cache on an auth error so the next cycle rebuilds it from a freshly read kubeconfig Secret.
PRs: event-manager #512, classifier #500, healthcheck-manager #424

healthcheck-manager: Notification Events Truncated to Kubernetes' Limit
Notification Event messages could exceed the 1024-character limit Kubernetes enforces on Event messages; they're now truncated to fit.
PR: healthcheck-manager #425

---

🔧 Maintenance

• All components advanced to Cluster API v1.14.0
• All components advanced to Go 1.26.6

Upgrade note: sveltos-license Secret managed via GitOps

Starting in this release, addon-controller's Secret cache is scoped to type: addons.projectsveltos.io/cluster-profile, so any other Secret type, including the sveltos-license Secret, which older installs created as Opaque, becomes invisible to it and every license check (JobCheck, ClusterPromotion) silently fails. register-mgmt-cluster now migrates an existing sveltos-license Secret to the correct type automatically on upgrade, no action needed for most installs.

If you manage sveltos-license through GitOps (Flux, ArgoCD, or similar) rather than applying it directly, update your source manifest's type field to addons.projectsveltos.io/cluster-profile as part of upgrading to this release. type is immutable on a Secret, so your GitOps tool can't reconcile this change in place: with the default sync settings it will just report a permanent "field is immutable" error on this one resource (harmless — the migration already fixed the live Secret, license checks keep working). But if you have force-recreate-on-drift enabled (Flux's force annotation, ArgoCD's Replace/forced ServerSideApply), your GitOps tool will instead recreate the Secret back to Opaque on its own reconcile schedule, silently breaking license checks again shortly after the upgrade until updated in Git.