clarify how to regenerate kcl modules

[dansrogers]

Feature Request

Is your feature request related to a problem? Please describe:

I'm trying to understand how to regenerate these module bindings for any given module. It seems ambiguous how any given module is generated.

Describe the feature you'd like:

A repeatable automation step to regenerate a module against a specific upstream version and documentation on how to call that.

Also a gitworkflow that generates new versions automatically would be nice to have.

Describe alternatives you've considered:

There is no clear alternative, sadly. crossplane, in particular, seems problematic as it has a file containing all crossplane resources that the bindings are generated against.

Teachability, Documentation, Adoption, Migration Strategy:

[Peefy]

cc @zong-zhe

[dansrogers]

After my experience with crossplane -- the generation step is currently dependent on docs.crds.dev, and it's not clear how to update that, if needed.

My crossplane module update PR proposes an alternative strategy based on helm, kind, and kubectl, but that probably requires some work to generalize -- it does however not require docs.crds.dev to be updated before a kcl module can be updated.

[dansrogers]

How do folks feel about something like https://github.com/earthly/earthly? for specifying module build targets? I could code up something based on my crossplane module rebuild experience.

[Peefy]

Hello @dansrogers

Do you mean to use Earthly to write some code for building KCL modules? Of course, we will also provide clearer guidance from KCL's own tools and documentation.