resilien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

website: Fix numerous links with redirects or broken anchors 

These links largely still go somewhere useful, but they have some kind of issue
revealed by our new link checker:

- Some of them point to a stale URL that redirects, and can be updated to the
  new destination.
- Some of them point to anchors that don't exist (anymore?) in the destination.
- Some of them end up redirecting unnecessarily due to how the server handles
  directory URLs without trailing slashes. Sorry, I know that's pointless, just,
  humor me for the time being so we can get our CI green. 😭

In a couple cases, I've added invisible anchors to destination pages, either to
preserve an old habit or because the current anchors kind of suck due to being
particularly long or meandering.
This commit is contained in:
Nick Fagerlund 2020-12-16 15:10:49 -08:00 committed by Nick Fagerlund
parent 1fff4e2690
commit 85d477aee9
30 changed files with 91 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/docs/backends/state.html.md
View File

@ -66,7 +66,7 @@ prior to forcing the overwrite.
Backends are responsible for supporting [state locking](/docs/state/locking.html)
if possible. Not all backend types support state locking. In the
[list of supported backend types](/docs/backends/types) we explicitly note
[list of supported backend types](/docs/backends/types/index.html) we explicitly note
whether locking is supported.
For more information on state locking, view the

2
website/docs/commands/0.13upgrade.html.markdown
View File

@ -23,7 +23,7 @@ providers are in use for a module, detect the source address for those
providers where possible, and record this information in a
[`required_providers` block][required-providers].
[required-providers]: /docs/configuration/terraform.html#specifying-required-provider-versions
[required-providers]: /docs/configuration/provider-requirements.html
~> Note: the command ignores `.tf.json` files and override files in the module.

10
website/docs/commands/apply.html.markdown
View File

