[tenstad]

Description of your changes

Adds support for use of context values in templated resources, through schema.context.
Example: region: '${schema.context["apiextensions.crossplane.io/environment"].region'

Very useful when the value of a managed resource is determined by some other function. It can be some custom logic in e.g function-python, or reading in data with function-environment-configs. Then using that value when creating a resource in function-kro.

Function context is added to the XR, meaning function-kro can then not support XRs with a top leven context field of their own (as it would be overwritten).

Relates to #30

I have:

• Read and followed Crossplane's contribution process.
• Added or updated unit tests for my change.

[jbw976]

thanks for taking the initiative to explore and push more on function-kro could support context. clearly there is some community demand for this feature, so thanks for stepping up!

i spent some time on this today because i really want to avoid any changes to KRO at all to support this.

Check out #30 (comment) and let me know what you think. If you like that direction, you can take first crack here at the implementation (absolutely feel free to use my agent prompt gist) and keep driving since you are showing the initiative here! 🙇‍♂️

[tenstad]

Thank you for #30 (comment) @jbw976!

The issue has two parts, reading and writing context. The two parts can be implemented independently of each other. I've focused on reading in this PR, as it's quite a bit easier and more important IMO. Also, another function can independantly read observed resources and output values from them to context.

[jbw976]

Thank you for updating this PR to go in this direction @tenstad - seeing the diff be pretty minimal is encouraging and I'm feeling good about this being the right approach that is also cheap for us!

A few more feedback items to incorporate in addition to the inline comments:

• docs/examples: this new functionality should 100% get a new example added for it, it's great new functionality that people should have an example to see and follow. Add one under the example/ folder and follow the existing conventions/patterns there.
• we still have the first attempt of updating vendored KRO code in the commit history - no need to keep that, let's just remove it from the history completely, e.g. rebase/squash your commits to just the new approach
• just FYI, this new functionality is subject to issue #126 which I just opened. I don't think we need to solve it as part of this PR, but we'll want to fix that issue soon too, since I think context reading is probably one of the easier scenarios to make that accidental resource deletion happen 😂