PseudoDynamic.Terraform.Toolset, a new way to write Terraform provider plugins in C#

Terraform Providers Plugin Development
1

Hey, I want to announce that PseudoDynamic.Terraform.Toolset is a new fancy way to write Terraform provider plugins in C#.

At the date of now, the first alpha version has been just released. Here you can read how to use it.

I am open for your feedback. :slight_smile:

2

By the way. Could @bflad or anyone else explain me how the registry recognizes possible packages from github artifacts? I mean, Goreleaser produces the following artifacts:

terraform-provider-<provider-name>_<version>_darwin_amd64.zip
terraform-provider-<provider-name>_<version>_darwin_arm64.zip
terraform-provider-<provider-name>_<version>_freebsd_386.zip
terraform-provider-<provider-name>_<version>_freebsd_amd64.zip
terraform-provider-<provider-name>_<version>_freebsd_arm.zip
terraform-provider-<provider-name>_<version>_freebsd_arm64.zip
terraform-provider-<provider-name>_<version>_linux_386.zip
terraform-provider-<provider-name>_<version>_linux_amd64.zip
terraform-provider-<provider-name>_<version>_linux_arm.zip
terraform-provider-<provider-name>_<version>_linux_arm64.zip
terraform-provider-<provider-name>_<version>_SHA256SUMS
terraform-provider-<provider-name>_<version>_SHA256SUMS.sig
terraform-provider-<provider-name>_<version>_windows_386.zip
terraform-provider-<provider-name>_<version>_windows_amd64.zip
terraform-provider-<provider-name>_<version>_windows_arm.zip
terraform-provider-<provider-name>_<version>_windows_arm64.zip

Are there any rules, constraints I need to respect? I foremost want to know, if someone needs to provide/support all architectures that are listed above to make the Terraform provider registry happy? Just for reference: .NET supports the following target runtimes: .NET Runtime Identifier (RID) catalog | Microsoft Learn

3

I also opened an issue here: Support external provider binaries that are not built by go · Issue #195 · hashicorp/terraform-plugin-docs · GitHub for having increased support for tfplugindocs. Would be nice to get feedback on that too. :slight_smile:

4

Are there any rules, constraints I need to respect? I foremost want to know, if someone needs to provide/support all architectures that are listed above to make the Terraform provider registry happy?

I really would like to know some details or context about this. Any chance @bflad, or someone else?

5

I do not believe the public Terraform Registry imposes minimum requirements for supported operating system and architectures on provider release ingest at this time, although I will say that a “base” set of these is likely expected by the ecosystem (in Go-based platform terms) due to their prevalence in Terraform development and execution environments:

  • darwin/amd64 (Intel-based macs, although diminishing over time)
  • darwin/arm64 (Apple silicon-based macs)
  • linux/amd64 (also the standard Terraform Cloud runner)
  • windows/amd64

Most of the provider ingress validation logic is around ensuring the trust chain (e.g. checksums and signature) is okay. The provider release asset filename checking/parsing is terraform-provider-<NAME>_<VERSION>_<OS>_<ARCH>.(.zip|.tar.gz). The checksum release asset must be terraform-provider-<NAME>_<VERSION>_SHA256SUMS, the signature release asset must be terraform-provider-<NAME>_<VERSION>_SHA256SUMS.sig, and the manifest release asset must be terraform-provider-<NAME>_<VERSION>_manifest.json.