* 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.
We've removed the main documentation pages for the backends that are
removed in Terraform v1.3, but we'll leave a small callout note so that
the backend names are still reachable through our search index once the
v1.3 docs are the active version.
The primary goal here is to help folks who have inherited configurations
using older versions of Terraform to learn about features they see in those
configurations, so the main thing here is the link to the older release
docs which include those. However, this is also a good opportunity to link
to the upgrade guide content which describes some possible migration
paths away from these removed backends.
Before our website allowed selecting from older versions of Terraform to
see older documentation we needed to preserve all of the historical
upgrade guides in the latest release branch so that they'd stay available
on the website.
However, our new strategy is for each release to have its own separate
set of documentation selectable using a global version selector. We should
therefore now have only the upgrade guide for the each minor release
on its release branch, with the upgrade guides for earlier releases
instead maintained on their own branches.
However, our v1.1 branch is, as a matter of pragmatism, serving as the home
for the "v1.1 and earlier" documentation, and so there will continue to
be multiple upgrade guides on that branch. For that reason, we're
preserving the URL scheme "upgrade-guides" (plural) even though the URL
now points to only a single version upgrade guide because that causes
readers to land in the correct place if they are on a modern version's
upgrade guide page and they use the version selector to choose the
"v1.1 and earlier" option.
This is a complement to "timestamp" and "timeadd" which allows
establishing the ordering of two different timestamps while taking into
account their timezone offsets, which isn't otherwise possible using the
existing primitives in the Terraform language.
Previously we didn't describe the interaction between default values and
callers explicitly passing "null".
We treat an explicit null as the same as omitting the attribute when
applying defaults, because that then allows callers to use the typical
pattern for conditional assignment, using explicit null as a fallback
to the module's defined default without having to duplicate that default:
example = var.foo ? "hello" : null
We've been holding on to this snapshot of the old docs from the v0.11
branch ever since the v0.12 release as a courtesy to folks who are still
using Terraform v0.11, since until now we didn't have any way to serve
older versions' docs on the website alongside the current aside from
snapshotting it forward in this way.
However, our website framework now supports publishing multiple versions
at the same time and so the final resting place for these v0.11 docs will
be in the "v1.1" branch, whose content is serving as the documentation
for the "v1.1 and earlier" version selection on the website. While it does
still feel a little awkward to have v0.11 be a subsection of the v1.1
docs, this is at least more honest in that v0.11 _is_ earlier than v1.1,
whereas it's confusing and weird for it to appear under the "v1.2.x"
option and the other versions that will appear later.
In order to avoid breaking incoming links to the old docs we will deploy
this in conjunction with some additional redirects managed by the top-level
terraform-website repository, which will send all paths with the prefix
/language/configuration-0-11 to the equivalent path under
/language/v1.1.x/configuration-0-11 . That redirect rule must exist
outside of this repository because it's a bridge _between_ versions of
the website in this repository, rather than a link to other content within
the same version.
