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.
Since we added support for PLSPs recently, and it will be released as part of 1.9.3, we add some documentation regarding the environment variables we added, and a note regarding their relation to PLSP support.
The `packer init' command's wording was not clear, so it was changed in
a preceding commit, and this commit aims to add more details on how the
command is meant to be used, along with a simple example.
When the config file header was reworked, an erroneous link was
included and placed so close to the header that it was rendered verbatim
in the final documentation page.
By adding an extra empty line in between the anchor link and the header,
this renders correctly.
Packer checks a number of directories for plugins upon initialization,
with the introduction of multi-component plugins and underlying changes
to the Packer SDK the ordering changed slightly. These changes update
the related documentation to reflect the new ordering, and adds a plugin
loading ordering section to the docs to help users discover how plugin
loading works.
Include in this change are updates to the PACKER_CONFIG_DIR environment
variables to reflect the XDG base directory specification used as the
default Packer configuration directory layout.
* Update website/content/docs/configure.mdx
* docs: add a paragraph on fingerprint generation
Since version 1.9.0+ changed the way Packer generates fingerprints for
HCP Packer, we add a small paragraph to explain how it used to be
generated before, and how it changed in this version.
* Apply suggestions from code review
---------
Co-authored-by: Wilken Rivera <[email protected]>
With HCP supporting multi-projects now, Packer needs to take it into
account when picking a project from an organisation.
This commit adds two cases:
1. multiple projects are defined, none is supplied through
HCP_PROJECT_ID: in this case we will default to the oldest project
defined for the organisation.
2. we supply HCP_PROJECT_ID: in this case, we pick the project with the
corresponding ID, and use it for publishing metadata.
Wilken Rivera
Estelle PoulinandWilken Rivera
Lucas Bajolet
Jiaqi Liu
pavedroad
Jenna Goldstrich
Wilken Rivera
Devashish
ygXXII
cjlapao
Kévin Dunglas
GaryNgandLucas Bajolet
akkuman
Dylan Staley