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

website: Correct formatting for lists in dependency lock docs 

I originally drafted these docs in a context where I was relying on
GitHub's Markdown renderer, and carelessly imported them into the
Terraform website without verifying that the website's Markdown renderer
could process it. This particular quirk has bitten us before: the website
Markdown parser expects follow-on paragraphs in a list item to be indented
at least four spaces, and with less than that it ignores the leading
whitespace altogether and just understands a normal paragraph.

This change will cause the follow-on paragraphs to now correctly render
as part of the bullet points they are intended to be attached to.
This commit is contained in:
Martin Atkins 2020-12-03 08:39:44 -08:00
parent 9935138e1c
commit 323cd4364b
2 changed files with 39 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
website/docs/commands/providers/lock.html.md
View File

@ -25,11 +25,11 @@ automatic approach may not be sufficient:
be able to populate all of the possible package checksums for the selected
provider versions.
If you use `terraform lock` to write the official release checksums for a
provider into the dependency lock file then future `terraform init` runs
will verify the packages available in your selected mirror against the
official checksums previously recorded, giving additional certainty that
the mirror is serving the provider packages it is claiming to.
If you use `terraform lock` to write the official release checksums for a
provider into the dependency lock file then future `terraform init` runs
will verify the packages available in your selected mirror against the
official checksums previously recorded, giving additional certainty that
the mirror is serving the provider packages it is claiming to.
* If your team runs Terraform across a number of different platforms (e.g.
on both Windows and Linux) and the upstream registry for a provider is unable
@ -81,14 +81,14 @@ You can customize the default behavior using the following additional option:
available for the given platform and will save enough package checksums in
the lock file to support _at least_ the specified platforms.
Use this option multiple times to include checksums for multiple target
systems.
Use this option multiple times to include checksums for multiple target
systems.
Target platform names consist of an operating system and a CPU
architecture. For example, `linux_amd64` selects the Linux operating system
running on an AMD64 or x86_64 CPU.
Target platform names consist of an operating system and a CPU
architecture. For example, `linux_amd64` selects the Linux operating system
running on an AMD64 or x86_64 CPU.
There is more detail on this option in the following section.
There is more detail on this option in the following section.
## Specifying Target Platforms

56
website/docs/configuration/dependency-lock.html.md
View File

@ -123,12 +123,12 @@ There are two special considerations with the "trust on first use" model:
your current platform _and_ any other packages that might be available for
other platforms.
In this case, the `terraform init` output will include the fingerprint of
the key that signed the checksums, with a message like
`(signed by a HashiCorp partner, key ID DC9FC6B1FCE47986)`. You may wish to
confirm that you trust the holder of the given key before committing the
lock file containing the signed checksums, or to retrieve and verify the
full set of available packages for the given provider version.
In this case, the `terraform init` output will include the fingerprint of
the key that signed the checksums, with a message like
`(signed by a HashiCorp partner, key ID DC9FC6B1FCE47986)`. You may wish to
confirm that you trust the holder of the given key before committing the
lock file containing the signed checksums, or to retrieve and verify the
full set of available packages for the given provider version.
* If you install a provider for the first time using an alternative
installation method, such as a filesystem or network mirror, Terraform will
@ -137,12 +137,12 @@ There are two special considerations with the "trust on first use" model:
for other platforms and so the configuration will not be usable on any other
platform.
To avoid this problem you can pre-populate checksums for a variety of
different platforms in your lock file using
[the `terraform providers lock` command](/docs/commands/providers/lock.html),
which will then allow future calls to `terraform init` to verify that the
packages available in your chosen mirror match the official packages from
the provider's origin registry.
To avoid this problem you can pre-populate checksums for a variety of
different platforms in your lock file using
[the `terraform providers lock` command](/docs/commands/providers/lock.html),
which will then allow future calls to `terraform init` to verify that the
packages available in your chosen mirror match the official packages from
the provider's origin registry.
## Understanding Lock File Changes
@ -300,27 +300,27 @@ The two hashing schemes currently supported are:
part of the Terraform provider registry protocol and is therefore used for
providers that you install directly from an origin registry.
This hashing scheme captures a SHA256 hash of each of the official `.zip`
packages indexed in the origin registry. This is an effective scheme for
verifying the official release packages when installed from a registry, but
it's not suitable for verifying packages that come from other
[provider installation methods](/docs/commands/cli-config.html#provider-installation),
such as filesystem mirrors using the unpacked directory layout.
This hashing scheme captures a SHA256 hash of each of the official `.zip`
packages indexed in the origin registry. This is an effective scheme for
verifying the official release packages when installed from a registry, but
it's not suitable for verifying packages that come from other
[provider installation methods](/docs/commands/cli-config.html#provider-installation),
such as filesystem mirrors using the unpacked directory layout.
* `h1:`: a mnemonic for "hash scheme 1", which is the current preferred hashing
scheme.
Hash scheme 1 is also a SHA256 hash, but is one computed from the _contents_
of the provider distribution package, rather than of the `.zip` archive
it's contained within. This scheme therefore has the advantage that it can
be calculated for an official `.zip` file, an unpacked directory with the
same contents, or a recompressed `.zip` file which contains the same files
but potentially different metadata or compression schemes.
Hash scheme 1 is also a SHA256 hash, but is one computed from the _contents_
of the provider distribution package, rather than of the `.zip` archive
it's contained within. This scheme therefore has the advantage that it can
be calculated for an official `.zip` file, an unpacked directory with the
same contents, or a recompressed `.zip` file which contains the same files
but potentially different metadata or compression schemes.
Due to the limited scope of the `zh:` scheme, Terraform will
opportunistically add in the corresponding `h1:` checksums as it learns
of them, which is what caused the addition of a second `h1:` checksum
in the example change shown above.
Due to the limited scope of the `zh:` scheme, Terraform will
opportunistically add in the corresponding `h1:` checksums as it learns
of them, which is what caused the addition of a second `h1:` checksum
in the example change shown above.
Terraform will add a new hash to an existing provider only if the hash is
calculated from a package that _also_ matches one of the existing hashes. In