* website: plannable import docs
* website: config gen docs
* Update website/docs/cli/commands/plan.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Update website/docs/cli/import/index.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Update website/docs/language/import/index.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Update website/docs/language/import/index.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* fix docs rendering
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* link again to import blocks
* fix genconfig example plan output
* Update website/docs/language/import/index.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* add import resource config example
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* attempt to fix nav
* more explicit
* fix build?
* remove pseudo tutorial
* add advice on when to gen
* add note on idempotency
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
Co-authored-by: Alan Szlosek Jr <alan.szlosek@hashicorp.com>
* refer to cli cmd in usual way
* more explanation for genconfig
* remove unnecessary sentence
* add heading
* update help text
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* update link
* add import ID section
* Apply suggestions from code review
Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* dial back didacticism
* clarify genconfig instructions
* explicit explanation of arg conflict
* Apply suggestions from code review
Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* clarify import block required for genconfig
---------
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
Co-authored-by: Alan Szlosek Jr <alan.szlosek@hashicorp.com>
Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>
* Add documentation page for checks and assertions
* address comments
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* address comments
* Apply suggestions from code review
Co-authored-by: Radek Simko <radek.simko@gmail.com>
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* address comments
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* revamp choosing checks or other custom conditions section
* expand on depends_on
* fix issues link
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* address comments
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
---------
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
Co-authored-by: Radek Simko <radek.simko@gmail.com>
There aren't any super significant upgrade considerations this time, so
this is really just a summary of the two main entries in the changelog.
There is also an entry in the changelog about ending support for older
versions of Windows, but in that case we are just passing on a release
note from Go itself and we already warned against using versions earlier
than Windows 10 back in Terraform v0.15 (since we are relying on the
Windows 10 console API) and so this is just one additional reason why
Terraform might not work correctly on those earlier versions of Windows,
so not worth mentioning in the upgrade guide here since our guidance
hasn't changed.
* cloud: assert import block compatibility
* check for import <> TFC compatibility during init
* imports are not in alphabetical order 🙃
---------
Co-authored-by: CJ Horton <cjhorton@hashicorp.com>
This temporary measure prevents a panic further down the line when there is an unmatched expanded resource instance import target when running in config gen mode.
This minor release includes a number of security fixes and other small bug
fixes in the standard library and Go compiler.
The security fixes do not appear to involve functionality critical to
Terraform and so this is not an urgent upgrade, but still worth doing to
reset to a more recent baseline.
HashiCorp legal now requires a copyright claim in a comment at the top of
every substantial file in this repository. If we don't add this ourselves
then a bot will open a PR to add missing entries, but that process adds
git history, pull request, and GitHub notification noise so instead we'll
deal with it proactively as part of our usual code generation steps.
This means that pull requests will fail their checks if there are any
files that lack copyright headers, so we can deal with those before we
merge rather than in a subsequent PR.
This introduces the "refinements" concept from upstream cty, which allows Terraform to track some additional information about unknown values that constrains their possible range even though we don't yet know the final value.
This is actually a description of the "cty" library's encoding of refined
values, but from the perspective of the plugin protocol it's an
implementation detail that Terraform Core outsources that to a third-party
library, and current server-side implementations of the protocol use an
independent implementation of this format which will need to be compatible
with what cty does.
Providers that existed prior to refinements (all of them, at the time of
writing) cannot preserve refinements sent in unknown values in the
configuration, and even if one day providers _are_ aware of refinements
there we might add new ones that existing providers don't know how to
handle.
For that reason we'll absolve providers of the responsibility of
preserving refinements from config into plan by fixing some cases where
we were incorrectly using RawEquals to compare values; that function isn't
appropriate for comparing values that might be unknown.
However, to avoid a disruptive change right now this initial fix just
strips off the refinements before comparing. Ideally this should be using
Value.Equals and handling unknown values more explicitly, but we'll save
that for a possible later improvement.
This does not include a similar exception for validating whether a final
value conforms to a plan because the plan value and the final value are
both produced by the same provider and so providers ought to be able to
be consistent with their _own_ treatment of refinements, if any.
Configuration is special because Terraform itself generates that, and so
it can potentially contain refinements that a particular provider has no
awareness of.
If the original value was unknown but its range was refined then the
provider must return a value that is within the refined range, because
otherwise downstream planning decisions could be invalidated.
This relies on cty's definition of whether a value is in a refined range,
which has pretty good coverage for the "false" case and so should give a
pretty good signal, but it'll probably improve over time and so providers
must not rely on any loopholes in the current implementation and must
keep their promises even if Terraform can't currently check them.
If the string to be tested is an unknown value that's been refined with
a prefix and the prefix we're being asked to test is in turn a prefix of
that known prefix then we can return a known answer despite the inputs
not being fully known.
There are also some other similar deductions we can make about other
combinations of inputs.
This extra analysis could be useful in a custom condition check that
requires a string with a particular prefix, since it can allow the
condition to fail even on partially-unknown input, thereby giving earlier
feedback about a problem.
The "id" attribute of this resource type is generated by the provider
itself and can never be null, so we'll refine the range of its unknown
result in case that helps downstream expressions to produce known results
even when the exact value hasn't yet been planned.
cty's new "refinements" concept allows us to reduce the range of unknown
values from our functions. This initial changeset focuses only on
declaring which functions are guaranteed to return a non-null result,
which is a helpful baseline refinement because it allows "== null" and
"!= null" tests to produce known results even when the given value is
otherwise unknown.
This commit also includes some updates to test results that are now
refined based on cty's own built-in refinement behaviors, just as a
result of us having updated cty in the previous commit.
