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.
`packer init' is meant to be invoked on a template file or a directory.
This was described in the command-line help message as
`[template.pkr.hcl|folder]'.
Because this is encapsulated between square brackets, this could be
taken as an option instead of a positional, mandatory argument.
This commit changes the wording to adopt a similar convention as `packer
build', so the two are consistent in how they are invoked, and to avoid
mistaking this argument as optional.
When setting a project id via the HCP_PROJECT_ID env the client will try to validate the project
by checking that it has an associated registry. If the project is invalid or not a valid UUID an error
will be displayed to the user
* Add comment to clarify usage of SDK loaded env. variables
HCP supports two types of service principals: Organization-level and project-level.
When a user tries to publish to an active HCP Packer registry using a plsp the client
fails when configuring the client due to a API permission error; namely plsp do not have
the permissions to query an org for a list of projects. Setting the HCP_PROJECT_ID does
not resolve the issue because the call to ListProjects is still executed.
This changes updates the client configuration params to obtain both the HCP Organization and
Project IDs that will be used for connecting to the HCP Packer registry. With this change
if a user provides a project Id via the HCP_PROJECT_ID environment variable no call to ListProjects will
be made. Instead the value will be take as is and used to create the connection. A user connecting with
a project level service principals must provide a valid HCP_PROJECT_ID in order to connect.
The action currently fails when trying to remove the stale or waiting-reply labels from issues
that do not actually contain the labels in question. This update adds a guard clause to only run the
action on issues containing at least one of the labels.
The GHA action used for adding comments or labels to issues untrusted by TSCCR
have been replaced with an approved set of actions. The updated workflows use
actions/github-script for adding comments or labels to an issue.
Related to: https://github.com/hashicorp/security-tsccr/pull/608
The Makefile would check for executable files inside the Packer
repository, and produce errors if one was detected and not explicitely
whitelisted through the `EXECUTABLE_FILES' Makefile variable.
This check was introduced a while back to avoid having executable files
in the repository, but this check can be problematic sometimes because
of how it is written, namely when building the website, which causes a
lot of JS executable files to appear in the hierarchy, and in turn this
causes the shell expansion to fail because of the large number of
arguments.
Since this test is not necessary for Packer to build or test, and since
it implies that we have to maintain the whitelist regex, we remove it
from the Makefile.
Since bundled plugins will be removed in an upcoming version of Packer,
this commit adds a new warning message whenever a template uses one such
plugin.
This warning has been implemented on build, validate, console and the
inspect subcommands.
In addition to warning about the upcoming change and potential issue
this will cause, this warning message proposes solutions to the user so
they know what they'll have to do in order not to rely on those bundled
plugins later.
In HCL2, if a template contains a `required_plugins' block, but the
required plugins are not installed, we print a warning.
Prior to this commit, this was reported as an error once per missing
plugin, which was redundant.
This commit changes that by gathering all the missing plugins once, and
printing them as a bullet list, so the message isn't redundant anymore.
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
* Update external plugin documentation source
The Parallels plugin for Packer is now maintained by the Parallels team, under
their respective GitHub org. This changes updates the source address for
the external plugin that should be used for pulling new plugin
documentation.
* Removed packer-plugin-parallels for list of vendored plugins
Packer will try to discover installed plugins in all of the directories
defined by packer.KnowPluginFolders. In a previous release logic was
added to scan nested directories in order to load plugins installed by
`packer plugins install`. This change resulted in a nested directory
scan for each folder within the KnownPluginFolders slice.
This change reduces the nested directory scan to only the directories
where plugins would have been installed using `packer plugins install`
Remove the check-legacy-links-format.yml workflow. These checks are now included as part of our
content conformance checks that run on PRs with documentation content changes.
* 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.
On HCP, multiproject support was GA'd recently, but Packer does not
support the feature yet.
To avoid clients being surprised if they encounter an error with this
feature enabled, we add an advisory related to this feature not being
supported for now, but planned for later.
hashicorp-tsccr[bot]
Lucas Bajolet
Wilken Rivera
hashicorp-copywrite[bot]
Wilken Rivera
Kévin Dunglas
dependabot[bot]
hashicorp-tsccr[bot]andhashicorp-tsccr[bot]
GaryNgandLucas Bajolet
akkuman
Dylan Staley