!> **Important:** The `terraform push` command is no longer functional. Its functionality was replaced and surpassed by [the `remote` backend](/language/settings/backends/remote), which works with current versions of Terraform Cloud. The `remote` backend allows you to run remote operations directly from the command line, and displays real-time output from the remote run environment.
!> **Important:** The `terraform push` command is no longer functional. We recommend the [Terraform Cloud CLI integration](/cli/cloud) instead, which allows you to run remote operations in Terraform Cloud directly from the command line.
The `terraform push` command was an early implementation of remote Terraform runs. It allowed teams to push a configuration to a remote run environment in a discontinued version of Terraform Enterprise.
For configurations using the [Terraform Cloud CLI integration](/cli/cloud) or the [`remote` backend](/language/settings/backends/remote) only, `terraform taint`
@ -20,9 +20,7 @@ It is safe to run this command automatically, for example as a post-save
check in a text editor or as a test step for a re-usable module in a CI
system.
Validation requires an initialized working directory with any referenced
plugins and modules installed. To initialize a working directory for
validation without accessing any configured remote backend, use:
Validation requires an initialized working directory with any referenced plugins and modules installed. To initialize a working directory for validation without accessing any configured backend, use:
```
$ terraform init -backend=false
@ -72,26 +70,26 @@ We will introduce new major versions only within the bounds of
In the normal case, Terraform will print a JSON object to the standard output
stream. The top-level JSON object will have the following properties:
* `valid` (boolean): Summarizes the overall validation result, by indicating
- `valid` (boolean): Summarizes the overall validation result, by indicating
`true` if Terraform considers the current configuration to be valid or
`false` if it detected any errors.
* `error_count` (number): A zero or positive whole number giving the count
- `error_count` (number): A zero or positive whole number giving the count
of errors Terraform detected. If `valid` is `true` then `error_count` will
always be zero, because it is the presence of errors that indicates that
a configuration is invalid.
* `warning_count` (number): A zero or positive whole number giving the count
- `warning_count` (number): A zero or positive whole number giving the count
of warnings Terraform detected. Warnings do not cause Terraform to consider
a configuration to be invalid, but they do indicate potential caveats that
a user should consider and possibly resolve.
* `diagnostics` (array of objects): A JSON array of nested objects that each
- `diagnostics` (array of objects): A JSON array of nested objects that each
describe an error or warning from Terraform.
The nested objects in `diagnostics` have the following properties:
* `severity` (string): A string keyword, currently either `"error"` or
- `severity` (string): A string keyword, currently either `"error"` or
`"warning"`, indicating the diagnostic severity.
The presence of errors causes Terraform to consider a configuration to be
@ -100,7 +98,7 @@ The nested objects in `diagnostics` have the following properties:
introduce new severity keywords, so consumers should be prepared to accept
and ignore severity values they don't understand.
* `summary` (string): A short description of the nature of the problem that
- `summary` (string): A short description of the nature of the problem that
the diagnostic is reporting.
In Terraform's usual human-oriented diagnostic messages, the summary serves
@ -113,7 +111,7 @@ The nested objects in `diagnostics` have the following properties:
summary. In those cases, the summary might include newline characters which
a renderer should honor when presenting the message visually to a user.
* `detail` (string): An optional additional message giving more detail about
- `detail` (string): An optional additional message giving more detail about
the problem.
In Terraform's usual human-oriented diagnostic messages, the detail provides
@ -135,7 +133,7 @@ The nested objects in `diagnostics` have the following properties:
additional rules for processing other text conventions, but will do so within
the bounds of the rules above to achieve backward-compatibility.
* `range` (object): An optional object referencing a portion of the configuration
- `range` (object): An optional object referencing a portion of the configuration
source code that the diagnostic message relates to. For errors, this will
typically indicate the bounds of the specific block header, attribute, or
expression which was detected as invalid.
@ -149,36 +147,36 @@ The nested objects in `diagnostics` have the following properties:
configuration, so `range` will be omitted or `null` for diagnostic messages
where it isn't relevant.
* `snippet` (object): An optional object including an excerpt of the
- `snippet` (object): An optional object including an excerpt of the
configuration source code that the diagnostic message relates to.
The snippet information includes:
* `context` (string): An optional summary of the root context of the
- `context` (string): An optional summary of the root context of the
diagnostic. For example, this might be the resource block containing the
expression which triggered the diagnostic. For some diagnostics this
information is not available, and then this property will be `null`.
* `code` (string): A snippet of Terraform configuration including the
- `code` (string): A snippet of Terraform configuration including the
source of the diagnostic. This can be multiple lines and may include
additional configuration source code around the expression which
triggered the diagnostic.
* `start_line` (number): A one-based line count representing the position
- `start_line` (number): A one-based line count representing the position
in the source file at which the `code` excerpt begins. This is not
necessarily the same value as `range.start.line`, as it is possible for
`code` to include one or more lines of context before the source of the
diagnostic.
* `highlight_start_offset` (number): A zero-based character offset into the
- `highlight_start_offset` (number): A zero-based character offset into the
`code` string, pointing at the start of the expression which triggered
the diagnostic.
* `highlight_end_offset` (number): A zero-based character offset into the
- `highlight_end_offset` (number): A zero-based character offset into the
`code` string, pointing at the end of the expression which triggered the
diagnostic.
* `values` (array of objects): Contains zero or more expression values
- `values` (array of objects): Contains zero or more expression values
which may be useful in understanding the source of a diagnostic in a
complex expression. These expression value objects are described below.
@ -187,12 +185,12 @@ The nested objects in `diagnostics` have the following properties:
A source position object, as used in the `range` property of a diagnostic
object, has the following properties:
* `byte` (number): A zero-based byte offset into the indicated file.
- `byte` (number): A zero-based byte offset into the indicated file.
* `line` (number): A one-based line count for the line containing the relevant
- `line` (number): A one-based line count for the line containing the relevant
position in the indicated file.
* `column` (number): A one-based count of _Unicode characters_ from the start
- `column` (number): A one-based count of _Unicode characters_ from the start
of the line indicated in `line`.
A `start` position is inclusive while an `end` position is exclusive. The
@ -208,13 +206,13 @@ part of the expression which triggered the diagnostic. This is especially
useful when using `for_each` or similar constructs, in order to identify
exactly which values are responsible for an error. The object has two properties:
* `traversal` (string): An HCL-like traversal string, such as
- `traversal` (string): An HCL-like traversal string, such as
`var.instance_count`. Complex index key values may be elided, so this will
not always be valid, parseable HCL. The contents of this string are intended
to be human-readable and are subject to change in future versions of
Terraform.
* `statement` (string): A short English-language fragment describing the value
- `statement` (string): A short English-language fragment describing the value
of the expression when the diagnostic was triggered. The contents of this
string are intended to be human-readable and are subject to change in future
While this may seem tedious, it still gives Terraform users an avenue for
importing existing resources.
## Remote Backends
## Terraform Cloud
When using Terraform import on the command line with a [remote
backend](/language/settings/backends/remote), such as Terraform Cloud, the import
command runs locally, unlike commands such as apply, which run inside your
Terraform Cloud environment. Because of this, the import command will not have
access to information from the remote backend, such as workspace variables.
In order to use Terraform import with a remote state backend, you may need to
set local variables equivalent to the remote workspace variables.
When you use Terraform on the command line with Terraform Cloud, many commands (e.g., `apply`) run inside your Terraform Cloud environment. However, the `import` command runs locally, so it will not have access to information from Terraform Cloud. To successfully perform an import, you may need to set local variables equivalent to any remote workspace variables in Terraform Cloud.
The `terraform_remote_state` data source retrieves the root module output values
from some other Terraform configuration, using the latest state snapshot from
the remote backend.
The `terraform_remote_state` data source uses the latest state snapshot from a specified state backend to retrieve the root module output values
from some other Terraform configuration.
This data source is built into Terraform, and is always available; you do not
need to require or configure a provider in order to use it.
You can use the `terraform_remote_state` data source without requiring or configuring a provider. It is always available through a built-in provider with the [source address](/language/providers/requirements#source-addresses) `terraform.io/builtin/terraform`. That provider does not include any other resources or data sources.
-> **Note:** This data source is implemented by a built-in provider, whose
is `terraform.io/builtin/terraform`. That provider does not include any other
resources or data sources.
~> **Important:** We recommend using the [`tfe_outputs` data source](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) in the [Terraform Cloud/Enterprise Provider](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs) to access remote state outputs in Terraform Cloud or Terraform Enterprise. The `tfe_outputs` data source is more secure because it does not require full access to workspace state to fetch outputs.
## Alternative Ways to Share Data Between Configurations
@ -94,12 +89,6 @@ post-processing such as JSON decoding. You can then change that module later
if you switch to a different strategy for sharing data between multiple
Terraform configurations.
## Usage with Terraform Cloud/Enterprise
When trying to access remote state outputs in Terraform Cloud/Enterprise, it is recommended to use the `tfe_outputs` data source in the [Terraform Cloud/Enterprise Provider](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs) instead of relying the `terraform_remote_state` data source.
See the [full documentation](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) for the `tfe_outputs` data source for more details.
Laura Pacilio
4 years ago
committed by
GitHub