Support read/write from/to pipeline context

[fernandezcuesta]

What problem are you facing?

As a user I expect function-kro to be able to access the pipeline context.
I see two gaps:

• Reading context in templates.

  Users who place function-kro after function-environment-configs (or any function that populates a context) cannot reference those values in their resource templates, includeWhen, readyWhen, or forEach expressions. They must instead copy environment data into the XR spec/status via an earlier function, creating unnecessary coupling.

• Writing context for downstream functions.

  function-kro may resolves values that downstream pipeline functions could use.
  There is no mechanism to publish those values back to the context.

How could this Function help solve your problem?

Reading from context could look like the following snippet:

resources:
  - id: bucket
    template:
      apiVersion: s3.aws.m.upbound.io/v1beta1
      kind: Bucket
      spec:
        forProvider:
          region: ${context["apiextensions.crossplane.io/environment"].region}
  - id: logging
    includeWhen:                                          
      - ${context["foo/bar"].enableLogging == true}
    template: [...]

Writing to the context could look like a context field in the ResourceGraph spec:

apiVersion: kro.fn.crossplane.io/v1beta1
kind: ResourceGraph
context:
  "foo/bar":
    bucketArn: ${bucket.status.atProvider.arn}
  resources:
    - id: bucket

[bobh66]

I was thinking about this as well - it would be interesting to be able to generate a function-kro input graph using go-templating, to handle situations like conditional attributes and other logic that is possible in go-templating but not in kro (that I can see, anyway).

[fernandezcuesta]

I think for conditional attributes you can just use null, e.g.:

permissionsBoundary: ${has(schema.spec.parameters.permissionsBoundary) ? schema.spec.parameters.permissionsBoundary : null}

[jbw976]

Thanks for sharing this idea @fernandezcuesta! 🙌

I spent a bit of time digging into what it would take to support this with my buddy Claude. It's definitely a good idea from a DevEx and interopability perspective within the Crossplane function ecosystem - but it's got some challenges to overcome that are specific to function-kro unfortunately.

The other functions that support context (function-go-templating, function-kcl, function-cel-filter, etc.) own their evaluation engine. They just pass req.GetContext() into their template environment as a native variable and everything works in one pass — maps, lists, deeply nested objects, all handled natively by the engine.

function-kro is different because we use KRO's graph builder and runtime for CEL compilation and evaluation. KRO's CEL environment is statically constructed at graph build time — every valid identifier must be registered upfront for compilation, AST inspection, and DAG construction. If you write ${context["env"].region} and context isn't in that known set, the expression fails at compile time. Go's text/template and KCL don't have this constraint; they're dynamically scoped, so you can hand them arbitrary data at evaluation time and it just works. KRO's static approach is what enables its compile-time type checking and cycle detection, but it also means you can't sneak new variables in without the builder knowing about them.

We're actively trying to minimize divergence from upstream KRO so we can eventually consume it as a dependency rather than vendoring it. Adding context as a CEL variable touches a handful of places inside KRO's core - not a massive change, but it would be Crossplane-specific concepts leaking into upstream KRO libraries.

I've looked at a few approaches that avoid modifying KRO code, and none are great:

• Pre-process context references before KRO sees them. Works for simple scalars like region: ${context["env"].region}, but context data is often maps, lists, nested objects. Pre-processing would mean reimplementing KRO's resolver logic just for context references. It also can't handle mixed expressions like ${context["env"].region + "-" + schema.spec.name}.

• Propose a generic extension point upstream to KRO. a generic way for consumers/hosts of the KRO runtime to injecting additional variables into the CEL environment. Not Crossplane-specific; KRO's own controller could use it too. Probably the right long-term answer, but requires work to push that within the upstream KRO community.

So after looking into it a bit, there doesn't seem to be a clear cut easy path forward here - this may just be a limitation of function-kro for the time being versus the rest of Crossplane's function ecosystem...open to other thoughts though!