render: Sync render.proto with c/c and wire XRD through#74
Conversation
Add composite_resource_definition (field 8) to CompositeInput, matching the upstream change in crossplane/crossplane. The field carries the XRD that defines the input XR so the render binary can pick the right composite.Schema (Legacy vs Modern) the way the production reconciler does. The field is optional, so existing callers keep their current SchemaModern fallback behavior. The cli's option go_package intentionally still points at github.com/crossplane/cli/v2/proto/render/v1alpha1, not the upstream path. Regenerated render.pb.go via ./nix.sh run .#generate using the Nix-pinned protoc-gen-go v1.36.10. Upstream: crossplane/crossplane@12f3f1c Upstream follow-up: crossplane/crossplane@babb251 Signed-off-by: Jonathan Ogilvie <jonathan.ogilvie@sumologic.com>
📝 WalkthroughWalkthroughThis PR extends the ChangesCompositeInput Schema Extension
🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 6✅ Passed checks (6 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Add XRD field to CompositionInputs so callers can pass a CompositeResourceDefinition to the render binary. BuildCompositeRequest copies it through to the proto's CompositeResourceDefinition field (added in the previous commit syncing render.proto). When no XRD is supplied behavior is unchanged (Schema=Modern fallback in the binary). Mirror of the Go-level change in crossplane/crossplane/cmd/crossplane/render to keep the CLI's CompositionInputs in sync with what the binary now consumes. Signed-off-by: Jonathan Ogilvie <jonathan.ogilvie@sumologic.com>
adamwg
left a comment
There was a problem hiding this comment.
lgtm, thanks for taking care of this.
|
Successfully created backport PR for |
Description of your changes
Two commits:
proto: Sync render.proto with crossplane/crossplane main— addscomposite_resource_definition(field 8) toCompositeInput, matching the upstream proto, and regeneratesrender.pb.govia./nix.sh run .#generate(Nix-pinnedprotoc-gen-gov1.36.10). The cli'soption go_packageintentionally still points atgithub.com/crossplane/cli/v2/proto/render/v1alpha1; after that one line the proto file is byte-identical to upstreammain.render: wire CompositionInputs.XRD through to the proto— adds anXRD *unstructured.Unstructuredfield toCompositionInputsand threads it throughBuildCompositeRequestto the proto'sCompositeResourceDefinition. When the caller leavesXRDnil, behavior is unchanged: the field stays unset and the render binary keeps itsSchema=Modernfallback. This mirrors the Go-level change incrossplane/crossplane/cmd/crossplane/renderso the cli'sCompositionInputsstays in sync with what the binary now consumes.Picking up an XRD from disk / the
--extra-resourcesflag and populatingCompositionInputs.XRDat the call sites (e.g.cmd/crossplane/render/xr/cmd.go) is intentionally out of scope here — that's a separate UX-shaped change. After this PR the plumbing is in place; the field is available to any caller that wants to use it.Upstream proto changes:
composite_resource_definitionsplural at the time)composite_resource_definition; this PR matches the post-feedback shape onmain)How this is covered by tests: regen is mechanical, and the wiring commit is pure plumbing — leaving
CompositionInputs.XRDnil produces the same proto request as before, so the existingcmd/crossplane/render/...tests cover the no-XRD path../nix.sh flake checkpasses.Fixes #
I have:
./nix.sh flake checkto ensure this PR is ready for review.Added or updated unit tests.Regen + nil-default plumbing; the existing render tests cover the unchanged no-XRD path. Happy to add a test that asserts the XRD-set path produces the populated proto field if reviewers want it.Linked a PR or a docs tracking issue to document this change.No user-facing change yet — this PR adds the proto field and theCompositionInputs.XRDplumbing; there's no command-surface change to document.AddedNot a backport candidate; happy to add a label if maintainers want it on a release branch.backport release-x.ylabels to auto-backport this PR.