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.
cty's new "refinements" concept allows us to reduce the range of unknown
values from our functions. This initial changeset focuses only on
declaring which functions are guaranteed to return a non-null result,
which is a helpful baseline refinement because it allows "== null" and
"!= null" tests to produce known results even when the given value is
otherwise unknown.
This commit also includes some updates to test results that are now
refined based on cty's own built-in refinement behaviors, just as a
result of us having updated cty in the previous commit.
If a variable is defined and overriden in the packer command-line, but
there's a problem during the evaluation of this override (type error
typically), we show an error message which details the problem.
This message points to a temporary in-memory HCL2 "file" that we use for
parsing and evaluating the expression for the variable, but since it's
virtual, there's no point in using this as the source for the error, as
it will always yield "line 0" and no contents.
So, in order to limit confusion here, we remove the source for this
error message.
This change initializes a MapOfBuilders with the test builder to fix a
panic with checking if the initialized BuilderSet has an entry for the
test builder.
When a user invokes packer for a build or validation, the template being
processed needs components to be present for Packer to process it
without error.
If the component cannot be found from the plugins loaded (or from the
components bundled with Packer), Packer errors, and the command fails.
This is expected, but the error message does not suggest anything to fix
the error, potantially leaving users confused at the problem.
This commit suggests either a replacement (in case of a typo), or points
to the web documentation for Packer, specifically the integrations, so
they can look for the plugin they're missing, and install it, so
subsequent invocations of Packer work.
If a user attempts to remove a plugin through the `packer plugins
remove' subcommand, and the specified plugin is not installed, the
command succeeds, but does nothing, and exits silently.
This is not clear what is happening, and arguably, calling a command
that does nothing, not even explain what went wrong, is not intuitive.
Because of that, this commit changes how the command behaves in this
case, stating what went wrong, and exiting with a non-zero status.
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.
When a user invokes `packer plugins remove', the plugin binary gets
removed, but not the corresponding SHA256SUM file.
This patch changes this so that when a binary is removed, so is its
SHA256SUM file.
When invoking `packer plugins install' to install a plugin, or `packer
init', the checksum file would be installed with 0555 permissions.
This led in turn to further attempts at installing the plugin will
succeed, but the checksum file would not be updated, as it was marked
non-writable by the owner of the file, leading potentially to a
situation where the plugin binary and the checksum would be out-of-sync,
but could not be updated unless the user changed it.
To avoid such a problem, we write the checksum file with 0644
permissions, so the owner can read/write, while the other users can only
read it.
This change updates hcl2_upgrade to not flag known plugin components, those used for generating the required plugins
block, when upgrading a legacy JSON template to HCL2. Any unknown plugins will be installed after running packer init
on the generated template so we don't error. We may want to suggest running packer init to install any missing plugins.
* Move knownPluginPrefixes into the hcl2_upgrade command
With the removal of vendored_plugins we are no longer interested in tacking bundled plugins usage.
For plugins such as file, null, or anything bultin into Packer we don't track because there is no
way to install them outside of Packer, for now.
The enumeration for FlagSetFlags, which presumably was added when the
Meta structure was introduced, aims to pre-populate the flagset for a
subcommand with a series of arguments.
However, despite it being documented, it is actually not used, and
therefore can safely be removed from the codebase.
The previous implementation of the GetVarsByType function worked only on
top-level attributes, ignoring the nested blocks in the structure.
This implies that if a datasource depends on another through an
expression within a nested block, we may not execute it first, and then
executing this datasource before its dependent is possible, resulting in
an error in the end.
This commit is an attempt at making this more reliable for HCL configs,
but only works on configs lifted from HCL files for now. We need to make
this more reliable for later iterations.
