From ab29b187b1b206e0415e514e5dbeb4d40b2d79d6 Mon Sep 17 00:00:00 2001 From: Dan Barr Date: Thu, 4 Aug 2022 18:42:53 -0400 Subject: [PATCH] Fix capitalizations in docs * Brands (HashiCorp, VMware) * Various OS/languages (Windows, Unix, Linux, POSIX, Python, PowerShell) * Various abbreviations (ID, VM, HTTP) --- website/README.md | 2 +- website/content/community-tools.mdx | 4 +-- .../content/docs/commands/hcl2_upgrade.mdx | 4 +-- website/content/docs/communicators/winrm.mdx | 10 +++---- website/content/docs/configure.mdx | 16 +++++------ website/content/docs/debugging.mdx | 6 ++-- website/content/docs/index.mdx | 2 +- website/content/docs/partnerships.mdx | 2 +- .../docs/plugins/creation/custom-builders.mdx | 2 +- .../content/docs/plugins/creation/index.mdx | 2 +- website/content/docs/plugins/hcp-support.mdx | 2 +- .../content/docs/post-processors/artifice.mdx | 8 +++--- .../content/docs/post-processors/manifest.mdx | 4 +-- .../docs/post-processors/shell-local.mdx | 20 ++++++------- website/content/docs/provisioners/file.mdx | 2 +- .../content/docs/provisioners/powershell.mdx | 12 ++++---- .../content/docs/provisioners/shell-local.mdx | 28 +++++++++---------- .../blocks/build/hcp_packer_registry.mdx | 4 +-- .../hcl_templates/contextual-variables.mdx | 12 ++++---- .../templates/hcl_templates/expressions.mdx | 4 +-- .../functions/encoding/csvdecode.mdx | 4 +-- .../hcl_templates/functions/uuid/uuidv4.mdx | 4 +-- .../docs/templates/hcl_templates/index.mdx | 2 +- .../templates/hcl_templates/variables.mdx | 2 +- .../legacy_json_templates/engine.mdx | 10 +++---- .../templates/legacy_json_templates/index.mdx | 2 +- website/content/guides/1.7-plugin-upgrade.mdx | 2 +- .../autounattend_windows.mdx | 10 +++---- .../preseed_ubuntu.mdx | 2 +- .../packer-on-cicd/build-virtualbox-image.mdx | 2 +- .../packer-on-cicd/pipelineing-builds.mdx | 4 +-- .../hcp-packer-image/DatasourceOutput.mdx | 4 +-- .../hcp-packer-iteration/DatasourceOutput.mdx | 2 +- .../DatasourceOutput.mdx | 4 +-- .../ParBuild-not-required.mdx | 4 +-- .../ParImage-not-required.mdx | 2 +- .../from-1.5/variables/custom-validation.mdx | 8 +++--- .../multistep/commonsteps/HTTPConfig.mdx | 2 +- .../partials/plugins/installing-plugins.mdx | 20 ++++++------- .../provisioners/community_provisioners.mdx | 2 +- 40 files changed, 119 insertions(+), 119 deletions(-) diff --git a/website/README.md b/website/README.md index 4c5ee4d40..601644c9c 100644 --- a/website/README.md +++ b/website/README.md @@ -45,7 +45,7 @@ The website can be run locally through node.js or [Docker](https://www.docker.co Running the site locally is simple. Provided you have Docker installed, clone this repo, run `make`, and then visit `http://localhost:3000`. -The docker image is pre-built with all the website dependencies installed, which is what makes it so quick and simple, but also means if you need to change dependencies and test the changes within Docker, you'll need a new image. If this is something you need to do, you can run `make build-image` to generate a local Docker image with updated dependencies, then `make website-local` to use that image and preview. +The Docker image is pre-built with all the website dependencies installed, which is what makes it so quick and simple, but also means if you need to change dependencies and test the changes within Docker, you'll need a new image. If this is something you need to do, you can run `make build-image` to generate a local Docker image with updated dependencies, then `make website-local` to use that image and preview. ### With Node diff --git a/website/content/community-tools.mdx b/website/content/community-tools.mdx index 40ede7e8d..42c1cd4ab 100644 --- a/website/content/community-tools.mdx +++ b/website/content/community-tools.mdx @@ -65,8 +65,8 @@ contribution here! - [packer-config](https://github.com/ianchesal/packer-config) - a Ruby model that lets you build Packer configurations in Ruby - [racker](https://github.com/aspring/racker) - an opinionated Ruby DSL for generating Packer templates -- [packerlicious](https://github.com/mayn/packerlicious) - a python library for generating Packer templates -- [packer.py](https://github.com/mayn/packer.py) - a python library for executing Packer CLI commands +- [packerlicious](https://github.com/mayn/packerlicious) - a Python library for generating Packer templates +- [packer.py](https://github.com/mayn/packer.py) - a Python library for executing Packer CLI commands ## Other diff --git a/website/content/docs/commands/hcl2_upgrade.mdx b/website/content/docs/commands/hcl2_upgrade.mdx index 308949255..f18874cdf 100644 --- a/website/content/docs/commands/hcl2_upgrade.mdx +++ b/website/content/docs/commands/hcl2_upgrade.mdx @@ -75,7 +75,7 @@ variable "aws_secret_key" { ## Go template functions -`hcl2_upgrade` will do its best to transform your go _template calls_ to HCL2, +`hcl2_upgrade` will do its best to transform your Go _template calls_ to HCL2, here is the list of calls that should get transformed: - `` {{ user `my_var` }} `` becomes `${var.my_var}`. @@ -87,7 +87,7 @@ here is the list of calls that should get transformed: will be created for all generated files. - `` {{ build `ID` }} `` becomes `${build.ID}`. -The rest of the calls should remain go template calls for now, this will be +The rest of the calls should remain Go template calls for now, this will be improved over time. -> **Note**: The `hcl2_upgrade` command does its best to transform template diff --git a/website/content/docs/communicators/winrm.mdx b/website/content/docs/communicators/winrm.mdx index c549bf7a2..b7a98b088 100644 --- a/website/content/docs/communicators/winrm.mdx +++ b/website/content/docs/communicators/winrm.mdx @@ -17,7 +17,7 @@ The WinRM communicator is not the default communicator, so you will always have to set the `"communicator": "winrm",` template option explicitly. In addition, you will almost always have to provide a pre-run script that enables and configures WinRM on the guest machine. This will generally be in the form of a -powershell script or a batch file. +PowerShell script or a batch file. If you are building from a brand-new and unconfigured operating system image, you will need to provide this pre-run script as part of your @@ -58,7 +58,7 @@ to be able to connect via WinRM 6. If necessary, generate a self-signed certificate or provide a real certificate to the WinRM listener. -#### Configuring WinRM in VMWare +#### Configuring WinRM in VMware If you are configuring WinRM using an Autounattend.xml, the simplest way to set up WinRM is to put the configuration commands directly into the Autounattend @@ -84,7 +84,7 @@ Autounattend file. ``` -It is also possible to call powershell scripts in a similar manner. +It is also possible to call PowerShell scripts in a similar manner. The winrmConfig.bat referenced above can be as simple as @@ -108,7 +108,7 @@ Please note that the above batch file is _extremely_ simplistic, and not secure. It is intended to be an example of the bare minimum configuration. Below, you'll find a more complicated example of a more secure WinRM configuration process. -This batch file will only work for http connections, not https, but will enable +This batch file will only work for HTTP connections, not HTTPS, but will enable you to connect using only the username and password created earlier in the Autounattend file. The above batchfile will allow you to connect using a very simple Packer config: @@ -119,7 +119,7 @@ simple Packer config: "winrm_password": "SecretPassword" ``` -A more complex example of a powershell script used for configuration can be seen +A more complex example of a PowerShell script used for configuration can be seen below. ```powershell diff --git a/website/content/docs/configure.mdx b/website/content/docs/configure.mdx index 183857bec..681b5316c 100644 --- a/website/content/docs/configure.mdx +++ b/website/content/docs/configure.mdx @@ -19,7 +19,7 @@ Plugins and core configuration files can exist in the home directory of Packer. The home directory of Packer will be the first one of the following env values to be set : -| unix | windows | +| Unix | Windows | | ---------------------- | --------------------- | | `${PACKER_CONFIG_DIR}` | `%PACKER_CONFIG_DIR%` | | `${APPDATA}` | `%APPDATA%` | @@ -34,7 +34,7 @@ to be set : Packer can optionally read a JSON file for the end user to set core settings. The config file of Packer will be looked up on the following paths: -| unix | windows | +| Unix | Windows | | ------------------------------- | -------------------------------- | | `${PACKER_CONFIG}` | `%PACKER_CONFIG%` | | `PACKER_HOME_DIR/.packerconfig` | `PACKER_HOME_DIR/packer.config/` | @@ -46,18 +46,18 @@ The config file of Packer will be looked up on the following paths: Packer's configuration directory can potentially contain plugins and internal Packer files. The config dir of Packer will be looked up on the following paths: -| unix | windows | +| Unix | Windows | | --------------------------- | --------------------------- | | `PACKER_HOME_DIR/.packer.d` | `PACKER_HOME_DIR/packer.d/` | Examples: -- On a 'unix' system, if the `$PACKER_CONFIG_DIR` env var is set to +- On a Unix system, if the `$PACKER_CONFIG_DIR` env var is set to `/home/packer`, the config directory will be: `/home/packer/.packer.d/` and other values will not be checked. -- On a 'unix' system, if the `HOME` env var is `/home/azr` or the `USER` env var +- On a Unix system, if the `HOME` env var is `/home/azr` or the `USER` env var is `azr`, then the config directory will default to `/home/azr/.packer.d/`. -- On a 'windows' system, if the `PACKER_CONFIG_DIR` env var is set to `C:/`,the +- On a Windows system, if the `PACKER_CONFIG_DIR` env var is set to `C:/`,the config directory will be: `C:/packer.d/` and other values will not be checked. ## Packer's plugin directory @@ -139,8 +139,8 @@ each can be found below: - `PACKER_PLUGIN_PATH` - a PATH variable for finding third-party packer plugins. For example: `~/custom-dir-1:~/custom-dir-2`. Separate directories in - the PATH string using a colon (`:`) on posix systems and a semicolon (`;`) on - windows systems. The above example path would be able to find a provisioner + the PATH string using a colon (`:`) on POSIX systems and a semicolon (`;`) on + Windows systems. The above example path would be able to find a provisioner named `packer-provisioner-foo` in either `~/custom-dir-1/packer-provisioner-foo` or `~/custom-dir-2/packer-provisioner-foo`. See the documentation on [plugin diff --git a/website/content/docs/debugging.mdx b/website/content/docs/debugging.mdx index de591d4da..0adad6c9d 100644 --- a/website/content/docs/debugging.mdx +++ b/website/content/docs/debugging.mdx @@ -81,7 +81,7 @@ homed in on the problem is usually enough. ### Debugging Packer in Powershell/Windows In Windows you can set the detailed logs environmental variable `PACKER_LOG` or -the log variable `PACKER_LOG_PATH` using powershell environment variables. For +the log variable `PACKER_LOG_PATH` using PowerShell environment variables. For example: ```powershell @@ -138,10 +138,10 @@ On Unix systems, you can check what your file descriptor limit is with ## Issues when using long temp directory -Packer uses unix sockets internally, which are created inside the default +Packer uses Unix sockets internally, which are created inside the default directory for temporary files. Some operating systems place a limit on the length of the socket name, usually between 80 and 110 characters. If you get an -error like this (for any builder, not just docker): +error like this (for any builder, not just Docker): ```text Failed to initialize build 'docker': error initializing builder 'docker': plugin exited before we could connect diff --git a/website/content/docs/index.mdx b/website/content/docs/index.mdx index 2758108db..95e69358b 100644 --- a/website/content/docs/index.mdx +++ b/website/content/docs/index.mdx @@ -8,7 +8,7 @@ page_title: Documentation [Packer](https://www.packer.io/) is an open source tool that enables you to create identical machine images for multiple platforms from a single source template. A common use case is creating "golden images" that teams across an organization can use in cloud infrastructure. -To install Packer and learn the standard Packer workflow, try the [Get Started tutorials](https://learn.hashicorp.com/packer) on Hashicorp Learn. +To install Packer and learn the standard Packer workflow, try the [Get Started tutorials](https://learn.hashicorp.com/packer) on HashiCorp Learn. ## HCP Packer diff --git a/website/content/docs/partnerships.mdx b/website/content/docs/partnerships.mdx index d0096c0c4..58e4397a8 100644 --- a/website/content/docs/partnerships.mdx +++ b/website/content/docs/partnerships.mdx @@ -38,7 +38,7 @@ Main Packer categories for partners to integrate with include: - **Data Sources** - Data Sources allow users to retrieve values from a remote API and store them as variables in the Packer configuration template. An example is the [AWS secrets manager](/docs/datasources/amazon/secretsmanager) data source. - **Builders** - - Builders manage the VM lifecycle. They manage launching a vm/instance, running provisioners against that instance, shutting the instance down, and saving an artifact image from that instance. Your builder handles all of the setup and cleanup costs associated with creating the output image artifact. + - Builders manage the VM lifecycle. They manage launching a VM/instance, running provisioners against that instance, shutting the instance down, and saving an artifact image from that instance. Your builder handles all of the setup and cleanup costs associated with creating the output image artifact. - **Provisioners** - Provisioners are run against the instance launched by the builder. They generally provide an interface for interacting with a particular provisioning tool, such as Ansible, Puppet, or Chef. - **Post-Processors** diff --git a/website/content/docs/plugins/creation/custom-builders.mdx b/website/content/docs/plugins/creation/custom-builders.mdx index 6694363c7..457c39acb 100644 --- a/website/content/docs/plugins/creation/custom-builders.mdx +++ b/website/content/docs/plugins/creation/custom-builders.mdx @@ -11,7 +11,7 @@ Packer Builders are the components of Packer responsible for creating a virtual machine, bringing it to a point where it can be provisioned, and then turning that provisioned virtual machine into a machine image. Several builders are officially maintained and distributed by the HashiCorp Packer team -- among -these are builders for creating images on Amazon EC2, VMWare, Google +these are builders for creating images on Amazon EC2, VMware, Google Compute Engine, and many more. You can find documentation for how to use these official builders [here](/docs/builders). It is also possible to write custom builders using the Packer plugin interface, and this page documents how to do diff --git a/website/content/docs/plugins/creation/index.mdx b/website/content/docs/plugins/creation/index.mdx index d3721447a..36f4dd850 100644 --- a/website/content/docs/plugins/creation/index.mdx +++ b/website/content/docs/plugins/creation/index.mdx @@ -28,7 +28,7 @@ recommend getting a bit more comfortable before you dive into writing plugins. ### Plugin System Architecture -A Packer plugin is just a go binary. Instead of loading plugins directly into a +A Packer plugin is just a Go binary. Instead of loading plugins directly into a running application, Packer runs each plugin as a _separate application_. The multiple separate Packer plugin processes communicate with the Core using an RPC defined in the packer-plugin SDK. The Packer core itself is responsible diff --git a/website/content/docs/plugins/hcp-support.mdx b/website/content/docs/plugins/hcp-support.mdx index 8b6e15fa2..4fb51fa7e 100644 --- a/website/content/docs/plugins/hcp-support.mdx +++ b/website/content/docs/plugins/hcp-support.mdx @@ -46,7 +46,7 @@ type Image struct { // Labels represents additional details about an image that a builder or post-processor may with to provide for a given build. // Any additional metadata will be made available as build labels within a HCP Packer registry iteration. Labels map[string]string - // SourceImageID is the cloud image id of the image that was used as the + // SourceImageID is the cloud image ID of the image that was used as the // source for this image. If set, the HCP Packer registry will be able // link the parent and child images for ancestry visualizations and // dependency tracking. diff --git a/website/content/docs/post-processors/artifice.mdx b/website/content/docs/post-processors/artifice.mdx index b946b8d7f..e47fbf013 100644 --- a/website/content/docs/post-processors/artifice.mdx +++ b/website/content/docs/post-processors/artifice.mdx @@ -6,9 +6,9 @@ description: > artifacts you specify. The primary use-case is to build artifacts inside a - packer builder -- for example, spinning up an EC2 instance to build a docker + packer builder -- for example, spinning up an EC2 instance to build a Docker - container -- and then extracting the docker container and throwing away the + container -- and then extracting the Docker container and throwing away the EC2 instance. @@ -35,7 +35,7 @@ post-processors. A major benefit of this is that you can modify builder artifacts using shell-local and pass those modified artifacts into post-processors that may not have worked with the original builder. -For example, maybe you want to export a docker container from an amazon-ebs +For example, maybe you want to export a Docker container from an amazon-ebs builder and then use Docker-push to put that Docker container into your Docker Hub account. @@ -170,4 +170,4 @@ result. ``` You can create multiple post-processor chains to handle multiple builders (for -example, building linux and windows binaries during the same build). +example, building Linux and Windows binaries during the same build). diff --git a/website/content/docs/post-processors/manifest.mdx b/website/content/docs/post-processors/manifest.mdx index 5e439e1d6..675224394 100644 --- a/website/content/docs/post-processors/manifest.mdx +++ b/website/content/docs/post-processors/manifest.mdx @@ -17,7 +17,7 @@ Artifact BuilderId: `packer.post-processor.manifest` The manifest post-processor writes a JSON file with a list of all of the artifacts packer produces during a run. If your Packer template includes multiple builds, this helps you keep track of which output artifacts (files, -AMI IDs, docker containers, etc.) correspond to each build. +AMI IDs, Docker containers, etc.) correspond to each build. The manifest post-processor is invoked each time a build completes and _updates_ data in the manifest file. Builds are identified by name and type, @@ -194,7 +194,7 @@ Example usage: The manifest can be very useful for cleaning up old artifacts, or printing important values to logs. The following example uses jq, a command-line tool for -parsing json output, to find and echo the AWS ami-id of an ami created by a +parsing json output, to find and echo the AWS ami-id of an AMI created by a build. ```bash diff --git a/website/content/docs/post-processors/shell-local.mdx b/website/content/docs/post-processors/shell-local.mdx index 0d0f786e6..7d16aa716 100644 --- a/website/content/docs/post-processors/shell-local.mdx +++ b/website/content/docs/post-processors/shell-local.mdx @@ -173,17 +173,17 @@ Optional parameters: on specific operating systems. By default, shell-local will always run if `only_on` is not set." -- `use_linux_pathing` (bool) - This is only relevant to windows hosts. If you +- `use_linux_pathing` (bool) - This is only relevant to Windows hosts. If you are running Packer in a Windows environment with the Windows Subsystem for Linux feature enabled, and would like to invoke a bash script rather than invoking a Cmd script, you'll need to set this flag to true; it tells - Packer to use the linux subsystem path for your script rather than the + Packer to use the Linux subsystem path for your script rather than the Windows path. (e.g. /mnt/c/path/to/your/file instead of C:/path/to/your/file). Please see the example below for more guidance on how to use this feature. If you are not on a Windows host, or you do not intend to use the shell-local post-processor to run a bash script, please ignore this option. If you set this flag to true, you still need to provide - the standard windows path to the script when providing a `script`. This is + the standard Windows path to the script when providing a `script`. This is a beta feature. - `valid_exit_codes` (list of ints) - Valid exit codes for the script. By @@ -389,7 +389,7 @@ _must_ be extra careful to `exit 0` when necessary. ### Windows Host -Example of running a .cmd file on windows: +Example of running a .cmd file on Windows: @@ -419,7 +419,7 @@ Contents of `test_cmd.cmd`: echo %SHELLLOCALTEST% -Example of running an inline command on windows: Required customization: +Example of running an inline command on Windows: Required customization: tempfile_extension @@ -448,7 +448,7 @@ post-processor "shell-local" { -Example of running a bash command on windows using WSL: Required +Example of running a bash command on Windows using WSL: Required customizations: `use_linux_pathing` and `execute_command`: @@ -515,7 +515,7 @@ post-processor "shell-local" { -Example of running a powershell script on windows as "inline": Required +Example of running a PowerShell script on Windows as "inline": Required customizations: `env_var_format`, `tempfile_extension`, and `execute_command` @@ -550,7 +550,7 @@ post-processor "shell-local" { ### Unix Host -Example of running a Shell script on unix: +Example of running a Shell script on Unix: @@ -576,7 +576,7 @@ post-processor "shell-local" { -Example of running a bash "inline" on unix: +Example of running a bash "inline" on Unix: @@ -603,7 +603,7 @@ post-processor "shell-local" { -Example of running a python script on unix: +Example of running a Python script on Unix: diff --git a/website/content/docs/provisioners/file.mdx b/website/content/docs/provisioners/file.mdx index 4b320c536..3f7d3c5ed 100644 --- a/website/content/docs/provisioners/file.mdx +++ b/website/content/docs/provisioners/file.mdx @@ -188,5 +188,5 @@ using the file provisioner on Windows, it's suggested that you set up an SSH server and use the [ssh communicator](/docs/communicators/ssh). If you only want to transfer files to your guest, and if your builder supports it, you may also use the `http_directory` or `http_content` directives. This will cause that -directory to be available to the guest over http, and set the environment +directory to be available to the guest over HTTP, and set the environment variable `PACKER_HTTP_ADDR` to the address. diff --git a/website/content/docs/provisioners/powershell.mdx b/website/content/docs/provisioners/powershell.mdx index c1248dd14..1000748b4 100644 --- a/website/content/docs/provisioners/powershell.mdx +++ b/website/content/docs/provisioners/powershell.mdx @@ -205,9 +205,9 @@ provisioner "powershell" { -- `execution_policy` - To run ps scripts on windows packer defaults this to +- `execution_policy` - To run ps scripts on Windows, Packer defaults this to "bypass" and wraps the command to run. Setting this to "none" will prevent - wrapping, allowing to see exit codes on docker for windows. Possible values + wrapping, allowing to see exit codes on Docker for Windows. Possible values are `bypass`, `allsigned`, `default`, `remotesigned`, `restricted`, `undefined`, `unrestricted`, and `none`. @@ -244,7 +244,7 @@ provisioner "powershell" { exists in order to deal with times when SSH may restart, such as a system reboot. Set this to a higher value if reboots take a longer amount of time. -- `pause_after` (string) - Wait the amount of time after provisioning a powershell +- `pause_after` (string) - Wait the amount of time after provisioning a PowerShell script, this pause be taken if all previous steps were successful. @include 'provisioners/common-config.mdx' @@ -371,7 +371,7 @@ The above snippet should result in the following output on the Packer console: ```shell-session ==> amazon-ebs: Provisioning with Powershell... -==> amazon-ebs: Provisioning with powershell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner508190439 +==> amazon-ebs: Provisioning with PowerShell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner508190439 amazon-ebs: A literal dollar $ must be escaped amazon-ebs: A literal backtick ` must be escaped amazon-ebs: Here "double quotes" must be escaped @@ -468,10 +468,10 @@ The above snippet should result in the following output on the Packer console: ```shell-session ==> amazon-ebs: Provisioning with Powershell... -==> amazon-ebs: Provisioning with powershell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner961728919 +==> amazon-ebs: Provisioning with PowerShell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner961728919 amazon-ebs: The dollar in the elevated_password is interpreted correctly ==> amazon-ebs: Provisioning with Powershell... -==> amazon-ebs: Provisioning with powershell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner142826554 +==> amazon-ebs: Provisioning with PowerShell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner142826554 amazon-ebs: In the following examples the special character is interpreted correctly: amazon-ebs: The dollar in VAR1: A$Dollar amazon-ebs: The backtick in VAR2: A`Backtick diff --git a/website/content/docs/provisioners/shell-local.mdx b/website/content/docs/provisioners/shell-local.mdx index 282260bf9..4e54f9892 100644 --- a/website/content/docs/provisioners/shell-local.mdx +++ b/website/content/docs/provisioners/shell-local.mdx @@ -80,7 +80,7 @@ Exactly _one_ of the following is required: - `command` (string) - This is a single command to execute. It will be written to a temporary file and run using the `execute_command` call below. - If you are building a windows vm on AWS, Azure, Google Compute, or OpenStack + If you are building a Windows VM on AWS, Azure, Google Compute, or OpenStack and would like to access the generated password that Packer uses to connect to the instance via WinRM, you can use the template variable `{{.WinRMPassword}}` to set this as an environment variable. @@ -112,7 +112,7 @@ Optional parameters: inject prior to the `execute_command`. The format should be `key=value`. Packer injects some environmental variables by default into the environment, as well, which are covered in the section below. If you are - building a windows vm on AWS, Azure, Google Compute, or OpenStack and would + building a Windows VM on AWS, Azure, Google Compute, or OpenStack and would like to access the generated password that Packer uses to connect to the instance via WinRM, you can use the template variable `{{.WinRMPassword}}` to set this as an environment variable. For example: @@ -127,7 +127,7 @@ Optional parameters: - `execute_command` (array of strings) - The command used to execute the script. By default this is `["/bin/sh", "-c", "{{.Vars}}", "{{.Script}}"]` - on unix and `["cmd", "/c", "{{.Vars}}", "{{.Script}}"]` on windows. This is + on Unix and `["cmd", "/c", "{{.Vars}}", "{{.Script}}"]` on Windows. This is treated as a [template engine](/docs/templates/legacy_json_templates/engine). There are two available variables: `Script`, which is the path to the script to run, and `Vars`, which is the list of `environment_vars`, if configured. @@ -147,7 +147,7 @@ Optional parameters: sake of clarity, as even when you set only a single `command` to run, Packer writes it to a temporary file and then runs it as a script. - If you are building a windows vm on AWS, Azure, Google Compute, or OpenStack + If you are building a Windows VM on AWS, Azure, Google Compute, or OpenStack and would like to access the generated password that Packer uses to connect to the instance via WinRM, you can use the template variable `{{.WinRMPassword}}` to set this as an environment variable. @@ -166,11 +166,11 @@ Optional parameters: on specific operating systems. By default, shell-local will always run if `only_on` is not set." -- `use_linux_pathing` (bool) - This is only relevant to windows hosts. If you +- `use_linux_pathing` (bool) - This is only relevant to Windows hosts. If you are running Packer in a Windows environment with the Windows Subsystem for Linux feature enabled, and would like to invoke a bash script rather than invoking a Cmd script, you'll need to set this flag to true; it tells - Packer to use the linux subsystem path for your script rather than the + Packer to use the Linux subsystem path for your script rather than the Windows path. (e.g. /mnt/c/path/to/your/file instead of C:/path/to/your/file). Please see the example below for more guidance on how to use this feature. If you are not on a Windows host, or you do not @@ -316,7 +316,7 @@ _must_ be extra careful to `exit 0` when necessary. ### Windows Host -Example of running a .cmd file on windows: +Example of running a .cmd file on Windows: @@ -346,7 +346,7 @@ Contents of "test_cmd.cmd": echo %SHELLLOCALTEST% -Example of running an inline command on windows: Required customization: +Example of running an inline command on Windows: Required customization: tempfile_extension @@ -375,7 +375,7 @@ provisioner "shell-local" { -Example of running a bash command on windows using WSL: Required +Example of running a bash command on Windows using WSL: Required customizations: use_linux_pathing and execute_command @@ -411,7 +411,7 @@ Contents of `example_bash.sh`: #!/bin/bash echo $SHELLLOCALTEST -Example of running a powershell script on windows: Required customizations: +Example of running a PowerShell script on Windows: Required customizations: `env_var_format` and `execute_command` @@ -442,7 +442,7 @@ provisioner "shell-local" { -Example of running a powershell script on windows as "inline": Required +Example of running a PowerShell script on Windows as "inline": Required customizations: `env_var_format`, `tempfile_extension`, and `execute_command` @@ -477,7 +477,7 @@ provisioner "shell-local" { ### Unix Host -Example of running a Shell script on unix: +Example of running a Shell script on Unix: @@ -503,7 +503,7 @@ provisioner "shell-local" { -Example of running a Shell script "inline" on unix: +Example of running a Shell script "inline" on Unix: @@ -530,7 +530,7 @@ provisioner "shell-local" { -Example of running a Python script on unix: +Example of running a Python script on Unix: diff --git a/website/content/docs/templates/hcl_templates/blocks/build/hcp_packer_registry.mdx b/website/content/docs/templates/hcl_templates/blocks/build/hcp_packer_registry.mdx index 4c1995e67..964fc4d73 100644 --- a/website/content/docs/templates/hcl_templates/blocks/build/hcp_packer_registry.mdx +++ b/website/content/docs/templates/hcl_templates/blocks/build/hcp_packer_registry.mdx @@ -59,12 +59,12 @@ Some nice description about the image which artifact is being published to HCP P `HCP_PACKER_BUCKET_NAME` is set. - `bucket_labels` (map[string]string) - Map of labels. Can provide any information, - such as tools versions (e.g. go 1.17, python 3.5, etc...). The bucket labels will + such as tools versions (e.g. Go 1.17, Python 3.5, etc...). The bucket labels will appear at the image's main page and will be updated whenever it is changed and a new iteration for the bucket is pushed to the HCP Packer registry. - `build_labels` (map[string]string) - Map of labels. Can provide any information, - such as tools versions (e.g. go 1.17, python 3.5, etc...). The build labels will + such as tools versions (e.g. Go 1.17, Python 3.5, etc...). The build labels will appear in the build section of an iteration. Build labels are specific to an iteration and will be added to a build when is pushed to the HCP Packer registry. Updates to build labels on a completed iteration is not allowed. diff --git a/website/content/docs/templates/hcl_templates/contextual-variables.mdx b/website/content/docs/templates/hcl_templates/contextual-variables.mdx index ff4b56a56..3bffadee2 100644 --- a/website/content/docs/templates/hcl_templates/contextual-variables.mdx +++ b/website/content/docs/templates/hcl_templates/contextual-variables.mdx @@ -39,19 +39,19 @@ Here is the list of available build variables: - **name** Represents the name of the build block being run. This is different than the name of the source block being run. -- **ID**: Represents the vm being provisioned. For example, in Amazon it is the instance id; in digitalocean, - it is the droplet id; in Vmware, it is the vm name. +- **ID**: Represents the VM being provisioned. For example, in Amazon it is the instance ID; in DigitalOcean, + it is the Droplet ID; in VMware, it is the VM name. - **Host**, **Port**, **User** and **Password**: The host, port, user, and password that Packer uses to access the machine. Useful for using the shell local provisioner to run Ansible or Inspec against the provisioned instance. - **ConnType**: Type of communicator being used. For example, for SSH communicator this will be "ssh". -- **PackerRunUUID**: Current build's unique id. Can be used to specify build artifacts. +- **PackerRunUUID**: Current build's unique ID. Can be used to specify build artifacts. An example of that, is when multiple builds runs at the same time producing the same artifact. - It's possible to differentiate these artifacts by naming them with the builds' unique ids. + It's possible to differentiate these artifacts by naming them with the builds' unique IDs. -- **PackerHTTPIP**, **PackerHTTPPort**, and **PackerHTTPAddr**: HTTP IP, port, and address of the file server Packer creates to serve items in the "http" dir to the vm. The HTTP address is displayed in the format `IP:PORT`. +- **PackerHTTPIP**, **PackerHTTPPort**, and **PackerHTTPAddr**: HTTP IP, port, and address of the file server Packer creates to serve items in the "http" dir to the VM. The HTTP address is displayed in the format `IP:PORT`. - **SSHPublicKey** and **SSHPrivateKey**: The public and private key that Packer uses to connect to the instance. These are unique to the SSH communicator and are unset when using other communicators. @@ -162,4 +162,4 @@ You can also add this value to post-processors, for example to add to a manifest } } -``` \ No newline at end of file +``` diff --git a/website/content/docs/templates/hcl_templates/expressions.mdx b/website/content/docs/templates/hcl_templates/expressions.mdx index 769c8a1a5..5eb7a3bd0 100644 --- a/website/content/docs/templates/hcl_templates/expressions.mdx +++ b/website/content/docs/templates/hcl_templates/expressions.mdx @@ -203,7 +203,7 @@ A _splat expression_ provides a more concise way to express a common operation that could otherwise be performed with a `for` expression. If `var.list` is a list of objects that all have an attribute `id`, then a list -of the ids could be produced with the following `for` expression: +of the IDs could be produced with the following `for` expression: ```hcl [for o in var.list : o.id] @@ -248,7 +248,7 @@ may not produce a tuple value: aws_instance.example[*].id ``` -The above will produce a list of ids whether `aws_instance.example` has `count` +The above will produce a list of IDs whether `aws_instance.example` has `count` set or not, avoiding the need to revise various other expressions in the configuration when a particular resource switches to and from having `count` set. diff --git a/website/content/docs/templates/hcl_templates/functions/encoding/csvdecode.mdx b/website/content/docs/templates/hcl_templates/functions/encoding/csvdecode.mdx index d8653a4c7..abd073ec6 100644 --- a/website/content/docs/templates/hcl_templates/functions/encoding/csvdecode.mdx +++ b/website/content/docs/templates/hcl_templates/functions/encoding/csvdecode.mdx @@ -43,7 +43,7 @@ You can use the result of `csvdecode` with to describe a collection of similar objects whose differences are described by the rows in the given CSV file. -There must be one column in the CSV file that can serve as a unique id for each +There must be one column in the CSV file that can serve as a unique ID for each row, which we can then use as the tracking key for the individual instances in the `for_each` expression. For example: @@ -91,5 +91,5 @@ then you could instead use to define an object for each CSV row, with each one identified by its index into the list returned by `csvdecode`. However, in that case any future updates to the CSV may be disruptive if they change the positions of particular objects in -the list. We recommend using `for_each` with a unique id column to make +the list. We recommend using `for_each` with a unique ID column to make behavior more predictable on future changes. diff --git a/website/content/docs/templates/hcl_templates/functions/uuid/uuidv4.mdx b/website/content/docs/templates/hcl_templates/functions/uuid/uuidv4.mdx index c1e608861..6fc9430af 100644 --- a/website/content/docs/templates/hcl_templates/functions/uuid/uuidv4.mdx +++ b/website/content/docs/templates/hcl_templates/functions/uuid/uuidv4.mdx @@ -1,13 +1,13 @@ --- page_title: v4 - uuid - Functions - Configuration Language -description: The uuidv4 function generates a unique id. +description: The uuidv4 function generates a unique ID. --- # `uuidv4` Function `uuidv4` generates a unique identifier string. -The id is a generated and formatted as required by [RFC 4122 section +The ID is a generated and formatted as required by [RFC 4122 section 4.4](https://tools.ietf.org/html/rfc4122#section-4.4), producing a Version 4 UUID. The result is a UUID generated only from pseudo-random numbers. diff --git a/website/content/docs/templates/hcl_templates/index.mdx b/website/content/docs/templates/hcl_templates/index.mdx index d460b771b..73869587c 100644 --- a/website/content/docs/templates/hcl_templates/index.mdx +++ b/website/content/docs/templates/hcl_templates/index.mdx @@ -10,7 +10,7 @@ description: |- `@include 'from-1.5/beta-hcl2-note.mdx'` -Packer uses the Hashicorp Configuration Language - HCL - designed to allow +Packer uses the HashiCorp Configuration Language - HCL - designed to allow concise descriptions of the required steps to get to a build file. This page describes the features of HCL2 exhaustively, if you would like to give a quick try to HCL2, you can also read the quicker [HCL2 getting started diff --git a/website/content/docs/templates/hcl_templates/variables.mdx b/website/content/docs/templates/hcl_templates/variables.mdx index 8d45c2dea..9acfab62c 100644 --- a/website/content/docs/templates/hcl_templates/variables.mdx +++ b/website/content/docs/templates/hcl_templates/variables.mdx @@ -155,7 +155,7 @@ argument: ```hcl variable "image_id" { type = string - description = "The id of the machine image (AMI) to use for the server." + description = "The ID of the machine image (AMI) to use for the server." } ``` diff --git a/website/content/docs/templates/legacy_json_templates/engine.mdx b/website/content/docs/templates/legacy_json_templates/engine.mdx index 6b38e4b1e..706b3bd62 100644 --- a/website/content/docs/templates/legacy_json_templates/engine.mdx +++ b/website/content/docs/templates/legacy_json_templates/engine.mdx @@ -74,19 +74,19 @@ Here is a full list of the available functions for reference. Valid variables to request are: - - **ID**: Represents the vm being provisioned. For example, in Amazon it is the instance id; in digitalocean, - it is the droplet id; in Vmware, it is the vm name. + - **ID**: Represents the VM being provisioned. For example, in Amazon it is the instance ID; in DigitalOcean, + it is the Droplet ID; in VMware, it is the VM name. - **Host**, **Port**, **User** and **Password**: The host, port, user, and password that Packer uses to access the machine. Useful for using the shell local provisioner to run Ansible or Inspec against the provisioned instance. - **ConnType**: Type of communicator being used. For example, for SSH communicator this will be "ssh". - - **PackerRunUUID**: Current build's unique id. Can be used to specify build artifacts. + - **PackerRunUUID**: Current build's unique ID. Can be used to specify build artifacts. An example of that, is when multiple builds runs at the same time producing the same artifact. - It's possible to differentiate these artifacts by naming them with the builds' unique ids. + It's possible to differentiate these artifacts by naming them with the builds' unique IDs. - - **PackerHTTPIP**, **PackerHTTPPort**, and **PackerHTTPAddr**: HTTP IP, port, and address of the file server Packer creates to serve items in the "http" dir to the vm. The HTTP address is displayed in the format `IP:PORT`. + - **PackerHTTPIP**, **PackerHTTPPort**, and **PackerHTTPAddr**: HTTP IP, port, and address of the file server Packer creates to serve items in the "http" dir to the VM. The HTTP address is displayed in the format `IP:PORT`. - **SSHPublicKey** and **SSHPrivateKey**: The public and private key that Packer uses to connect to the instance. These are unique to the SSH communicator and are unset when using other communicators. diff --git a/website/content/docs/templates/legacy_json_templates/index.mdx b/website/content/docs/templates/legacy_json_templates/index.mdx index 130562370..bbb44aa11 100644 --- a/website/content/docs/templates/legacy_json_templates/index.mdx +++ b/website/content/docs/templates/legacy_json_templates/index.mdx @@ -79,7 +79,7 @@ key with an underscore. Example: **Important:** Only _root level_ keys can be underscore prefixed. Keys within builders, provisioners, etc. will still result in validation errors. --> **Note:** Packer supports HCL2 from version 1.6.0. The Hashicorp +-> **Note:** Packer supports HCL2 from version 1.6.0. The HashiCorp Configuration Language does support comments anywhere in template files. If comments are important to you, consider upgrading your JSON template to HCL2 using the `packer hcl2_upgrade` command. diff --git a/website/content/guides/1.7-plugin-upgrade.mdx b/website/content/guides/1.7-plugin-upgrade.mdx index d925d10de..6e2e849e4 100644 --- a/website/content/guides/1.7-plugin-upgrade.mdx +++ b/website/content/guides/1.7-plugin-upgrade.mdx @@ -83,7 +83,7 @@ func main() { The implementation is similar, but now we use the "NewSet" function to create the component Server, and call Run() instead of Serve(). -You build it as you would any go binary: +You build it as you would any Go binary: ```go go build -o packer-plugin-bar diff --git a/website/content/guides/automatic-operating-system-installs/autounattend_windows.mdx b/website/content/guides/automatic-operating-system-installs/autounattend_windows.mdx index 061b45d24..445da28ea 100644 --- a/website/content/guides/automatic-operating-system-installs/autounattend_windows.mdx +++ b/website/content/guides/automatic-operating-system-installs/autounattend_windows.mdx @@ -2,7 +2,7 @@ page_title: Unattended Windows Installation description: |- Learn how to use an autounattend file to automatically answer installation - questions and enable Packer to connect to your windows instance. + questions and enable Packer to connect to your Windows instance. --- # Unattended Installation for Windows @@ -57,21 +57,21 @@ If you want to be able to use provisioners, the Answer file must also contain a script that sets up SSH or WinRM so that Packer can connect to the instance. Finally, your Packer build will be much smoother if the Answer File handles or -disables windows updates rather than you trying to run them using a Packer +disables Windows updates rather than you trying to run them using a Packer provisioner. This is because the winrm communicator does not handle the disconnects caused by automatic reboots in Windows updates well, and the disconnections can fail a build. ## Examples -The chef-maintained bento boxes are a great example of a windows build that +The chef-maintained bento boxes are a great example of a Windows build that sets up openssh as part of the unattended installation so that Packer can connect using the SSH communicator. The functioning answer files for every modern Windows version can be found [here](https://github.com/chef/bento/tree/master/packer_templates/windows/answer_files). Stefan Scherer's [packer-windows repo](https://github.com/StefanScherer/packer-windows) -is a great example of windows builds that set up WinRM as part of the unattended -installation so that Packer can connect using the winrm communicator: +is a great example of Windows builds that set up WinRM as part of the unattended +installation so that Packer can connect using the `winrm` communicator: ```json { diff --git a/website/content/guides/automatic-operating-system-installs/preseed_ubuntu.mdx b/website/content/guides/automatic-operating-system-installs/preseed_ubuntu.mdx index 3554ed927..e52e7fa75 100644 --- a/website/content/guides/automatic-operating-system-installs/preseed_ubuntu.mdx +++ b/website/content/guides/automatic-operating-system-installs/preseed_ubuntu.mdx @@ -49,7 +49,7 @@ You then reference the file using a `boot_command` to kick off the installation. In the example below, see how the `preseed/url` command line option is being used in the `/install/vmlinuz command`. The `{{ .HTTPIP }}` and `{{ .HTTPPort }}` options are special Packer template options that will get set -by Packer to point to the http server we create, so that your boot command can +by Packer to point to the HTTP server we create, so that your boot command can access it. For an example of a working boot_command, see the Examples section below. For more information on how boot_command works, see the boot_command section of the docs for whatever builder you are using. diff --git a/website/content/guides/packer-on-cicd/build-virtualbox-image.mdx b/website/content/guides/packer-on-cicd/build-virtualbox-image.mdx index 83cd520b1..0a2744cdd 100644 --- a/website/content/guides/packer-on-cicd/build-virtualbox-image.mdx +++ b/website/content/guides/packer-on-cicd/build-virtualbox-image.mdx @@ -12,7 +12,7 @@ The Packer VirtualBox builder requires access to VirtualBox. Virtualization is not universally supported on cloud instances, so we recommend you run these builds on either a bare metal server, or cloud instances which support nested virtualization, such as Azure or GCP. This is also true for the -[VMWare](/docs/builders/vmware) and the [QEMU](/docs/builders/qemu) +[VMware](/docs/builders/vmware) and the [QEMU](/docs/builders/qemu) Packer builders. We will use Chef's [Bento boxes](https://github.com/chef/bento) to provision an diff --git a/website/content/guides/packer-on-cicd/pipelineing-builds.mdx b/website/content/guides/packer-on-cicd/pipelineing-builds.mdx index 4f35946e9..e0d045df0 100644 --- a/website/content/guides/packer-on-cicd/pipelineing-builds.mdx +++ b/website/content/guides/packer-on-cicd/pipelineing-builds.mdx @@ -287,7 +287,7 @@ sources.pkr.hcl source "docker" "example" { commit = true - // any other configuration you want for your docker containers + // any other configuration you want for your Docker containers } ``` @@ -314,7 +314,7 @@ build { } // Make sure that the output from your build can be used in the next build. - // In this example, we're tagging the docker image so that the step-2 + // In this example, we're tagging the Docker image so that the step-2 // builder can find it without us having to track it down in a manifest. post-processor "docker-tag" { repository = "ubuntu" diff --git a/website/content/partials/datasource/hcp-packer-image/DatasourceOutput.mdx b/website/content/partials/datasource/hcp-packer-image/DatasourceOutput.mdx index 54949cb5c..07e53af6f 100644 --- a/website/content/partials/datasource/hcp-packer-image/DatasourceOutput.mdx +++ b/website/content/partials/datasource/hcp-packer-image/DatasourceOutput.mdx @@ -7,11 +7,11 @@ - `created_at` (string) - The date and time at which the image was created. -- `build_id` (string) - The id of the build that created the image. This is a ULID, which is a +- `build_id` (string) - The ID of the build that created the image. This is a ULID, which is a unique identifier similar to a UUID. It is created by the HCP Packer Registry when an build is first created, and is unique to this build. -- `iteration_id` (string) - The iteration id. This is a ULID, which is a unique identifier similar +- `iteration_id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar to a UUID. It is created by the HCP Packer Registry when an iteration is first created, and is unique to this iteration. diff --git a/website/content/partials/datasource/hcp-packer-iteration/DatasourceOutput.mdx b/website/content/partials/datasource/hcp-packer-iteration/DatasourceOutput.mdx index 10e5ac30e..469a09f05 100644 --- a/website/content/partials/datasource/hcp-packer-iteration/DatasourceOutput.mdx +++ b/website/content/partials/datasource/hcp-packer-iteration/DatasourceOutput.mdx @@ -15,7 +15,7 @@ - `fingerprint` (string) - The fingerprint of the build; this could be a git sha or other unique identifier as set by the Packer build that created this iteration. -- `id` (string) - The iteration id. This is a ULID, which is a unique identifier similar +- `id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar to a UUID. It is created by the HCP Packer Registry when an iteration is first created, and is unique to this iteration. diff --git a/website/content/partials/datasource/packer-image-iteration/DatasourceOutput.mdx b/website/content/partials/datasource/packer-image-iteration/DatasourceOutput.mdx index 20f15d53a..c5748fc25 100644 --- a/website/content/partials/datasource/packer-image-iteration/DatasourceOutput.mdx +++ b/website/content/partials/datasource/packer-image-iteration/DatasourceOutput.mdx @@ -1,6 +1,6 @@ -- `Id` (string) - The iteration id. This is a ULID, which is a unique identifier similar +- `Id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar to a UUID. It is created by the HCP Packer Registry when an iteration is first created, and is unique to this iteration. @@ -13,6 +13,6 @@ - `created_at` (string) - The date the iteration was created. - `builds` ([]ParBuild) - A list of builds that are stored in the iteration. These builds can be - parsed using HCL to find individual image ids for specific providers. + parsed using HCL to find individual image IDs for specific providers. diff --git a/website/content/partials/datasource/packer-image-iteration/ParBuild-not-required.mdx b/website/content/partials/datasource/packer-image-iteration/ParBuild-not-required.mdx index 4ae39c4ac..0c604b219 100644 --- a/website/content/partials/datasource/packer-image-iteration/ParBuild-not-required.mdx +++ b/website/content/partials/datasource/packer-image-iteration/ParBuild-not-required.mdx @@ -7,14 +7,14 @@ - `created_at` (string) - The date and time at which the build was run. -- `id` (string) - The build id. This is a ULID, which is a unique identifier similar +- `id` (string) - The build ID. This is a ULID, which is a unique identifier similar to a UUID. It is created by the HCP Packer Registry when an build is first created, and is unique to this build. - `images` ([]ParImage) - A list of images as stored in the HCP Packer registry. See the ParImage docs for more information. -- `iteration_id` (string) - The iteration id. This is a ULID, which is a unique identifier similar +- `iteration_id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar to a UUID. It is created by the HCP Packer Registry when an iteration is first created, and is unique to this iteration. diff --git a/website/content/partials/datasource/packer-image-iteration/ParImage-not-required.mdx b/website/content/partials/datasource/packer-image-iteration/ParImage-not-required.mdx index fe891d0ed..3c915d8af 100644 --- a/website/content/partials/datasource/packer-image-iteration/ParImage-not-required.mdx +++ b/website/content/partials/datasource/packer-image-iteration/ParImage-not-required.mdx @@ -2,7 +2,7 @@ - `created_at` (string) - The date and time at which the build was last updated. -- `id` (string) - The iteration id. This is a ULID, which is a unique identifier similar +- `id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar to a UUID. It is created by the HCP Packer Registry when an iteration is first created, and is unique to this iteration. diff --git a/website/content/partials/from-1.5/variables/custom-validation.mdx b/website/content/partials/from-1.5/variables/custom-validation.mdx index 042aec146..7bf8146bd 100644 --- a/website/content/partials/from-1.5/variables/custom-validation.mdx +++ b/website/content/partials/from-1.5/variables/custom-validation.mdx @@ -7,11 +7,11 @@ within the corresponding `variable` block: ```hcl variable "image_id" { type = string - description = "The id of the machine image (AMI) to use for the server." + description = "The ID of the machine image (AMI) to use for the server." validation { condition = length(var.image_id) > 4 && substr(var.image_id, 0, 4) == "ami-" - error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"." + error_message = "The image_id value must be a valid AMI ID, starting with \"ami-\"." } } ``` @@ -27,12 +27,12 @@ If the failure of an expression is the basis of the validation decision, use ```hcl variable "image_id" { type = string - description = "The id of the machine image (AMI) to use for the server." + description = "The ID of the machine image (AMI) to use for the server." validation { # regex(...) fails if it cannot find a match condition = can(regex("^ami-", var.image_id)) - error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"." + error_message = "The image_id value must be a valid AMI ID, starting with \"ami-\"." } } ``` diff --git a/website/content/partials/packer-plugin-sdk/multistep/commonsteps/HTTPConfig.mdx b/website/content/partials/packer-plugin-sdk/multistep/commonsteps/HTTPConfig.mdx index f4efe759b..44aec2280 100644 --- a/website/content/partials/packer-plugin-sdk/multistep/commonsteps/HTTPConfig.mdx +++ b/website/content/partials/packer-plugin-sdk/multistep/commonsteps/HTTPConfig.mdx @@ -1,6 +1,6 @@ -Packer will create an http server serving `http_directory` when it is set, a +Packer will create an HTTP server serving `http_directory` when it is set, a random free port will be selected and the architecture of the directory referenced will be available in your builder. diff --git a/website/content/partials/plugins/installing-plugins.mdx b/website/content/partials/plugins/installing-plugins.mdx index 0fc563432..c47767c66 100644 --- a/website/content/partials/plugins/installing-plugins.mdx +++ b/website/content/partials/plugins/installing-plugins.mdx @@ -180,19 +180,19 @@ later, it will take precedence over one found earlier. 1. The directory where `packer` is, or the executable directory. -2. The `$HOME/.packer.d/plugins` directory, if `$HOME` is defined (unix) +2. The `$HOME/.packer.d/plugins` directory, if `$HOME` is defined (Unix) -3. The `%APPDATA%/packer.d/plugins` if `%APPDATA%` is defined (windows) +3. The `%APPDATA%/packer.d/plugins` if `%APPDATA%` is defined (Windows) 4. The `%USERPROFILE%/packer.d/plugins` if `%USERPROFILE%` is defined - (windows) + (Windows) 5. The current working directory. 6. The directory defined in the env var `PACKER_PLUGIN_PATH`. There can be more than one directory defined; for example, `~/custom-dir-1:~/custom-dir-2`. - Separate directories in the PATH string using a colon (`:`) on posix systems and - a semicolon (`;`) on windows systems. The above example path would be able to + Separate directories in the PATH string using a colon (`:`) on POSIX systems and + a semicolon (`;`) on Windows systems. The above example path would be able to find a provisioner named `packer-provisioner-foo` in either `~/custom-dir-1/packer-provisioner-foo` or `~/custom-dir-2/packer-provisioner-foo`. @@ -226,19 +226,19 @@ later, it will take precedence over one found earlier. 1. The directory where `packer` is, or the executable directory. -2. The `$HOME/.packer.d/plugins` directory, if `$HOME` is defined (unix) +2. The `$HOME/.packer.d/plugins` directory, if `$HOME` is defined (Unix) -3. The `%APPDATA%/packer.d/plugins` if `%APPDATA%` is defined (windows) +3. The `%APPDATA%/packer.d/plugins` if `%APPDATA%` is defined (Windows) 4. The `%USERPROFILE%/packer.d/plugins` if `%USERPROFILE%` is defined - (windows) + (Windows) 5. The current working directory. 6. The directory defined in the env var `PACKER_PLUGIN_PATH`. There can be more than one directory defined; for example, `~/custom-dir-1:~/custom-dir-2`. - Separate directories in the PATH string using a colon (`:`) on posix systems and - a semicolon (`;`) on windows systems. The above example path would be able to + Separate directories in the PATH string using a colon (`:`) on POSIX systems and + a semicolon (`;`) on Windows systems. The above example path would be able to find a provisioner named `packer-provisioner-foo` in either `~/custom-dir-1/packer-provisioner-foo` or `~/custom-dir-2/packer-provisioner-foo`. diff --git a/website/content/partials/provisioners/community_provisioners.mdx b/website/content/partials/provisioners/community_provisioners.mdx index d52c6bdf2..e01f48aad 100644 --- a/website/content/partials/provisioners/community_provisioners.mdx +++ b/website/content/partials/provisioners/community_provisioners.mdx @@ -5,5 +5,5 @@ comments. - [Windows Update provisioner](https://github.com/rgl/packer-plugin-windows-update) - - A provisioner for gracefully handling windows updates and the reboots they + A provisioner for gracefully handling Windows updates and the reboots they cause.