Proposal on improvements for provider-template

[cychiang]

What are current challenges for using provider-template

I spent some time to dogfooding the provider-template with the current setup, and there are a few points I would like to bring up and improve them.

• A few manual steps are required to make it works. For example, in order to initialize the generated repository, you will not only need to run Makefile to change some predefined names in one or more places. For example, go.mod, Makefile itself and the apis folder for changing repository name.

• Instead of maintaining ready-to-work example provider, it would be reasonable to make it templated through go-templating or similar approach already introduced under hack/helpers. I believe the concept of ready-to-work provider is to show case the provider-template trying to demonstrate but importantly it's to make it friendly and extendable for anyone who interested in developing their own provider for Crossplane. Ideally, we can extent what exists in hack/heplers, and let it be able to bootstrap the whole go code like go.mod, Makefile, apis, internal, cmd and so on kind of like upjet is doing. By doing this, we're able to make sure whoever using the template can always bootstrap a clean and ready-to-go provider with bare minimal setup.

• Currently, provider-template is targeting Crossplane v1, but in the foreseeable future, we might need to support v2 for namespaced resources.

Proposed improvements

• Extend hack/helpers to be able to support not only for an API GVK, but also for other things like cmd, go.mod and maybe Makefile. So we can skip some manual steps, and let the tool do the job
• Explorer an implementation for Crossplane v2, the provider-template after this should be able to generate a provider for either v1 or v2.

[jbw976]

i like the spirit of this idea @cychiang, thanks for taking the initiative on it! I like the idea of having more things templated, which means that people that start from this template repo will have less updates they need to make manually to get to success.

One question comes up for me though: how would we ensure over time that this repo is functional? the more that gets templated the further away you are from a repo that you can build and test easily. Perhaps part of the testing will be executing the templates so they have resolved values, and then build/test from that - so it's not insurmountable, just something to think though more 😇

otherwise, this seems like a great idea!