Skip to content

Add provider block reference rewrite #557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: docs/reference-rewrites-phrase-1
Choose a base branch
from
Open

Add provider block reference rewrite #557

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bb03383
First try
rkoron007 Jul 10, 2025
109d3c5
Fix small things and ready to review
rkoron007 Jul 10, 2025
99f6513
Fix the module block link for now
rkoron007 Jul 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions content/terraform/v1.12.x/data/language-nav-data.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -193,8 +193,8 @@
"routes": [
{ "title": "Overview", "path": "providers" },
{
"title": "Provider Configuration",
"path": "providers/configuration"
"title": "Provider block",
"href": "/terraform/language/block/provider"
},
{
"title": "Provider Requirements",
Expand Down Expand Up @@ -1143,6 +1143,10 @@
"title": "output",
"path": "block/output"
},
{
"title": "provider",
"path": "block/provider"
},
{
"title": "removed",
"path": "block/removed"
Expand Down
66 changes: 33 additions & 33 deletions content/terraform/v1.12.x/docs/language/block/data.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ The `data` block supports the following configuration:
- [`data "<TYPE>" "<LABEL>"`](#data) &nbsp block
- [provider-specific arguments](#provider-specific-arguments) &nbsp block | refer to your provider documentation
- [`count`](#count) &nbsp number | mutually exclusive with `for_each`
- [`depends_on`](#depends_on) &nbsp list of references
- [`depends_on`](#depends_on) &nbsp list of references
- [`for_each`](#for_each) &nbsp map or set of strings | mutually exclusive with `count`
- [`provider`](#provider) &nbsp reference
- [`lifecycle`](#lifecycle) &nbsp block
Expand All @@ -36,11 +36,11 @@ data "<TYPE>" "<LABEL>" {
<PROVIDER-SPECIFIC ARGUMENTS>
count = <NUMBER> # `count` and `for_each` are mutually exclusive
depends_on = [ <RESOURCE.ADDRESS.EXPRESSION> ]
for_each = { # `for_each` and `count` are mutually exclusive
for_each = { # `for_each` and `count` are mutually exclusive
<KEY> = <VALUE>
}
for_each = [ # `for_each` accepts a map or a set of strings
"<VALUE>",
for_each = [ # `for_each` accepts a map or a set of strings
"<VALUE>",
"<VALUE>"
]
provider = <REFERENCE.TO.ALIAS>
Expand All @@ -65,16 +65,16 @@ A `data` block supports the following configuration.

You must set the following arguments for every `data` block:

- `TYPE`: Specifies the data source type. Provider developers define the support data sources. Refer to the provider documentation for details. Terraform also includes the [`terraform_remote_state` data source](/terraform/language/state/remote-state-data), which lets you access state data from other workspaces.
- `TYPE`: Specifies the data source type. Provider developers define the support data sources. Refer to the provider documentation for details. Terraform also includes the [`terraform_remote_state` data source](/terraform/language/state/remote-state-data), which lets you access state data from other workspaces.
- `LABEL`: Specifies a name for the data source. Use the `data.<label>.<attribute>` syntax to reference the data. Refer to [References to Named Values](/terraform/language/expressions/references) and [Resource naming](/terraform/language/style#resource-naming) for expression syntax and label recommendations.

### Provider-specific arguments

The provider developer determines which arguments you can define for a data source. Refer to the provider documentation for details.
The provider developer determines which arguments you can define for a data source. Refer to the provider documentation for details.

### `count`

The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration.
The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration.

```hcl
data "<TYPE>" "<LABEL>" {
Expand Down Expand Up @@ -137,7 +137,7 @@ The `for_each` meta-argument instructs Terraform to provision similar resources

```hcl
data "<TYPE>" "<LABEL>" {
for_each = [ "<VALUE>" ]
for_each = [ "<VALUE>" ]
# . . .
}
```
Expand Down Expand Up @@ -173,12 +173,12 @@ You cannot use sensitive values, such as [sensitive input variables](/terraform/

If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.

Refer to [Sensitive Data in State](/terraform/language/state/sensitive-data) for more information.
Refer to [Sensitive Data in State](/terraform/language/state/sensitive-data) for more information.

The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the data source. The object has the following attributes:

- `each.key`: Map key or list member that corresponds to an instance.
- `each.value`: Map value that corresponds to an instance.
- `each.value`: Map value that corresponds to an instance.

Use the `<TYPE>.<NAME>[<KEY>]` syntax to access an instance of a data source created using `for_each`. For example, `data.azurerm_resource_group.rg["a_group"]` refers to an instance of the `data.azurrm_resource_group` resource named `rg` created off of the `a_group` key.

Expand All @@ -188,36 +188,36 @@ The `for_each` argument is a meta-argument, which is built into Terraform and co
#### Summary

- Data type: Map or set of strings.
- Default: None.
- Default: None.

### `provider`

The `provider` argument instructs Terraform to use an alternate provider configuration.
The `provider` argument instructs Terraform to use an alternate provider configuration.

```hcl
data "<TYPE>" "<LABEL>" {
provider = <provider>.<alias>
}
```

By default, Terraform automatically selects a provider based on the data source type, but you can create multiple provider configurations and use a non-default configuration for specific data sources.
By default, Terraform automatically selects a provider based on the data source type, but you can create multiple provider configurations and use a non-default configuration for specific data sources.

Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. Refer to [Multiple Provider Configurations](/terraform/language/providers/configuration#alias-multiple-provider-configurations) for instructions on how to reference a specific provider configuration.
Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. Refer to [Using an alternate provider configuration](/terraform/language/block/provider#using-an-alternate-provider-configuration) for an example of how to reference a specific provider configuration.

The `provider` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/concepts/meta-arguments) for more information.

#### Summary

- Data type: Reference.
- Default: None.
- Default: None.

### `lifecycle`

The `lifecycle` block defines lifecycle rules for how Terraform operates on your data source.
The `lifecycle` block defines lifecycle rules for how Terraform operates on your data source.

```hcl
data "<TYPE>" "<LABEL>" {
lifecycle {
lifecycle {
<lifecycle>
}
}
Expand All @@ -230,7 +230,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o

Configurations defined in the `lifecycle` block affect how Terraform constructs and traverses the dependency graph. You can only use literal values in the lifecycle block because Terraform processes them before it evaluates arbitrary expressions for a run.

The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates data sources. Refer to [Meta-arguments](/terraform/language/concepts/meta-arguments) for more information.
The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates data sources. Refer to [Meta-arguments](/terraform/language/concepts/meta-arguments) for more information.

#### Summary

Expand All @@ -239,11 +239,11 @@ The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments

### `precondition`

The `precondition` block specifies a condition that must return `true` before Terraform evaluates and performs operations on the data source. You can also specify an error message for Terraform to print when the condition returns `false`.
The `precondition` block specifies a condition that must return `true` before Terraform evaluates and performs operations on the data source. You can also specify an error message for Terraform to print when the condition returns `false`.

```hcl
resource {
lifecycle {
lifecycle {
precondition {
condition = <expression>
error_message = "<message>"
Expand All @@ -261,9 +261,9 @@ The following arguments in the `precondition` block are required:

Terraform evaluates `precondition` blocks before evaluating the resource's configuration arguments. The `precondition` can take precedence over argument evaluation errors.

Terraform evaluates precondition blocks after evaluating [`count`](#count) and [`for_each`](#for_each) meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.
Terraform evaluates precondition blocks after evaluating [`count`](#count) and [`for_each`](#for_each) meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.

You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.

Refer to [Test and validate](/terraform/language/test-and-validate) for information about adding validations to your Terraform configuration.

Expand All @@ -275,11 +275,11 @@ Refer to [Test and validate](/terraform/language/test-and-validate) for informat

### `postcondition`

The `postcondition` block specifies a condition that must return `true` after Terraform performs operations on the data source. You can also specify an error message for Terraform to print to the console when the condition returns `false`.
The `postcondition` block specifies a condition that must return `true` after Terraform performs operations on the data source. You can also specify an error message for Terraform to print to the console when the condition returns `false`.

```hcl
data "<TYPE>" "<LABEL>" {
lifecycle {
lifecycle {
postcondition {
condition = <expression>
error_message = "<message>"
Expand All @@ -297,7 +297,7 @@ The following arguments in the `precondition` block are required:

Terraform evaluates `postcondition` blocks after planning and applying changes to the data source. Postcondition failures prevent changes to other resources that depend on the failing resource.

You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.

Refer to [Test and validate](/terraform/language/test-and-validate) for information about adding validations to your Terraform configuration.

Expand All @@ -313,9 +313,9 @@ The following examples show how to write configuration for common use cases.

### Specify a dependency

In the following example, Terraform gets an AMI for use in the `aws_instance` resource after creating the `aws_subnet.example_subnet` resource:
In the following example, Terraform gets an AMI for use in the `aws_instance` resource after creating the `aws_subnet.example_subnet` resource:

```hcl
```hcl
resource "aws_vpc" "example_vpc" {
cidr_block = "10.0.0.0/16"
}
Expand All @@ -336,7 +336,7 @@ data "aws_ami" "example_ami" {
name = "architecture"
values = ["x86_64"]
}
depends_on = [aws_subnet.example_subnet]
depends_on = [aws_subnet.example_subnet]
}

resource "aws_instance" "example_instance" {
Expand All @@ -346,11 +346,11 @@ resource "aws_instance" "example_instance" {
}
```

Note that this is a simplified example and does not represent a real-world use case. The `depends_on` argument changes the dependency graph so that Terraform creates the resources in a linear order. Without the argument, Terraform would still successfully create the resources.
Note that this is a simplified example and does not represent a real-world use case. The `depends_on` argument changes the dependency graph so that Terraform creates the resources in a linear order. Without the argument, Terraform would still successfully create the resources.

### Select an alternate provider configuration

In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.
In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.

```hcl
provider "google" {
Expand All @@ -362,15 +362,15 @@ provider "google" {
region = "europe-west1"
}

data "google_compute_instance" "example" {
data "google_compute_instance" "example" {
provider = google.europe
# ...
}
```

### Apply custom conditions

The following example includes several configurations that illustrate how to define `precondition` and `postcondition` arguments in the `lifecycle` meta-argument.
The following example includes several configurations that illustrate how to define `precondition` and `postcondition` arguments in the `lifecycle` meta-argument.

The following `data` block instructs Terraform to retrieve the ID of the `ami-abc123` AMI:

Expand Down Expand Up @@ -424,4 +424,4 @@ data "aws_ebs_volume" "example" {
output "api_base_url" {
value = "https://${aws_instance.example.private_dns}:8433/"
}
```
```
Loading
Loading