* Document use of TMPDIR required for remote plugin installation
* Update website/content/docs/configure.mdx
Co-authored-by: Lucas Bajolet <[email protected]>
---------
Co-authored-by: Lucas Bajolet <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
* 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 <[email protected]>
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.
The current documentation about installing plugins does not explain
(outside of the `packer init' section) how Packer discovers plugins,
what the expected file system hierarchy should be, and the quirk of how
this takes precedence over the rest when `required_plugins' is
specified.
This commit addresses that by reorganising the page to highlight general
usage questions on sources and plugins, and simplifies the tabs below to
only highlight installation methods.
In order to better document packer plugins installation methods, and
since `packer plugins install' is not really manual, we split in two
sections the "manual installation".
As this is legacy, we stop documenting how to install single-component
plugins, and reword the documentation for manually installing a plugin.
The HCL2 docs on built-in functions contains a link to a non-existent
section of the expressions page, so we update it to link to the general
page, and to the string interpolation section, since it is a common use
case.
Since this feature is no longer something we plan to activate later, as
it contradicts with our efforts to remove bundled plugins, and
encouraging users to move to either manually installing plugins, or
managing them through `packer init', we clean-up the code for this
feature.
Wenfeng Pan
Lucas Bajolet
Wilken RiveraandLucas Bajolet
Ryan Johnson
Ryan Johnson
Steven Kalt
Estelle PoulinandWilken Rivera
Jiaqi Liu
pavedroad
Jenna Goldstrich
Devashish
ygXXII
cjlapao