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.
Datasources use their attribute's expressions to determine whether or
not they depend on another datasource, in order to get the list of
dependencies and execute them before executing a datasource.
This code may be useful later on for figuring out the dependencies for
any block, so we move this code to the utils.go file, and use this for
datasources.
When a datasource fails to be evaluated because a cycle has been
detected, we point out one of the links of the chain now so that users
have a better idea of what to look at.
Since datasources are recursively evaluated depending on their
dependencies, we don't need to pre-execute those that depend on nothing,
as the recursive traversal of the datasources will take care of that for
us.
Not sure why this was defined and returned, but the value was set, but
never used, as such this is not useful to keep in the code, so let's
simplify this now.
When users call `packer init' on a template that does not specify a
`required_plugin' block, the command succeeds but does nothing, which is
not helpful for users that may expect their plugins to install.
To remedy that problem, we now output a message like what `packer
plugins required' does on templates without such a block, so that users
have an idea of what to change in order to get the command to work.
The active plugins that resided in a HashiCorp repository have been migrated to
the integrations framework and no longer need to be listed within the plugins-manifest file.
Local variables can't have a validation block in their definition, so
this step in not useful and should be removed.
Besides, since the validation was done on the local variables before
evaluation, it did nothing at all, as the PackerConfig.LocalVariables
collection gets populated during evaluation, so this is essentially a
no-op, and can be safely removed.
The flags -v and --version are handled by the CLI runner, which
outputs the raw version string. This change shortcuts the handling of
the flags to force Packer to run the version subcommand.
Closes: #12565
Invoking Packer with the CHECKPOINT_DISABLE env. variable the telemetry reporter is left uninitialized in order to disable telemetry reporting.
Any method calls on the nil reporter is expected to check if the reporter is active or in NOOP mode. This change fixes a crash when calling SetBundledUsage()
on a nil CheckpointTelemetry type that occurs when using a bundled plugin with CHECKPOINT_DISABLE=1.
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.
