Previously, the `providers schema -json` output would include the root object from `metadata functions -json`. This object had its own `format_version` property, which would be confusing with the root `format_version` property already present.
This change still uses the `jsonfunction` package for consistency between cty and provider function JSON handling, but removes that extra object, instead making `functions` directly a mapping of names to signatures/definitions. This also adds a code comment to hint maintainers that jsonprovider format versioning is tied to jsonfunction format versioning.
Example output prior to change:
```jsonc
{
"format_version": "1.0",
"provider_schemas": {
"registry.terraform.io/bflad/framework": {
// ...
"functions": {
"format_version": "1.0",
"function_signatures": {
"example": {
"description": "Echoes given argument as result",
"summary": "Example function",
"return_type": "string",
"parameters": [
{
"name": "input",
"description": "String to echo",
"type": "string"
}
]
}
}
}
}
}
}
```
Example output after change:
```jsonc
{
"format_version": "1.0",
"provider_schemas": {
"registry.terraform.io/bflad/framework": {
// ...
"functions": {
"example": {
"description": "Echoes given argument as result",
"summary": "Example function",
"return_type": "string",
"parameters": [
{
"name": "input",
"description": "String to echo",
"type": "string"
}
]
}
}
}
}
}
```
Previously "terraform console" always evaluated in a kinda strange context
where resource instance data comes from the prior state, but other derived
of values end up being calculated dynamically based on the current
configuration, which is okay for simple cases but can be confusing if the
configuration has changed significantly since the most recent apply, or
if there haven't yet been any applied changes.
Now we'll allow an optional new mode where Terraform runs the normal plan
phase (as if running "terraform plan") and then uses the resulting
_planned state_ as the basis for evaluation, allowing evaluation against
a partial approximation of what the world ought to look like if these
changes were applied, without having to actually apply them first.
As with the previous use of the eval walk, it's possible that an erroneous
situation will still produce a partial evaluation scope, and so the
console still allows evaluation against that scope but with a caveat that
it might produce unexpected results. In practice this can be useful for
debugging situations like when unknown values block planning of an object,
to allow inspection of the values that are contributing to that blocked
planning operation even though the plan is not yet complete.
Unless a user specifically requests a real operation graph using the
-type option, we'll by default present a simplified graph which only
represents the relationships between resources, since resources are the
main side-effects and so the ordering of these is more interesting than
the ordering of Terraform's internal implementation details.
* Add cloud-run documentation for testing framework
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* resolve last comment
---------
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Add ability to specify Terraform Cloud Project in cloud block
Adds project configuration to the workspaces section of the cloud block.
Also configurable via the `TF_CLOUD_PROJECT` environment variable.
When a project is configured, the following behaviors will occur:
- `terraform init` with workspaces.name configured will create the workspace in the given project
- `terraform workspace new <name>` with workspaces.tags configured will create workspaces in the given project
- `terraform workspace list` will list workspaces only from the given project
The following behaviors are NOT affected by project configuration
- `terraform workspace delete <name>` does not validate the workspace's inclusion in the given project
- When initializing a workspace that already exists in Terraform Cloud, the workspace's parent project is NOT validated against the given project
Adds tests for cloud block configuration of project
Update changelog
* Update cloud block docs
* Fix typos and changelog entry
* Add speculative project lookup early in the cloud initialize process to capture inability to find a configured project
* Add project config for alias test
* 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>
This is an alternative way to set the CLI configuration setting
plugin_cache_may_break_dependency_lock_file to activate the transitional
compatibility behavior that prefers to break the dependency lock file if
that would create an additional opportunity to use the plugin cache.
* Add metadata functions command skeleton
* Export functions as JSON via cli command
* Add metadata command
* Add tests to jsonfunction package
* WIP: Add metadata functions test
* Change return_type & type in JSON to json.RawMessage
This enables easier deserialisation of types when parsing the JSON.
* Skip is_nullable when false
* Update cli docs with metadata command
* Use tfdiags to report function marshal errors
* Ignore map, list and type functions
* Test Marshal function with diags
* Test metadata functions command output
* Simplify type marshaling by using cty.Type
* Add static function signatures for can and try
* Update internal/command/jsonfunction/function_test.go
Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>
---------
Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>
Currently Terraform will use an entry from the global plugin cache only if
it matches a checksum already recorded in the dependency lock file. This
allows Terraform to produce a complete lock file entry on the first
encounter with a new provider, whereas using the cache in that case would
cause the lock file to only cover the single package in the cache and
thereefore be unusable on any other operating system or CPU architecture.
This temporary CLI config option is a pragmatic exception to support those
who cannot currently correctly use the dependency lock file but who still
want to benefit from the plugin cache. With this setting enabled,
Terraform has permission to produce a dependency lock file that is only
suitable for the current system if that would allow use of an existing
entry in the plugin cache.
We are introducing this option to resolve a conflict between the needs of
folks who are using the dependency lock file as expected and the needs of
folks who cannot use the dependency lock file for some reason. The hope
then is to give respite to those who need this exception in the meantime
while we understand better why they cannot use the dependency lock file
and improve its design so that everyone will be able to use it
successfully in a future version of Terraform. This option will become a
silent no-op in a future version of Terraform, once the dependency lock
file behavior is sufficient for all supported Terraform development
workflows.
