Description
operator-render (the CLI that renders a DatadogAgent CRD into the plain Kubernetes manifests the Operator would apply, without needing a live cluster) is very useful for generating documentation/examples and for CI checks that diff rendered output. Today the only way to get it is to clone the repo and run make build-renderer yourself.
It would help downstream consumers a lot if prebuilt operator-render executables were published as release artifacts (e.g. attached to GitHub Releases, one per OS/arch, alongside the existing datadog-operator/datadog-operator-init release binaries), instead of requiring a local build.
Why
We use operator-render in a Makefile target to keep a set of example DatadogAgent manifests up to date in DataDog/opentelemetry-examples (see guides/kubernetes/configuration/opentelemetry-kube-stack/Makefile). Building it locally has a couple of rough edges that a published binary would sidestep:
- It requires a full
git clone of datadog-operator plus a Go toolchain just to render a single YAML file — heavier than the task needs.
- The binary bakes an absolute, compile-time path to the DDAI CRD YAML file into itself (via
runtime.Caller), so it only works when run from the exact same filesystem path it was built in/against. Building it in one location (e.g. a scratch clone) and copying the binary elsewhere breaks it with an error like:
error: reading DDAI CRD at /path/from/build/time/config/crd/bases/v1/datadoghq.com_datadogagentinternals.yaml: open ...: no such file or directory
go:embed rather than a runtime.Caller-derived path, if that's not already the case) would avoid this footgun entirely for anyone consuming the tool rather than developing the Operator itself.
Suggested solution
- Add
operator-render to the project's release pipeline so a binary per OS/arch is published for each datadog-operator release (GitHub Release assets, similar to how other Operator binaries are distributed).
- If not already the case, embed the CRD YAML(s)
operator-render reads (e.g. via go:embed) instead of resolving them from a runtime.Caller-derived filesystem path, so the published binary is portable and doesn't depend on where/how it was built.
Description
operator-render(the CLI that renders aDatadogAgentCRD into the plain Kubernetes manifests the Operator would apply, without needing a live cluster) is very useful for generating documentation/examples and for CI checks that diff rendered output. Today the only way to get it is to clone the repo and runmake build-rendereryourself.It would help downstream consumers a lot if prebuilt
operator-renderexecutables were published as release artifacts (e.g. attached to GitHub Releases, one per OS/arch, alongside the existingdatadog-operator/datadog-operator-initrelease binaries), instead of requiring a local build.Why
We use
operator-renderin a Makefile target to keep a set of exampleDatadogAgentmanifests up to date in DataDog/opentelemetry-examples (seeguides/kubernetes/configuration/opentelemetry-kube-stack/Makefile). Building it locally has a couple of rough edges that a published binary would sidestep:git cloneofdatadog-operatorplus a Go toolchain just to render a single YAML file — heavier than the task needs.runtime.Caller), so it only works when run from the exact same filesystem path it was built in/against. Building it in one location (e.g. a scratch clone) and copying the binary elsewhere breaks it with an error like:go:embedrather than aruntime.Caller-derived path, if that's not already the case) would avoid this footgun entirely for anyone consuming the tool rather than developing the Operator itself.Suggested solution
operator-renderto the project's release pipeline so a binary per OS/arch is published for eachdatadog-operatorrelease (GitHub Release assets, similar to how other Operator binaries are distributed).operator-renderreads (e.g. viago:embed) instead of resolving them from aruntime.Caller-derived filesystem path, so the published binary is portable and doesn't depend on where/how it was built.