feat(helm): add extraObjects for arbitrary manifests

[younsl]

Summary

Adds an optional top-level extraObjects value that renders arbitrary Kubernetes manifests within the kagent chart. It is empty by default so existing installs stay unaffected. Each entry is rendered through tpl so values can reference the release context such as {{ include "kagent.fullname" . }} or {{ .Release.Namespace }}. Both map and multi-line string entries are supported.

This lets users manage companion resources like ExternalSecret or HTTPRoute in the same chart lifecycle. It follows a common pattern used by community charts such as:

• grafana
• kube-prometheus-stack
• external-secrets

Changes

• New template templates/extra-objects.yaml ranging over .Values.extraObjects (default []).
• Documented extraObjects in values.yaml with an ExternalSecret example.
• Added helm-unittest suite tests/extra-objects_test.yaml.

Testing

helm unittest helm/kagent passes. The new suite covers the empty default map entries multiple documents tpl evaluation against the release context and multi-line string entries.

Notes

This change was originally intended for #2165 but was split into its own PR at a maintainer request so each concern can be reviewed on its own.

[Copilot]

Pull request overview

Adds a new Helm chart capability to render user-supplied, arbitrary Kubernetes manifests alongside the kagent chart via a top-level extraObjects value, enabling companion resources (e.g., ExternalSecret, HTTPRoute) to be managed in the same release lifecycle.

Changes:

• Introduces extraObjects (default []) in values.yaml, with documentation and an example.
• Adds a new Helm template to render each extraObjects entry via tpl (supporting both map and multi-line string entries).
• Adds a helm-unittest suite covering empty/default behavior, multiple docs, tpl evaluation, and string entries.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
helm/kagent/values.yaml	Documents and introduces the extraObjects top-level value with an example manifest.
helm/kagent/templates/extra-objects.yaml	Implements rendering of arbitrary user manifests through tpl for both map and string entries.
helm/kagent/tests/extra-objects_test.yaml	Adds unit tests validating rendering behavior and templating against release context.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[younsl]

@EItanya PTAL

[EItanya]

Personally this feels like a weird pattern to me. I'd be interested to hear how other projects and other systems are dealing with this problem today.

[younsl]

Fair question. This mirrors an established Helm pattern: a top level list rendered through tpl, used for companion resources like ExternalSecret, HTTPRoute, Istio DestinationRule, or NetworkPolicy that need to share the release lifecycle.

Many popular community Helm charts follow this pattern through values named like extraObjects or extraManifests. A few examples with the same shape:

• Argo CD extraObjects
• kube-prometheus-stack extraManifests
• Bitnami extraDeploy

The alternative is a second chart, which duplicates values, needs its own helm upgrade, and can drift from the app version. extraObjects keeps them atomic.

Happy to rename to extraDeploy or extraManifests for familiarity if you prefer. Let me know.

[younsl]

For context on my own use case: I needed to manage a separate HTTPRoute resource for the kagent UI as part of the same kagent chart release, rather than maintaining it in a detached manifest or a second chart. extraObjects lets that HTTPRoute live and upgrade alongside the app it fronts.

[EItanya]

Ok that all makes sense, I’ll do a little more research of my own. Since we merged that other HTTPRoute helm change do you still need this PR?

[younsl]

Thanks for looking into this. I think it is still worth keeping. The HTTPRoute change covers UI routing, but extraObjects is the general way to add other related resources that may not each need their own value.

A couple of cases I have in mind:

• A PrometheusRule handled by the Prometheus Operator, so kagent's alerts upgrade together with the app instead of living in a separate file.
• The NetworkPolicy from Secure the kagent UI #2028 for locking down the UI, which users could add right away without a dedicated value.

Adding a new value for every resource type does not scale well, while extraObjects stays generic. That said, I am happy to follow your call if you prefer a different direction.