Proto commits in hashicorp/terraform-plugin-go

These 25 commits are when the Protocol Buffers files have changed:

2025-05-02

Update with latest protocol changes

2025-04-15

Update with latest protocol changes

2025-03-19

Initial Actions prototype implementation

2025-03-13

Updated protocol to reflect core changes to protocol move request (#487) * Updated protocol to reflect core changes to raw identity * RawIdentity Co-authored-by: Austin Valle <austinvalle@gmail.com> * RawIdentity Co-authored-by: Austin Valle <austinvalle@gmail.com> * Update tfprotov6/resource.go Co-authored-by: Austin Valle <austinvalle@gmail.com> * Update tfprotov5/resource.go Co-authored-by: Austin Valle <austinvalle@gmail.com> * Fixed bug from suggestions * Fixed bug from suggestions --------- Co-authored-by: Austin Valle <austinvalle@gmail.com>

The documentation is generated from this commit.

2025-02-10

tfprotov5: Resource Identity implementation (#474) * start writing files for v5 * add missing code comments * add new fields added by identity protocol changes made by core * add missing copywrite headers * remove traces of flatmap from copied file that were missed * put new rpc calls in separate interface * first bunch of tests for files that already existed (and some for new files that are helpers for the other tests in prior art only) * Added test files for toproto for tfprotov5 and started adding to logging. Also addressed renamed the file as per suggested in the previous PR. * Fixing typo * update attribute names to match latest protobuf schema * fix tests * add test for raw_identity (copied from state.go) * update to latest gprc schema used by core * remove ResourceIdentityContext as we don't need it * add attributes for new identity data added to the protocol recently * add comments and fix logging * Apply suggestions from code review --------- Co-authored-by: Ansgar Mertens <ansgar@hashicorp.com> Co-authored-by: Austin Valle <austinvalle@gmail.com>

Add protobuf support for resource identity messages and rpcs (#472) * Add protobuf support for resource identity messages and rpcs * add more identity procotol changes made by core * implement core change to rename prior_identity to planned_identity for ApplyResourceChange.Request

2025-02-05

add more identity procotol changes made by core

2025-02-04

Add protobuf support for resource identity messages and rpcs

2025-01-21

tfprotov5+tfprotov6: Write-only Attribute Implementation (#462) * Upgrade Go to `v1.22` * Add support for ephemeral resources in protocol version 6 * Add support for ephemeral resources in protocol version 5 * Add ephemeral resources field to `GetMetadata_Response()` * Update tfplugin5.proto and tfplugin5.proto to support write-only attributes and generate stubs. * Implement write-only attributes in `tfprotov5` and `tfprotov6` packages * Remove `State` field from `RenewEphemeralResource` RPC response and rename `PriorState` request fields to `State`. * Update tfplugin5.proto and tfplugin5.proto to support write-only attributes and generate stubs. * Implement write-only attributes in `tfprotov5` and `tfprotov6` packages * Update protobuf stubs after rebase * Increase protocol minor version for write-only attributes * switch interfaces to be optional * removed `config` from renew request * Update protocol bindings * remove ApplyResourceChange client capabilities + add server logging for validate resource config * Update `protoc` to `v29.3` in CI * Add changelog entry * Apply suggestions from code review Co-authored-by: Austin Valle <austinvalle@gmail.com> --------- Co-authored-by: Austin Valle <austinvalle@gmail.com>

2024-10-29

tfprotov5+tfprotov6: Initial ephemeral resource type implementation (#441) * Upgrade Go to `v1.22` * Add support for ephemeral resources in protocol version 6 * Add support for ephemeral resources in protocol version 5 * Add ephemeral resources field to `GetMetadata_Response()` * Remove `State` field from `RenewEphemeralResource` RPC response and rename `PriorState` request fields to `State`. * switch interfaces to be optional * removed `config` from renew request * update protocol to match core + added logging * Update protocol bindings * Add changelog entries * Fix comment wording based off of PR feedback --------- Co-authored-by: Austin Valle <austinvalle@gmail.com>

2024-05-06

tfprotov5+tfprotov6: Add deferred action support to related RPCs (#403) * generate protocol bindings * add protocol bindings to external interface * build(deps): Bump google.golang.org/grpc from 1.63.0 to 1.63.2 (#394) Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.63.0 to 1.63.2. - [Release notes](https://github.com/grpc/grpc-go/releases) - [Commits](https://github.com/grpc/grpc-go/compare/v1.63.0...v1.63.2) --- updated-dependencies: - dependency-name: google.golang.org/grpc dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * workflows: Remove wildcard suffix from Terraform workflow call (#395) * don't marshal integer values as msgpack floats (#396) * don't marshal integer values as msgpack floats Round-tripping a large integer through a float64, even if the binary representation is exact, causes us to end up with a rounded string representation after decoding, because the decoded number has 52-bit precision instead of the 512 we use when dealing with string representations of large integers. * update CHANGELOG.md * update to changie log --------- Co-authored-by: Austin Valle <austinvalle@gmail.com> * Update changelog * breaking: update protocol bindings for new client capabilities struct + add configure provider bindings * add Go pkg docs * add copywrite headers * add changelog * split client capabilities per RPC * added logging for req/resp deferred actions * add test for ensuring global variable is updated * add diagnostic for invalid deferred * move helper diag into function * add a separate log for nil client capabilities --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: James Bardin <j.bardin@gmail.com> Co-authored-by: hc-github-team-tf-provider-devex <github-team-tf-provider-devex@hashicorp.com>

2024-02-22

tfprotov5+tfprotov6: Replace usage of diagnostics in CallFunction RPC with function error (#380) * tfprotov5+tfprotov6: Replace usage of diagnostics in CallFunction RPC with function error Reference: hashicorp/terraform#34603 The next version of the plugin protocol (5.5/6.5) includes support for provider defined functions. This change modifies the response returned from the CallFunction RPC, replacing diagnostics with function error. * Fix protoc version * Add changelog * Removing function argument from diagnostics * Renaming param from msg to text for function errorr * Adding change log

2024-01-26

tfprotov5+tfprotov6: Include private state in MoveResourceState (#372) Reference: https://github.com/hashicorp/terraform/pull/34575 To match upstream changes. No changelog is necessary as this is unreleased.

2024-01-17

tfprotov5+tfprotov6: Initial MoveResourceState support (#364) Reference: https://github.com/hashicorp/terraform-plugin-go/issues/362 Reference: https://github.com/hashicorp/terraform-plugin-go/issues/363 The next version of the plugin protocol (5.5/6.5) includes support for moving resource state. This change introduces the initial implementation of that support including: - Updated Protocol Buffers definitions - Re-generated Protocol Buffers Go code - Initial implementations of `tfprotov5` and `tfprotov6` package abstractions and wiring between those abstractions and the Protocol Buffers generated Go code - Initial implementations of `tfprotov5/tf5server` and `tfprotov6/tf6server` for the new `MoveResourceState` RPC This temporarily will not require `ProviderServer` implementations to include `MoveResourceState` implementation, however that change will occur in a subsequent release.

2023-12-14

tfprotov5+tfprotov6: Initial provider defined functions implementation (#351) Reference: https://github.com/hashicorp/terraform/pull/34383 Reference: https://github.com/hashicorp/terraform-plugin-go/issues/353 The next version of the plugin protocol (5.5/6.5) includes support for provider defined functions. This change introduces the initial implementation of that support including: - Updated Protocol Buffers definitions - Re-generated Protocol Buffers Go code - Initial implementations of `tfprotov5` and `tfprotov6` package abstractions and wiring between those abstractions and the Protocol Buffers generated Go code - Initial implementations of `tfprotov5/tf5server` and `tfprotov6/tf6server` for the new `GetFunctions` and `CallFunction` RPCs This temporarily will not require `ProviderServer` implementations to include `FunctionServer` implementation, however that change will occur in a subsequent release.

2023-09-06

tfprotov5+tfprotov6: Update to protocol versions 5.4/6.4 with GetMetadata RPC and GetProviderSchemaOptional server capability (#311) Reference: https://github.com/hashicorp/terraform-plugin-go/issues/310 Protocol upgrades that impose new RPCs will either require: - The `tfprotov5.ProviderServer`/`tfprotov6.ProviderServer` interface to require a new method - Or, new "optional" interfaces be implemented (let's make up `ProviderServerWithGetMetadata` in this case) terraform-plugin-go is a low level abstraction which is designed to _directly implement_ the protocol rather than introduce its own abstractions. Most provider developers will directly interface with higher level Go modules, such as terraform-plugin-sdk and terraform-plugin-framework. Except for advanced provider development using this Go module directly, this type of low level "breaking" change will be hidden by also upgrading those Go modules at the same time: - https://github.com/hashicorp/terraform-plugin-sdk/pull/1235 - https://github.com/hashicorp/terraform-plugin-framework/pull/829 - https://github.com/hashicorp/terraform-plugin-mux/pull/186 Therefore the change is implemented on the existing interface.

2023-06-26

tfprotov5+tfprotov6: Add GetProviderSchema request fields for limiting resource schema data

2023-06-05

[COMPLIANCE] Add copyright and license headers (#292) * add copywrite changes * mod tidy? * add back to go mod + ignores * add --plan * add `make tools` * [COMPLIANCE] Add copyright and license headers * update protobuf GH workflow * add ignore to pb.go only * reverted back to the original protoc version * Update .copywrite.hcl Co-authored-by: Brian Flad <bflad417@gmail.com> --------- Co-authored-by: Brian Flad <bflad417@gmail.com>

2022-10-14

tfprotov5+tfprotov6: Synchronize Protocol Buffers comments for ReadResource and UpgradeResourceState (#231) Reference: https://github.com/hashicorp/terraform/pull/31998

2022-07-08

tfprotov5+tfprotov6: Support for Protocol Version 5.3 and 6.3 (#205) Reference: https://github.com/hashicorp/terraform-plugin-go/issues/204

2022-01-20

tfprotov6: Upgrade to Protocol Version 6.2 (#143) Reference: https://github.com/hashicorp/terraform-plugin-go/issues/142 Updated via: ```shell pushd tfprotov6/internal/tfplugin6 ./generate.sh popd ``` Terraform Plugin Protocol version 6.1 includes a deprecation of the `SchemaObject` `max_items` and `min_items` fields. While this package could transitively also deprecate the fields in its exported types, this opts to instead remove them completely since they never worked as intended. Terraform Plugin Protocol version 6.2 includes the `ApplyResourceChange.Response` and `PlanResourceChange.Response` message `legacy_type_system` field that was unintentionally missing from earlier versions. The `tfprotov6` types errantly already included the `UnsafeToUseLegacyTypeSystem` fields (copied from `tfprotov5`), which were never wired through the protocol because the protocol did not implement them. That field is now passed through the protocol in both directions.

2021-04-13

tfprotov6 (#71)

2020-10-06

Upgrade gRPC and protobuf versions. We're now generating our tfplugin5 package using libprotoc v3.13.0, protoc-gen-go v1.25.0, and protoc-gen-go-grpc v1.0. This required updating all our protocol conversions to use pointers instead of concrete values to make Go vet happy, as most request types in the generated tfplugin5 package now had sync.Mutexes in them, and go vet complained about us copying the sync.Mutex.

2020-08-20

Move tfplugin5 package under tfprotov5. There's no reason to top-level the generated gRPC types, they can live under the version-specific package.

Rough out the basic type system. This is basically just transcribing the generated gRPC types into types that we control. I still need to do the conversion for them. I changed GetSchema to GetProviderSchema, Stop to StopProvider, and Configure to ConfigureProvider, as all other RPC calls name the type of resource they're operating on. This may also provide a little forward compatibility if we introduce other plugin types to the protocol, e.g. backends. I'm still not sure how to represent state. In the gRPC generated types, it's just a *DynamicValue, which means "msgpack-encoded whatever that gets a second round of decoding", usually. So I need to figure out what it gets decoded into and replicate _that_, instead. I'm going back and forth on the Private []bytes. The protocol just requires you to echo them back, I believe, which we can do for users without them needing to deal with these weird opaque fields that they need to remember to return every time. But "minimal possible abstraction" has me questioning whether it's our place to do that or not. Representing cty is also something I need to figure out. Once again, its protocol definition is just a *DynamicValue, which only tells us that it will be decoded _again_ by the application, not what it's decoded into, which is what we want to surface. Should be easy enough to find, but it wasn't in front of my face in the protobuf definition, so I didn't include it in this pass. I have no idea why SchemaAttribute.Type is a []byte in the protobuf, and want someone to explain that to me and why it isn't, say, a string, so I can include it as a comment in the code, because that's bizarre. I made all the code happen in tfprotov5 instead of the root package or a tfproto package because I want to be able to have multiple major versions of the protocol in a single module version, so we don't have to do weird long-running branches to support v5 and v6 simultaneously if we ever have a v6. I used a system of composition to do some weird type stuff here. The ResourceServer and DataSourceServer interfaces handle all the RPC calls for a resource or a data source, respectively. This allows us to have helpers that just send resource calls to a resource type, so users don't _need_ to branch all their resources out of ApplyResourceChange or whatever. Then a ProviderServer embeds those interfaces, relying on all their methods, and adds the provider-specific ones. I also used this approach to create a BaseResourceServer, BaseDataSourceServer, and BaseProviderServer that handle their unique methods (BaseProviderServer anonymously embeds BaseResourceServer and BaseDataSourceServer) and return a "not implemented" error message. This is an idea I'm playing with for forward-compatible interfaces; a struct can anonymously embed these types, and it will automatically implement the interface, even if the interface expands underneath it. I'm not sure if this is better than a compile-time warning, or if we can provide reasonable default behavior for some or all of these methods, but it seemed like an idea worth trying.