* Update gcs.mdx
Updated GCS remote backend to include the >=0.12 remote backend data source formatting (incl .output before output name)
* Update gcs.mdx
removed old data source example
* Update gcs.mdx
updated to local_file and output->outputs
* Update gcs.mdx
removed "outputs" from the pre 0.12 ref
Previously, there was mixed usage of "(sensitive)" and "(sensitive value)" and even though it was more common to see "(sensitive)", the thought is that it's a value we are hiding rather than describing something already shown.
The current documentation wording seems to suggest that the only `.netrc` file that will be considered by Terraform is the one sitting in the current user's HOME directory. However, unless I am missing something, Terraform uses `go-getter` to fetch remote modules which mean that the `NETRC` environment variable will also be respected and, in fact, will take precedence over any `.netrc` file on the user's home directory.
See: f7a8c48a1f/netrc.go (L23-L36)
* Add support for `storage_custom_endpoint` in `gcs` backend
* Add documentation for new `storage_custom_endpoint` endpoint
* Empty commit to trigger Vercel deployment
* Add ability to use customer-managed KMS key to encrypt state, add acceptance tests
* Change test names for different encrpytion methods
* Commit files updated by `go mod tidy`
* Add guard against missing ENVs to `setupKmsKey` func
* Update KMS setup function to get credentials from ENVs
* Update tests to not include zero-values in config
This means that default values are supplied later by TF instead of supplied as config from the user
This also avoids issues related to making field conflicts explicit with `ConflictsWith`
* Make `encryption_key` & `kms_encryption_key` conflicting fields
Removing the Default from `encryption_key` does not appear to be a breaking change when tested manually
* Add ability to set `kms_encryption_key` via ENV
* Refactor `encryption_key` to use `DefaultFunc` to access ENV, if set
* Remove comments
* Update `gcs` backend docs & descriptions in schema
* Update `gcs` backend docs to include information on encryption methods
* Apply technical writing suggestions from code review
Co-authored-by: Matthew Garrell <69917312+mgarrell777@users.noreply.github.com>
* Update documentation to remove passive voice
* Change use of context in tests, add inline comment, update logs
* Remove use of `ReadPathOrContents` for new field
Co-authored-by: Matthew Garrell <69917312+mgarrell777@users.noreply.github.com>
We originally included this warning because the go-cty-yaml module wasn't
yet stable and it was also not extensively tested so it wasn't yet clear
if its behavior would need to change in some less common cases we hadn't
tested so far.
However, go-cty-yaml had its v1.0.0 release some time ago and is now
committed to preserving its current Marshal output unless it is found to
be non-compliant with the YAML 1.2 specification. This doc change means
that Terraform's yamlencode is now adopting a similar posture:
- The exact style details produced by the function for a particular input
are now frozen. It'll change only if we find that the function is
producing output that isn't valid per the YAML spec.
- If someone finds a YAML parser that cannot parse what yamlencode
produces but what it produces is valid per the YAML 1.2 spec, we'll
expect the parser to be corrected to better support the spec rather
than changing the yamlencode output.
There may be pragmatic exceptions if we encounter a situation we cannot
anticipate yet, but the above will be our general rule. This is really
just a specialization of the spirit of the v1.x Compatibility Promises,
tailored specifically to this function.
Made a change to code example within the *Preconditions and Postconditions* section so that it technically makes sense; prior it was missing the data resource that was being called within the precondition lifecycle event on line 135, and the aws_instance resource was not utilizing the ami being provided by the data source in line 129, so i changed that as well.
