* doc fix for unattended debian/ubuntu installer linkrot
the links for chef-maintained preseeds/autoinstallers for debian/ubuntu both rotted. i'm just getting started with packer, so i hope this edit is accurate.
* Remove webarchive links for legacy JSON
When possible point users to HCL2 templates for getting started examples.
* As per the style guide aim for inclusive language
---------
Co-authored-by: Wilken Rivera <dev@wilkenrivera.com>
* Document use of TMPDIR required for remote plugin installation
* Update website/content/docs/configure.mdx
Co-authored-by: Lucas Bajolet <105649352+lbajolet-hashicorp@users.noreply.github.com>
---------
Co-authored-by: Lucas Bajolet <105649352+lbajolet-hashicorp@users.noreply.github.com>
Updates the provisioners documentation for a better reader experience by including a list of the built-in provisioners and a link to the community supported provisioners that are all withing the navigation tree.
Ref: #12898
Signed-off-by: Ryan Johnson <ryan@tenthirtyam.org>
Adds an example of a string template being used.
The example demonstrates how a template sequence can be used to embed the value of a variable into a string that can be used as script content.
Ref: #12651
Signed-off-by: Ryan Johnson <ryan.johnson@broadcom.com>
Adds documentation for `ssh_keypair_name`, `ssh_agent_auth`, `temporary_key_pair_name`, and `ssh_private_key_file`.
The note is updated noting that not all builders support these options.
Ref: #10722
Signed-off-by: Ryan Johnson <ryan@tenthirtyam.org>
* docs: add plugin loading spec documentation
The logic for discovering and loading plugins is not well documented on
the current documentation.
This causes issues for users that have to troubleshoot why a particular
plugin cannot be found or installed, so this commit adds a specification
document, detailing what are Packer's expectations when it comes to
discovering plugins.
* Apply suggestions from code review
* Update plugin loading specification navbar
---------
Co-authored-by: Wilken Rivera <dev@wilkenrivera.com>
Compared to Terraform, Packer was lacking a capability to encode/decode
strings to/from base64-encoded text encoded with another encoding.
This could be problematic in some cases, mainly when working with
Windows, as most of the OS uses UTF-16LE as its standard encoding for
many operations.
Therefore, we take a page from Terraform here, and add those functions
to what Packer supports in an HCL2 context.
When updating the docs in prevision for Packer 1.11.0, we changed the
templates that show how plugins are installed/discovered with commands
like packer init.
While doing so, a template had its component renamed to coolcloud, but
the following prose did not change, making the text inconsistent.
Since there are other mentions of myawesomecloud in the codebase, we
choose to settle on this one for that example too.
Since the plugins install subcommand can install both remotely and
locally sourced plugins, we update the documentation for it on the
web-docs to reflect this change.
Since we're changing how packer manages plugin installation with 1.11.0,
we reflect those changes to the website documentation.
Now, we only describe the packer init and packer plugins install
commands, along with the `--path` flag for installing from a local
source.
The explanations of how packer discovers and picks which version of a
plugin to load are also included, along with the list of constraints
that determine whether a plugin can be considered or not to be loadable.
With the changes coming up for 1.11.0, we update the Packer
configuration docs so they describe the one way to load plugins, and the
two environment variables which can be set to change this behaviour.
In the full example for both the hcp-packer-artifact and
hcp-packer-version the hcp-packer-version reference in the example
template was mistakenly spelled as "hcp_packer_version", which won't
work, so we fix that typo here.
This change removes all external plugin docs using the old remote docs framework
from the Packer core documentation in favor of the Packer integration framework.
Remove plugins will be enabled on the integration portal and contacted to merge their PRs to finalize the integration migration.
Since the UpCloud plugin has moved to the integrations model, we don't
want to continue looking for a docs.zip in their repo, as it doesn't
exist anymore with this migration.
