In a couple places in the codebase we didn't check the errors from
functions we execute.
In some cases this is harmless (or at least ignorable), but others may
need to log what went wrong, so for all the reported occurrences we
either ignore explicitly or handle the error with a log.
The global `PACKER_CONFIG` config file was already deprecated from
Packer core, but now with 1.11.0 since we remove support for
mono-component plugins, we are also removing the capability for that
config file to declare them.
Instead of silently not using those, Packer will now error with a
message pointing to the web docs on how to manage their plugins with the
updated workflows for Packer 1.11 and above.
The plugin and plugins command had a name that was close, and while
plugin is not supposed to be directly called by Packer users, this could
happen by accident while trying to execute packer plugins subcommands,
and when it does, the error messages are far from explicit, so unless
they understand what Packer is doing here, they'll likely be lost.
To reduce the risk of confusion, we rename the command to run packer
embedded components as execute.
When Packer is loaded, we used to perform plugin discovery.
This was done for every call to Packer, including when it is executed as
a plugin, arguably against what the comments document.
Doing this as early in the loading process makes it harder to change
this behaviour, as we'd need to introduce flags aside from the rest, and
handle them manually, which is not optimal.
Therefore, we change this: now when Packer starts executing, it will not
attempt to discover installed plugins anymore, and instead will only try
to load them when a configuration has been parsed, and is being used to
perform actions (typically build/validate).
Since we're removing the alternative plugin installation directories in
favour of only supporting installing them in the PACKER_PLUGIN_PATH
directory, we only return one directory when getting the known plugin
directories.
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
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.
* Updating the license from MPL to Business Source License
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at https://hashi.co/license-faq, and details of the license at www.hashicorp.com/bsl.
* Update copyright file headers to BUSL-1.1
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
The auto installation of external plugins via packer init only work for
HCL templates. Since we have not officially removed all plugins (slated
for 1.8.0) I am reverting this test change. Once 1.7.9 is released we
can begin removing plugins and optimizing the redirect experience for
JSON-only users.
errors
While working on this change it was found that prefixing an error
message with the ErrorPrefix string would trigger a copyOutput function
that would copy any outputted string to Stderr, until a new ErrorPrefix
or Outprefix string is encountered in the output. During background runs of
Packer an error message with the ErrorPrefix was being outputted which
was causing all output, including Stdout, to be written to Stderr.
This change updates the logic to only override the Stdout logging
for non-recoverable errors. The idea being that any non-recoverable
error should bypass panicwrap so that user know an error occurred.
All other errors should follow the same behavior that we had prior to
Packer v1.7.1.
Closes#10855
* used components that don't have a required_plugin block will make Packer 'implicitly' require those. These components are manually selected and commented for now.
* add tests
* docs
This adds the new `required_plugins` block to be nested under the packer block.
Example:
```hcl
packer {
required_plugins {
aws = {
version = ">= 2.7.0"
source = "azr/aws"
}
azure = ">= 2.7.0"
}
}
```
For example on darwin_amd64 Packer will install those under :
* "${PACKER_HOME_DIR}/plugin/github.com/azr/amazon/packer-plugin-amazon_2.7.0_x5.0_darwin_amd64"
* "${PACKER_HOME_DIR}/plugin/github.com/hashicorp/azure/packer-plugin-azure_2.7.0_x5.0_darwin_amd64_x5"
+ docs
+ tests
Modify makefile to call generate code properly, setting project root.
'make generate' now avoids deleting website code generated in the packer plugin sdk.
For now it will be maintainers' responsibility to regenerate this docs code from the
packer plugin sdk every release, and commit it to these folders manually.
remove boot command generator code
As of mitchellh/panicwrap#25, a call to panicwrap.Wrapped() unsets the
cookie in the env, that makes packer plugin child process inherit an env
without the panicwrap cookie and panicwrap itself.
This trips up CleanupClients() in Packer's plugin client: instead of the
real plugin server it now kills its panicwrap parent -- which doesn't
forward SIGKILL to its child because it's not a signal that can be
caught -- and ends up indefinitely waiting in client.Kill() for an EOF
that will never come.
This workaround is to not even try to panicwrap in a plugin server.
Hari
hashicorp-copywrite[bot]
Sebastien Dionne
Lucas Bajolet
Lucas Bajolet
guoguangwu
Wilken Rivera
Wilken Rivera
Adrien Delorme
Megan Marsh
Sylvia Moss
Dmitry Borodaenko