Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generate: Introduce provider-dir flag #259

Merged
merged 3 commits into from Jun 7, 2023
Merged

generate: Introduce provider-dir flag #259

merged 3 commits into from Jun 7, 2023

Conversation

bflad
Copy link
Member

@bflad bflad commented Jun 6, 2023

Closes #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:

$ 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"

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"
```
@bflad bflad added the enhancement New feature or request label Jun 6, 2023
@bflad bflad added this to the v0.15.0 milestone Jun 6, 2023
@bflad bflad requested a review from a team as a code owner June 6, 2023 18:12
Copy link
Member

@austinvalle austinvalle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only one documentation related note. Good stuff! 🚀

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 later os.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) to os.Getwd() and removing the later os.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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can change this up afterwards, if you have any further thoughts!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

@bendbennett bendbennett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@bflad bflad merged commit fe6bf46 into main Jun 7, 2023
5 checks passed
@bflad bflad deleted the bflad/change-directory branch June 7, 2023 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Have a go run compatible workflow
3 participants