generate: Introduce provider-dir flag #259
Conversation
Reference: #13 By default, the generator expects to be running in the root provider directory. The new `provider-dir` flag enables developers to run the command in any directory where the relative or absolute path is passed in as the base directory for all file operations for a provider codebase. All prior behaviors should be preserved, such as customizing via other flags like `examples-dir`. Due to lack of existing end-to-end testing (known technical debt), verified by locally compiling and running against existing HashiCorp-owned provider implementations which use `tfplugindocs` and by running the command in a subdirectory of hashicorp/terraform-provider-tls which has a mixture of custom and default templates and observed no changes or errors: ```console $ tfplugindocs generate -provider-dir=.. rendering website for provider "terraform-provider-tls" (as "terraform-provider-tls") copying any existing content to tmp dir exporting schema from Terraform compiling provider "tls" using Terraform CLI binary from PATH if available, otherwise downloading latest Terraform CLI binary running terraform init getting provider schema rendering missing docs generating missing resource content resource "tls_locally_signed_cert" template exists, skipping resource "tls_private_key" template exists, skipping resource "tls_self_signed_cert" template exists, skipping resource "tls_cert_request" template exists, skipping generating missing data source content resource "tls_certificate" template exists, skipping generating template for "tls_public_key" generating missing provider content provider "terraform-provider-tls" template exists, skipping rendering static website cleaning rendered website dir rendering templated website to static markdown rendering "data-sources/certificate.md.tmpl" rendering "data-sources/public_key.md.tmpl" rendering "index.md.tmpl" rendering "resources/cert_request.md.tmpl" rendering "resources/locally_signed_cert.md.tmpl" rendering "resources/private_key.md.tmpl" rendering "resources/self_signed_cert.md.tmpl" ```
README.md
Outdated
| --ignore-deprecated <ARG> don't generate documentation for deprecated resources and data-sources (default: "false") | ||
| --provider-dir <ARG> relative or absolute directory of provider code |
There was a problem hiding this comment.
Not sure if it'll be a pain to have this in the actual help CLI, but can we add some mention that it will default to the working directory here as well?
There was a problem hiding this comment.
I believe there's at least two options that are available to denote this with the standard "(default: xxx)" output of the --help flag:
- Changing the default value of the flag from
""(no default output) to"."and accounting for the new default in the lateros.Getwd()logic. I'm guessing most folks running a CLI tool may be familiar with that directory syntax, but maybe not all. - Changing the default value of the flag from
""(no default output) toos.Getwd()and removing the lateros.Getwd()logic. I'm guessing this could potentially be lengthy or confusing as it changes each directory the command is run in.
We could also consider just putting words there outside the (default: xxx) output that says something along the lines of "relative or absolute directory of provider code when running the command outside the root provider code directory".
Do any of these seem preferable to you?
There was a problem hiding this comment.
(I'm going to implement the last option as part of this PR right now, but if changing the default flag value makes sense, can certainly do that instead.)
There was a problem hiding this comment.
We can change this up afterwards, if you have any further thoughts!
There was a problem hiding this comment.
Sorry about the delayed response! I'm cool with what you ended with. I think it'd be neat to display the working directory as the default but I can't remember a CLI tool I've used that has done that before 🤔 (probably for the reasons you described).
There was a problem hiding this comment.
Nice job! 🚀
I've updated the PR that add compliance to the cloud-init provider using the sha from the most recent commit as an additional verification and everything looks great! Will amend to use tag once released.
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Closes #13
By default, the generator expects to be running in the root provider directory. The new
provider-dirflag enables developers to run the command in any directory where the relative or absolute path is passed in as the base directory for all file operations for a provider codebase. All prior behaviors should be preserved, such as customizing via other flags likeexamples-dir.Due to lack of existing end-to-end testing (known technical debt), verified by locally compiling and running against existing HashiCorp-owned provider implementations which use
tfplugindocsand by running the command in a subdirectory of hashicorp/terraform-provider-tls which has a mixture of custom and default templates and observed no changes or errors: