minamijoyo / tfupdate

Update version constraints in your Terraform configurations
MIT License
539 stars 23 forks source link

Using a non-official provider, tfupdate need to pass different parameters in `provider` and `release` subcommands. #65

Closed kangaechu closed 2 years ago

kangaechu commented 2 years ago

I am planning to update "integrations/github" provider version.

To get the latest version of the provider, I ran the following command.

$ docker run -it --rm minamijoyo/tfupdate release latest integrations/github -s tfregistryProvider
4.19.2

To update the provider version, I ran the following command, but tf file was not changed.

docker run -it -v $(pwd):/src --rm minamijoyo/tfupdate provider integrations/github -v 4.19.2 /src/config.tf

The update, provider version, I needed to specify github instead of integrations/github.

docker run -it -v $(pwd):/src --rm minamijoyo/tfupdate provider github -v 4.19.2 /src/config.tf

This doesn't seem to be consistent with the command options, what do you think?

(Addition)

When updating the provider without specifying the version, the following error occurred.

$ docker run -it -v $(pwd):/src --rm minamijoyo/tfupdate provider github /src/config.tf

no releases found
minamijoyo commented 2 years ago

@kangaechu Good point!

I agree with you. It looks inconsistent due to some historical reasons. Let me share the current context first.

Historically, the tfupdate was wrote in the era of Terraform v0.12. At that time, the Terraform Registry was dedicated to modules and providers were distributed from hashicorp's release server via undocumented protocol. So, it was a reasonable design to check the latest version from GitHub release of the provider's source code repository.

Terraform v0.13 introduced a hierarchical namespace and allowed 3rd-party to distribute providers from the registry. Even at this point, the github provider was maintaining on github.com/terraform-providers/terraform-provider-github as an official provider, so this worked fine.

Later, at some point, it was transferred to github.com/integrations/terraform-provider-github, becoming an unofficial verified provider maintained by GitHub as a partner instead of HashiCorp.

However, there seems to be a problem with the transfer method of the GitHub repository, and the redirect behavior is slightly different from other providers that have also become unofficial. Unfortunately github.com/terraform-providers/terraform-provider-github => github.com/integrations/terraform-provider-github is not automatically redirected. See also #28.

As you know, the tfupdate release command supports the Terraform Registry with --source-type tfregistryProvider, which allow us to get the release version from Terraform Registry, but the current implementation of the tfupdate provider command implicitly assumes the --source-type=github and doesn't support namespace. As a result, we can no longer find a release of the github provider depending on redirect. That's why it's inconsistent.

At time of this writing in the era of Terraform 1.1, it's more natural that we should treat the Terraform Registry as a first class. That is to say, the tfupdate provider command should check the Terraform Registry instead of the GitHub release. It would need some works, and I haven't found the time to implement it, but I think it should be.

Thanks!

kangaechu commented 2 years ago

Thank you for replying!

At time of this writing in the era of Terraform 1.1, it's more natural that we should treat the Terraform Registry as a first class. That is to say, the tfupdate provider command should check the Terraform Registry instead of the GitHub release.

I'm agree with this plan. It would be nice if this modification will be implemented.

minamijoyo commented 9 months ago

FYI: Starting from v0.8.0, the tfupdate provider command now supports namespaces via #102.