feat: add support for multiple inline templates

[doxsch]

Description of your changes

This PR introduces support for multiple inline templates to improve maintainability and scalability when using source: Inline.

Fixes #104

I have:

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

[doxsch]

I see that the previously missing code fragments for Pull Request #488 have now been generated and included. Can these remain, or should I revert them?

[bobh66]

@doxsch thanks for the contribution. Can you provide some context around how this would be used in practice? I'm not very familiar with kustomize and I don't see it being executed here so I'm wondering if it is being called in a pipeline or gitops controller like Argo? Thanks

[bobh66]

I see that the previously missing code fragments for Pull Request #488 have now been generated and included. Can these remain, or should I revert them?

Why do they need to be reverted?

[doxsch]

@doxsch thanks for the contribution. Can you provide some context around how this would be used in practice? I'm not very familiar with kustomize and I don't see it being executed here so I'm wondering if it is being called in a pipeline or gitops controller like Argo? Thanks

In our case, it will be Argo CD that runs kustomize build before applying. However, this would work just as well in a pipeline by using either kustomize build or kubectl apply -k.

I see that the previously missing code fragments for Pull Request #488 have now been generated and included. Can these remain, or should I revert them?

Why do they need to be reverted?

I was just wondering if it might make sense to submit this separately, since it’s not really related to the actual feature.

[bobh66]

In our case, it will be Argo CD that runs kustomize build before applying. However, this would work just as well in a pipeline by using either kustomize build or kubectl apply -k.

Ok so this is a way of allowing kustomize to generate a list of templates during composition reconciliation and then the function concatenates the templates at runtime.

Out of curiosity - have you considered using the source: Environment option to read templates, and have kustomize manipulate the content of a source EnvironmentConfig? I don't know if that's less work overall?

[doxsch]

In our case, it will be Argo CD that runs kustomize build before applying. However, this would work just as well in a pipeline by using either kustomize build or kubectl apply -k.

Ok so this is a way of allowing kustomize to generate a list of templates during composition reconciliation and then the function concatenates the templates at runtime.

Kustomize is executed before kubectl apply. This means the composition already contains a fully rendered list of templates; it does not happen during composition reconciliation.

Out of curiosity - have you considered using the source: Environment option to read templates, and have kustomize manipulate the content of a source EnvironmentConfig? I don't know if that's less work overall?

Yes, I looked into that option. However, I think the approach with directly use Kustomize is simpler.

[bobh66]

Kustomize is executed before kubectl apply. This means the composition already contains a fully rendered list of templates; it does not happen during composition reconciliation.

And they get concatenated into a single template by the function.

Yes, I looked into that option. However, I think the approach with directly use Kustomize is simpler.

Simpler from the kustomize side but at the expense of a slightly more complicated API on the function side. I'm going to ask the other maintainers to weigh in on whether the API change is acceptable. I feel like it makes the function API less clean and I'm not sure that's warranted when there is another solution available. I'm not saying no, just asking for other opinions. @negz @sergenyalcin @turkenf ?

[bobh66]

@ezgidemirel @phisco any opinions?

[ezgidemirel]

Since the function isn’t meant to be a full templating engine, I like the idea of handling more complex cases with external tools like kustomize and passing the rendered output into the function. This keeps the function simple while still giving users room to scale.

I agree that this change adds some API complexity, but I think that can be addressed with clear documentation and guidance around when to use each approach.