feat(helm): dynamically set ateomImage based on substrate dependency version

[entee28]

This PR closes #2491

[Copilot]

Pull request overview

This PR updates the kagent Helm chart to avoid requiring users to manually set substrateWorkerPool.ateomImage in the common case, by attempting to derive a default image tag from the chart’s substrate dependency version.

Changes:

• Add documentation in values.yaml indicating that an empty substrateWorkerPool.ateomImage should default based on the chart’s substrate dependency version.
• Update templates/substrate-workerpool.yaml to compute $ateomImage dynamically from the substrate chart dependency version and use it in the rendered WorkerPool.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
helm/kagent/values.yaml	Documents that substrateWorkerPool.ateomImage may be left empty to default based on the substrate dependency version.
helm/kagent/templates/substrate-workerpool.yaml	Implements dynamic ateomImage derivation from the substrate chart dependency version, falling back to a fail when no default can be determined.

Suppressed comments (1)

helm/kagent/templates/substrate-workerpool.yaml:17

• This defaulting relies on finding the substrate subchart in .Chart.Dependencies, but the substrate dependency is conditioned on substrate.enabled (helm/kagent/Chart-template.yaml:14) and substrate.enabled defaults to false (values.yaml:669-671). In setups where substrate isn’t bundled as a subchart, $ateomImage may remain empty and hit this fail, which conflicts with the intent of closing #2491. Consider deriving the pinned substrate dependency version from chart metadata (or otherwise providing a default) even when the subchart isn’t enabled, while still allowing users to override substrateWorkerPool.ateomImage explicitly.

  {{- fail "substrateWorkerPool.ateomImage is required when substrateWorkerPool.create=true and the \"substrate\" chart dependency isn't enabled (substrate.enabled=false) - set it explicitly to match your ate-system version" }}

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[EItanya]

What do you think about taking it from the go.mod version since they match? We can link it at buildtime with an ldflag

[entee28]

What do you think about taking it from the go.mod version since they match? We can link it at buildtime with an ldflag

Hi @EItanya , good catch — you're right it should come from go.mod. Couldn't figure out on how to use an ldflag here though, so I went with the build-time route this repo already has instead: SUBSTRATE_VERSION now also gets stamped into Chart.yaml's annotations via the same envsubst step that sets it for the substrate dependency.

Kept the fail for the substrate.enabled=false case — if ate-system is managed separately we don't actually know its version, so still want an explicit value there rather than guessing.