Add support for a container image

[remyleone]

It would be helpful to run this program in a CI. Having a OCI image for it would be helpful :)

[bflad]

Hi @remyleone 👋

Can you walk through why a container is important for your CI workflow over standard Go buildchain tooling? Another consideration is that https://github.com/hashicorp/terraform-plugin-codegen-openapi would likely be separate in this model, since it has its own releases and use cases (as developers can bring in or make their own different spec source generators).

More commonly, we would anticipate that this Go module’s dependency would be tracked within another Go module (e.g. the provider codebase or a “tools” sub-module). At that point, it is a matter of go install github.com/hashicorp/terraform-plugin-codegen-framework/cmd/tfcodegen-framework so the CLI is installed with the declared version. Even without declaring the dependency in that manner, go install can still be used with @... appended with the latest keyword or a particular version tag. It's even possible to go run directly in many cases, where Go handles all the install and execution details.

Thanks!

[remyleone]

At the moment we handle most of our code generation using containers because they mix different languages and different toolchain (mostly protobuf). Therefore we handle most of our code generation in a CI pipeline with dedicated containers for each targets. I'm hoping that the next version of golang will bring improve support for tooling. If that would be the case then yes I would do the tfgen calls from the native golang toolchain.