@ -72,11 +72,11 @@ The command-line flags are all optional. The list of available flags are:
* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
can be set multiple times. Variable values are interpreted as
[HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
specified via this flag.
[literal expressions](/docs/configuration/expressions/types.html) in the
Terraform language, so list and map values can be specified via this flag.
* `-var-file=foo` - Set variables in the Terraform configuration from
a [variable file](/docs/configuration/variables.html#variable-files). If
a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
directory, they will be automatically loaded. `terraform.tfvars` is loaded
first and the `.auto.tfvars` files after in alphabetical order. Any files
@ -92,7 +92,7 @@ that directory as the root module instead of the current working directory.
That usage is still supported in Terraform v0.14, but is now deprecated and we
plan to remove it in Terraform v0.15. If your workflow relies on overriding
the root module directory, use
[the `-chdir` global option](./#switching-working-directory-with--chdir)
[the `-chdir` global option](./#switching-working-directory-with-chdir)
instead, which works across all commands and makes Terraform consistently look
in the given directory for all files it would normaly read or write in the
current working directory.
@ -100,6 +100,6 @@ current working directory.
If your previous use of this legacy pattern was also relying on Terraform
writing the `.terraform` subdirectory into the current working directory even
though the root module directory was overridden, use
[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR)
[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
to direct Terraform to write the `.terraform` directory to a location other
than the current working directory.

7
website/docs/commands/import.html.md
View File

@ -75,11 +75,12 @@ in the configuration for the target resource, and that is the best behavior in m
* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
can be set multiple times. Variable values are interpreted as
[HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
specified via this flag. This is only useful with the `-config` flag.
[literal expressions](/docs/configuration/expressions/types.html) in the
Terraform language, so list and map values can be specified via this flag.
This is only useful with the `-config` flag.
* `-var-file=foo` - Set variables in the Terraform configuration from
a [variable file](/docs/configuration/variables.html#variable-files). If
a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
directory, they will be automatically loaded. `terraform.tfvars` is loaded
first and the `.auto.tfvars` files after in alphabetical order. Any files

14
website/docs/commands/init.html.markdown
View File

@ -142,10 +142,12 @@ You can modify `terraform init`'s plugin behavior with the following options:
cause Terraform to ignore any selections recorded in the dependency lock
file, and to take the newest available version matching the configured
version constraints.
- `-get-plugins=false` — Skip plugin installation. _Note: Since Terraform 0.13, this
command has been superseded by [`provider_installation`](./cli-config.html#provider-installation)
blocks or using the [`plugin_cache_dir`](./cli-config.html#plugin_cache_dir) setting.
It should not be used in Terraform versions 0.13+.
- `-get-plugins=false` — Skip plugin installation.
-> Note: Since Terraform 0.13, this option has been superseded by the
[`provider_installation`](./cli-config.html#provider-installation) and
[`plugin_cache_dir`](./cli-config.html#plugin_cache_dir) settings.
It should not be used in Terraform versions 0.13+.
- `-plugin-dir=PATH` — Force plugin installation to read plugins _only_ from
the specified directory, as if it had been configured as a `filesystem_mirror`
in the CLI configuration. If you intend to routinely use a particular
@ -176,7 +178,7 @@ that directory as the root module instead of the current working directory.
That usage is still supported in Terraform v0.14, but is now deprecated and we
plan to remove it in Terraform v0.15. If your workflow relies on overriding
the root module directory, use
[the `-chdir` global option](./#switching-working-directory-with--chdir)
[the `-chdir` global option](./#switching-working-directory-with-chdir)
instead, which works across all commands and makes Terraform consistently look
in the given directory for all files it would normaly read or write in the
current working directory.
@ -184,6 +186,6 @@ current working directory.
If your previous use of this legacy pattern was also relying on Terraform
writing the `.terraform` subdirectory into the current working directory even
though the root module directory was overridden, use
[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR)
[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
to direct Terraform to write the `.terraform` directory to a location other
than the current working directory.

12
website/docs/commands/plan.html.markdown
View File

@ -76,13 +76,13 @@ The available options are:
Address](/docs/internals/resource-addressing.html) to target. This flag can
be used multiple times. See below for more information.
* `-var=foo=bar` - Set a variable in the Terraform configuration. This flag
* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
can be set multiple times. Variable values are interpreted as
[HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
specified via this flag.
[literal expressions](/docs/configuration/expressions/types.html) in the
Terraform language, so list and map values can be specified via this flag.
* `-var-file=foo` - Set variables in the Terraform configuration from
a [variable file](/docs/configuration/variables.html#variable-files). If
a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
directory, they will be automatically loaded. `terraform.tfvars` is loaded
first and the `.auto.tfvars` files after in alphabetical order. Any files
@ -142,7 +142,7 @@ module instead of the current working directory.
That usage is still supported in Terraform v0.14, but is now deprecated and we
plan to remove it in Terraform v0.15. If your workflow relies on overriding
the root module directory, use
[the `-chdir` global option](./#switching-working-directory-with--chdir)
[the `-chdir` global option](./#switching-working-directory-with-chdir)
instead, which works across all commands and makes Terraform consistently look
in the given directory for all files it would normaly read or write in the
current working directory.
@ -150,6 +150,6 @@ current working directory.
If your previous use of this legacy pattern was also relying on Terraform
writing the `.terraform` subdirectory into the current working directory even
though the root module directory was overridden, use
[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR)
[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
to direct Terraform to write the `.terraform` directory to a location other
than the current working directory.

6
website/docs/commands/refresh.html.markdown
View File

@ -56,11 +56,11 @@ The `terraform refresh` command accepts the following options:
* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
can be set multiple times. Variable values are interpreted as
[HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
specified via this flag.
[literal expressions](/docs/configuration/expressions/types.html) in the
Terraform language, so list and map values can be specified via this flag.
* `-var-file=foo` - Set variables in the Terraform configuration from
a [variable file](/docs/configuration/variables.html#variable-files). If
a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
directory, they will be automatically loaded. `terraform.tfvars` is loaded
first and the `.auto.tfvars` files after in alphabetical order. Any files

2
website/docs/commands/state/push.html.md
View File

@ -20,7 +20,7 @@ manual intervention is necessary with the remote state.
Usage: `terraform state push [options] PATH`
This command will push the state specified by PATH to the currently
configured [backend](/docs/backends).
configured [backend](/docs/configuration/blocks/backends/index.html).
If PATH is "-" then the state data to push is read from stdin. This data
is loaded completely into memory and verified prior to being written to

4
website/docs/configuration-0-11/interpolation.html.md
View File

@ -409,7 +409,7 @@ The supported built-in functions are:
* `timestamp()` - Returns a UTC timestamp string in RFC 3339 format. This string will change with every
invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the
[`ignore_changes`](./resources.html#ignore-changes) lifecycle attribute.
[`ignore_changes`](./resources.html#ignore_changes) lifecycle attribute.
* `timeadd(time, duration)` - Returns a UTC timestamp string corresponding to adding a given `duration` to `time` in RFC 3339 format.
For example, `timeadd("2017-11-22T00:00:00Z", "10m")` produces a value `"2017-11-22T00:10:00Z"`.
@ -424,7 +424,7 @@ The supported built-in functions are:
* `urlencode(string)` - Returns an URL-safe copy of the string.
* `uuid()` - Returns a random UUID string. This string will change with every invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the [`ignore_changes`](./resources.html#ignore-changes) lifecycle attribute.
* `uuid()` - Returns a random UUID string. This string will change with every invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the [`ignore_changes`](./resources.html#ignore_changes) lifecycle attribute.
* `values(map)` - Returns a list of the map values, in the order of the keys
returned by the `keys` function. This function only works on flat maps and

4
website/docs/configuration-0-11/modules.html.md
View File

@ -233,7 +233,7 @@ resource "aws_s3_bucket" "example" {
This approach is recommended in the common case where only a single
configuration is needed for each provider across the entire configuration.
In more complex situations there may be [multiple provider instances](/docs/configuration/providers.html#multiple-provider-instances),
In more complex situations there may be [multiple provider instances](./providers.html#multiple-provider-instances),
or a child module may need to use different provider settings than
its parent. For such situations, it's necessary to pass providers explicitly
as we will see in the next section.
@ -272,7 +272,7 @@ module "example" {
The `providers` argument within a `module` block is similar to
the `provider` argument within a resource as described for
[multiple provider instances](/docs/configuration/providers.html#multiple-provider-instances),
[multiple provider instances](./providers.html#multiple-provider-instances),
but is a map rather than a single string because a module may contain resources
from many different providers.

2
website/docs/configuration-0-11/providers.html.md
View File

@ -220,7 +220,7 @@ may also be used, but currently may cause errors when running `terraform destroy
## Third-party Plugins
Anyone can develop and distribute their own Terraform providers. (See
[Writing Custom Providers](/docs/extend/writing-custom-providers.html) for more
[Writing Custom Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IO/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGE/docs/extend/writing-custom-providers.htmlutm_content=DOCS) for more
about provider development.) These third-party providers must be manually
installed, since `terraform init` cannot automatically download them.

2
website/docs/configuration-0-11/variables.html.md
View File

@ -211,7 +211,7 @@ $ TF_VAR_image=foo terraform apply
```
Maps and lists can be specified using environment variables as well using
[HCL](./syntax.html#HCL) syntax in the value.
[HCL](./syntax.html) syntax in the value.
For a list variable like so:

2
website/docs/configuration/meta-arguments/resource-provider.html.md
View File

@ -51,7 +51,7 @@ ensure that the provider is fully configured before any resource actions
are taken.
The `provider` meta-argument expects
[a `<PROVIDER>.<ALIAS>` reference](/docs/configuration/providers.html#referring-to-alternate-providers),
[a `<PROVIDER>.<ALIAS>` reference](/docs/configuration/providers.html#referring-to-alternate-provider-configurations),
which does not need to be quoted. Arbitrary expressions are not permitted for
`provider` because it must be resolved while Terraform is constructing the
dependency graph, before it is safe to evaluate expressions.

6
website/docs/configuration/outputs.html.md
View File

@ -66,6 +66,8 @@ value as `module.web_server.instance_ip_addr`.
`output` blocks can optionally include `description`, `sensitive`, and `depends_on` arguments, which are described in the following sections.
<a id="description"></a>
### `description` — Output Value Documentation
Because the output values of a module are part of its user interface, you can
@ -85,6 +87,8 @@ string might be included in documentation about the module, and so it should be
written from the perspective of the user of the module rather than its
maintainer. For commentary for module maintainers, use comments.
<a id="sensitive"></a>
### `sensitive` — Suppressing Values in CLI Output
An output can be marked as containing sensitive material using the optional
@ -151,6 +155,8 @@ Sensitive output values are still recorded in the
to access the state data. For more information, see
[_Sensitive Data in State_](/docs/state/sensitive-data.html).
<a id="depends_on"></a>
### `depends_on` — Explicit Output Dependencies
Since output values are just a means for passing data out of a module, it is

2
website/docs/configuration/providers.html.md
View File

@ -80,7 +80,7 @@ empty default configuration for any provider that is not explicitly configured.
## `alias`: Multiple Provider Configurations
[inpage-alias]: #alias-multiple-provider-instances
[inpage-alias]: #alias-multiple-provider-configurations
You can optionally define multiple configurations for the same provider, and
select which one to use on a per-resource or per-module basis. The primary

8
website/docs/configuration/resources.html.md
View File

@ -14,6 +14,7 @@ pages.
<a id="resource-arguments"></a>
<a id="documentation-for-resource-types"></a>
<a id="meta-arguments"></a>
<a id="timeouts"></a>
<a id="operation-timeouts"></a>
## Syntax and Elements of Resource Blocks
@ -66,7 +67,9 @@ This information has moved to
<a id="count-multiple-resource-instances-by-count"></a>
<a id="count-multiple-resource-instances"></a>
<a id="the-count-object"></a>
<a id="count-index"></a>
<a id="referring-to-instances"></a>
<a id="using-expressions-in-count"></a>
<a id="when-to-use-for_each-instead-of-count"></a>
@ -82,6 +85,8 @@ This information has moved to
<a id="for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings"></a>
<a id="the-each-object"></a>
<a id="each-key"></a>
<a id="each-value"></a>
<a id="using-expressions-in-for_each"></a>
<a id="referring-to-instances-1"></a>
<a id="using-sets"></a>
@ -107,6 +112,9 @@ This information has moved to
<a id="lifecycle-lifecycle-customizations"></a>
<a id="prevent_destroy"></a>
<a id="create_before_destroy"></a>
<a id="ignore_changes"></a>
### `lifecycle`

2
website/docs/configuration/variables.html.md
View File

@ -349,6 +349,8 @@ terraform apply -var='image_id_map={"us-east-1":"ami-abc123","us-east-2":"ami-de
The `-var` option can be used any number of times in a single command.
<a id="variable-files"></a>
### Variable Definitions (`.tfvars`) Files
To set lots of variables, it is more convenient to specify their values in

2
website/docs/import/index.html.md
View File

@ -31,7 +31,7 @@ behavior. For more information on this assumption, see
## Currently State Only
The current implementation of Terraform import can only import resources
into the [state](/docs/state). It does not generate configuration. A future
into the [state](/docs/state/). It does not generate configuration. A future
version of Terraform will also generate configuration.
Because of this, prior to running `terraform import` it is necessary to write

2
website/docs/internals/json-format.html.md
View File

@ -56,7 +56,7 @@ The extra wrapping object here will allow for any extension we may need to add i
A plan consists of a prior state, the configuration that is being applied to that state, and the set of changes Terraform plans to make to achieve that.
For ease of consumption by callers, the plan representation includes a partial representation of the values in the final state (using a [value representation](#value-representation)), allowing callers to easily analyze the planned outcome using similar code as for analyzing the prior state.
For ease of consumption by callers, the plan representation includes a partial representation of the values in the final state (using a [value representation](#values-representation)), allowing callers to easily analyze the planned outcome using similar code as for analyzing the prior state.
```javascript
{

2
website/docs/internals/remote-service-discovery.html.md
View File

@ -85,7 +85,7 @@ version 1 of the module registry protocol:
At present, the following service identifiers are in use:
* `login.v1`: [login protocol version 1](/docs/commands/login.html#protocol-v1)
* `login.v1`: [login protocol version 1](/docs/commands/login.html)
* `modules.v1`: [module registry API version 1](module-registry-protocol.html)
* `providers.v1`: [provider registry API version 1](provider-registry-protocol.html)

2
website/docs/modules/providers.html.md
View File

@ -80,7 +80,7 @@ however, specify any of the configuration settings that determine what remote
endpoints the provider will access, such as an AWS region; configuration
settings come from provider _configurations_, and a particular overall Terraform
configuration can potentially have
[several different configurations for the same provider](/docs/configuration/providers.html#alias-multiple-provider-instances).
[several different configurations for the same provider](/docs/configuration/providers.html#alias-multiple-provider-configurations).
If you are writing a shared Terraform module, constrain only the minimum
required provider version using a `>=` constraint. This should specify the

1
website/docs/plugins/basics.html.md
View File

@ -43,7 +43,6 @@ directory, located at `%APPDATA%\terraform.d\plugins` on Windows and
For more information, see:
- [Configuring Providers](/docs/configuration/providers.html)
- [Configuring Providers: Third-party Plugins](/docs/configuration/providers.html#third-party-plugins)
For developer-centric documentation, see:

5
website/docs/plugins/provider.html.md
View File

@ -75,9 +75,8 @@ an official release.
When constructing a new provider from scratch, it's recommended to follow
a similar repository structure as for the existing providers, with the main
package in the repository root and a library package in a subdirectory named
after the provider. For more information, see
[Writing Custom Providers](/docs/extend/writing-custom-providers.html) in the
[Extending Terraform section](/docs/extend/index.html).
after the provider. For more information, see the
[Call APIs with Terraform Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IO/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGE/docs/extend/writing-custom-providers.htmlutm_content=DOCS) collection on HashiCorp Learn.
When making changes only to files within the provider repository, it is _not_
necessary to re-build the main Terraform executable. Note that some packages

9
website/docs/provisioners/index.html.markdown
View File

@ -166,8 +166,13 @@ You must include [a `connection` block](./connection.html) so that Terraform
will know how to communicate with the server.
Terraform includes several built-in provisioners; use the navigation sidebar to
view their documentation. You can also install third-party provisioners in
[the user plugins directory](../configuration/providers.html#third-party-plugins).
view their documentation.
It's also possible to use third-party provisioners as plugins, by placing them
in `%APPDATA%\terraform.d\plugins`, `~/.terraform.d/plugins`, or the same
directory where the Terraform binary is installed. However, we do not recommend
using any provisioners except the built-in `file`, `local-exec`, and
`remote-exec` provisioners.
All provisioners support the `when` and `on_failure` meta-arguments, which
are described below (see [Destroy-Time Provisioners](#destroy-time-provisioners)

6
website/docs/state/locking.html.md
View File

@ -8,7 +8,7 @@ description: |-
# State Locking
If supported by your [backend](/docs/backends), Terraform will lock your
If supported by your [backend](/docs/backends/), Terraform will lock your
state for all operations that could write state. This prevents
others from acquiring the lock and potentially corrupting your state.
@ -21,8 +21,8 @@ If acquiring the lock is taking longer than expected, Terraform will output
a status message. If Terraform doesn't output a message, state locking is
still occurring if your backend supports it.
Not all [backends](/docs/backends) support locking. Please view the list
of [backend types](/docs/backends/types) for details on whether a backend
Not all [backends](/docs/backends/) support locking. Please view the list
of [backend types](/docs/backends/types/) for details on whether a backend
supports locking or not.
## Force Unlock

2
website/docs/state/remote.html.md
View File

@ -19,7 +19,7 @@ which can then be shared between all members of a team. Terraform supports
storing state in [Terraform Cloud](https://www.hashicorp.com/products/terraform/),
[HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.
Remote state is a feature of [backends](/docs/backends), which you can activate
Remote state is a feature of [backends](/docs/backends/), which you can activate
in your configuration's root module.
## Delegation and Teamwork

2
website/docs/state/workspaces.html.md
View File

@ -195,7 +195,7 @@ control, although using a remote backend instead is recommended when there are
multiple collaborators.
For [remote state](/docs/state/remote.html), the workspaces are stored
directly in the configured [backend](/docs/backends). For example, if you
directly in the configured [backend](/docs/backends/). For example, if you
use [Consul](/docs/backends/types/consul.html), the workspaces are stored
by appending the workspace name to the state path. To ensure that
workspace names are stored correctly and safely in all backends, the name

8
website/guides/terraform-provider-development-program.html.md
View File

@ -13,7 +13,7 @@ The Verified badge helps users easily identify and discover integrations develop
![Verified Provider Card](/assets/images/docs/verified-card.png)
-> **Building your own provider?** If you're building your own provider and aren't interested in having HashiCorp officially verify and regularly monitor your provider, please refer to the [Writing Custom Providers guide](https://www.terraform.io/docs/extend/writing-custom-providers.html) and the [Extending Terraform](https://www.terraform.io/docs/extend/index.html) section.
-> **Building your own provider?** If you're building your own provider and aren't interested in having HashiCorp officially verify and regularly monitor your provider, please refer to the [Call APIs with Terraform Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITEhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IOhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGEhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_content=DOCS) collection on HashiCorp Learn and the [Extending Terraform](https://www.terraform.io/docs/extend/index.html) section of the documentation.
## What is a Terraform Provider?
@ -66,7 +66,7 @@ The provider development process is divided into five steps below. By following
![Provider Development Process](/assets/images/docs/program-steps.png)
1. **Apply**: Initial contact between vendor and HashiCorp
2. **Prepare**: Follow documentation while developing the provider
2. **Prepare**: Follow documentation while developing the provider
3. **Verify**: Share public GPG key with HashiCorp
4. **Publish**: Release the provider on the Registry
5. **Support**: Ongoing maintenance and support of the provider by the vendor.
@ -112,7 +112,7 @@ We’ve found the provider development process to be fairly straightforward and
### 3. Verify
At this stage, it is expected that the provider is fully developed, all tests and documentation are in place, and your provider is ready for publishing. In this step, HashiCorp will verify the source and authenticity of the namespace being used to publish the provider by signing your GPG key with a trust signature.
At this stage, it is expected that the provider is fully developed, all tests and documentation are in place, and your provider is ready for publishing. In this step, HashiCorp will verify the source and authenticity of the namespace being used to publish the provider by signing your GPG key with a trust signature.
-> **Important:** This step requires that you have signed and accepted our Technology Partner Agreement. If you have not received this, please see step #1 above.
@ -128,7 +128,7 @@ $ gpg --armor --export "{Key ID or email address}"
Once the verification step is complete please follow the steps on [Publishing a Provider](https://www.terraform.io/docs/registry/providers/publishing.html). This step does not require additional involvement from HashiCorp as publishing is a fully self-service process in the [Terraform Registry](https://registry.terraform.io).
Once completed, your provider should be visible in the Terraform Registry and usable in Terraform. Please confirm that everything looks good, and that documentation is rendering properly.
Once completed, your provider should be visible in the Terraform Registry and usable in Terraform. Please confirm that everything looks good, and that documentation is rendering properly.
### 5. Maintain & Support

15
website/upgrade-guides/0-10.html.markdown
View File

@ -60,9 +60,18 @@ eventually support a similar approach for third-party plugins, but we wish
to ensure the robustness of the installation and versioning mechanisms before
generalizing this feature.
In the mean time,
[the prior mechanisms for installing third-party providers](/docs/plugins/basics.html#installing-a-plugin)
are still supported. Maintainers of third-party providers may optionally
-> **Note:** As of Terraform 0.13, Terraform can automatically install
third-party providers released on the Terraform Registry.
In the mean time, third-party providers can be installed by placing them in the
user plugins directory:
Operating system | User plugins directory
------------------|-----------------------
Windows | `%APPDATA%\terraform.d\plugins`
All other systems | `~/.terraform.d/plugins`
Maintainers of third-party providers may optionally
make use of the new versioning mechanism by naming provider binaries
using the scheme `terraform-provider-NAME_v0.0.1`, where "0.0.1" is an
example version. Terraform expects providers to follow the

8
website/upgrade-guides/0-13.html.markdown
View File

@ -44,7 +44,7 @@ Upgrade guide sections:
* [New Filesystem Layout for Local Copies of Providers](#new-filesystem-layout-for-local-copies-of-providers)
* [Special considerations for in-house providers](#in-house-providers)
* [Destroy-time provisioners may not refer to other resources](#destroy-time-provisioners-may-not-refer-to-other-resources)
* [Data resource reads can no longer be disabled by `-refresh=false`](#data-resource-reads-can-no-longer-be-disabled-by--refresh-false)
* [Data resource reads can no longer be disabled by `-refresh=false`](#data-resource-reads-can-no-longer-be-disabled-by-refresh-false)
* [Frequently Asked Questions](#frequently-asked-questions)
## Before You Upgrade
@ -135,7 +135,7 @@ for a module that must remain compatible with both Terraform v0.12 and
Terraform v0.13; the `terraform 0.13upgrade` result includes a conservative
version constraint for Terraform v0.13 or later, which you can weaken to
`>= 0.12.26` if you follow the guidelines in
[v0.12-Compatible Provider Requirements](/docs/configuration/provider-requirements.html#v012-compatible-provider-requirements).
[v0.12-Compatible Provider Requirements](/docs/configuration/provider-requirements.html#v0-12-compatible-provider-requirements).
Each module must declare its own set of provider requirements, so if you have
a configuration which calls other modules then you'll need to run this upgrade
@ -441,7 +441,7 @@ accurate plan, and so there is no replacement mechanism in Terraform v0.13
to restore the previous behavior.
## Frequently Asked Questions
### Why do I see `-/provider` during init?
### Why do I see `-/provider` during init?
Provider source addresses starting with `registry.terraform.io/-/` are a special
way Terraform marks legacy addresses where the true namespace is unknown. For
@ -473,7 +473,7 @@ While this does not cause any problems for Terraform, it has been confusing. You
may circumvent this by using the `terraform state replace-provider` subcommand
to tell Terraform exactly what provider addresses are required in state.
Continuing from the example above, the following commands tell Terraform the
source address for the `null` and `random` providers:
source address for the `null` and `random` providers:
```
terraform state replace-provider -- -/random registry.terraform.io/hashicorp/random