17 Commits (27770ee8053da48fbb684fd23d415aae376d2bed)

Author	SHA1	Message	Date
Sarah French	145e152a57	Clarify usage of BackendOpts, rename field in struct to enable usage with PSS in future (#37085) ... * Update comments to distinguish between operations and state-storage backends more clearly * Rename `BackendOpts` field `Config` to more specific `BackendConfig`	8 months ago
UKEME BASSEY	91b1dd3cc3	extend existing cloud plugin to accomodate new plugin	10 months ago
Brandon Croft	e87335a972	cloud: Allows object tag schema for selecting kv tagged workspaces ... When key-value tags are enabled and used in the workspace, users may define the tags attribute as a map of strings in the cloud block in order to more precicely match workspaces using those tags.	1 year ago
Sebastian Rivera	015f795ff0	Rebrand Terraform Cloud to HCP Terraform	2 years ago
Nick Fagerlund	ff62192819	Adjust CloudPluginConfig doc comments	2 years ago
Nick Fagerlund	c398d0340f	Catch a missing assign-after-append ... I believe this is a slice append under the hood, which would mean `.Append()` consumes the original receiver and you shouldn't touch it afterwards.	2 years ago
Nick Fagerlund	7a1c49c61d	Append cloud plugin config metadata in plugin client requests ... - 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.	2 years ago
Nick Fagerlund	e1f0165693	Cloud command: Use cloud backend to find plugin config and service URLs ... The plugin needs some config info in order to actually build a go-tfe client and _do_ anything, and the Cloud backend is the one place that already knows how to look up and reconcile all the possible sources of that info. So, we'll just find a Cloud backend and pick its pockets. This also replaces our reimplementations of hostname lookup and service discovery, using work the Cloud backend already did.	2 years ago
Nick Fagerlund	d2e07f6f03	Add `TF_CLOUD_PLUGIN_DEV_OVERRIDE` to enable cloudplugin dev ... 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`.	2 years ago
Brandon Croft	114f876f81	Merge pull request #33602 from hashicorp/TF-8071-download-and-verify-the-plugin-in-terraform ... Download and authenticate the cloudplugin	3 years ago
Brandon Croft	3d1e07dcf3	Write command output to Meta.Streams, more plugin err handling	3 years ago
Brandon Croft	8f4a430e41	refactor: cloudplugin VersionManager -> BinaryManager	3 years ago
CJ Horton	98b81d3c50	add missing copyright headers	3 years ago
Brandon Croft	63e017b81b	cloudplugin: download and verify plugin ... 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	3 years ago
Brandon Croft	e5ce25099c	Apply suggestions from code review ... Co-authored-by: Sebastian Rivera <sebastian.rivera@hashicorp.com>	3 years ago
Brandon Croft	9bb566dcdb	Update cloudplugin type casting to simplify adding future versions	3 years ago
Brandon Croft	2c3d134705	Adds `cloud` subcommand with some toy options	3 years ago