* Update protoc version in downloader script
* go get google.golang.org/grpc/cmd/protoc-gen-go-grpc v1.5.1
This matched terraform-plugin-go
* make protobuf
* Run `make protobuf`
* Update generator to handle generic types from google.golang.org/grpc
Looks like this was added in v1.69.3 in https://github.com/grpc/grpc-go/pull/7057 ?
* Run `make generate`
* Fix "cannot infer Res" compile error - more usage of generics
* More fixing compile errors due to switching to use of a generic
* Make putting `google.golang.org/grpc` import into generated files conditional
* Run `make generate`
* Update more places where generics now need to be used
* Update generator to handle any types from google.golang.org/grpc in same switch case.
* Remove `require_unimplemented_servers=false` option when generating code from proto files. Run `make protobuf`.
This allows require_unimplemented_servers to default to true, and the generated code shows the impacts of that.
* Update generator script to embed 'UnimplementedFoobarServer' structs and skip generating code for the `mustEmbedUnimplementedFoobarServer` method that is implemented via that embedding.
* Run `make generate`
* Embed UnimplementedProviderServer into implementations of ProviderServer
* Embed UnimplementedProvisionerServer into implementations of ProvisionerServer
* Reformat Args in steps definitions
* Swap to using the new version of protoc-gen-go that doesn't include grpc support (instead it relies on protoc-gen-go-grpc).
Update command flags to reflect this change in tooling.
See this comment for explanation: https://github.com/golang/protobuf/issues/1070#issuecomment-607293496
* Run `make protobuf` with problem generate steps commented out.
* Use `require_unimplemented_servers=false` to minimise changes at the time of upgrading tooling
In future we can navigate the consequences of this in its own PR.
* WIP
* Fix out/opt typo, add remaining flags once terraform1.proto was being found ok
* Run `make protobuf`
* `go get google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.3.0` && `go mod tidy`
This version includes a feature that allows the copyright comment in the .proto file to be pulled across to generated _grpc.pb.go files.
* Run `make protobuf` with new version of protoc-gen-go-grpc that allows copyright comment to be copied to generated output files
* Potential fix for `internal/rpcapi/dynrpcserver/generator`
* go get github.com/hashicorp/go-azure-helpers@v0.72.0
* .go-version to 1.24.1
* Run `./scripts/syncdeps.sh`
This propagates the Go version upgrade
* gcs : go get google.golang.org/api@v0.155.0
* gcs: go mod tidy
* Run `./scripts/syncdeps.sh`
* make generate && make protobuf
Many of the changes between these two versions seem to be in parts of the
library that Terraform doesn't use, but there are a few sensitive parts:
- Slight changes to details of how the library implements the JSON
encoding of protobuf. Terraform CLI/Core don't use this, but some
of the backends might use it indirectly when talking to their
underlying APIs.
- Some details of the "protoreflect" package for working with
protobuf descriptors dynamically (rather than using generated stubs)
have changed, but it seems pretty marginal and unlikely to cause
problems.
- The cloud plugin wants a go-tfe client to get stuff from TFC.
- Terraform knows how to find all the info you need in order to configure a
go-tfe client, but it's sometimes scattered across configs and env vars and
credentials helpers, and trying to re-implement the resolution logic identically
in another codebase would be error-prone.
- Therefore, it'd be best if Terraform did that resolution and just passed the
plugin all the config info it needs.
There are two options for that handoff:
1. Adding it as an additional argument to the primary Execute RPC interface.
2. Passing it as gRPC metadata, which is a pile of arbitrary key => list-of-strings
pairs transmitted via HTTP/2 headers.
The crux of the decision here is whether a proliferation of plugin protocol
versions whenever we need to add more config data is better or worse than a
fuzzy and typeless key/value bag.
This PR is an implementation of option 2, for discussion and evaluation. (And
after all, this is considered an experimental feature anyway.) It assembles the
necessary information, translates it to the required metadata format, and
attaches it to the request at the proper moment to get everything over to the
plugin.
As previous commits foreshadowed, we're leaning on the existing logic in the
Cloud backend for pretty much all of this.
Currently, Terraform will only run properly signed versions of the experimental
cloud plugin that were downloaded from a TFC instance that provides the
appropriate service. That obstructs development on new cloud plugin features!
Our internal teams will need a "dev override" capability, like what we offer
provider authors.
However, unlike with providers, we don't have to integrate this into a
heterogeneous mix of sources for mirroring and caching a wide range of binaries.
There's only one cloud plugin, HashiCorp controls it, and end users should never
need to override the location of the binary for non-development reasons.
Thus, we have the luxury of being quite a bit stupider in how we handle the
override signal. Instead of adding it to the CLI config file schema, we'll just
use a single environment variable whose value is the path to an alternate
binary.
Enter: `TF_CLOUD_PLUGIN_DEV_OVERRIDE`.
Changes the release manifest format to more closely match the releases API V1 (example https://api.releases.hashicorp.com/v1/releases/terraform-cloudplugin/0.1.0-prototype)
- The new format doesn't carry the SHASUM for each build, so it made the matching_sums check in releaseauth redundant.
- Added tests for checksum parsing
- Added ID-based selection of signature file
Adds a client that encapsulates the process of downloading a cloudplugin manifest from a Terraform Cloud, downloads the appropriate binary to the specified location, and validates that it was distributed by HashiCorp
