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.
* 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>
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
* move maps of plugins back in core
* go mod vendor
* more fixes
* fix imports
* Update core_test.go
* fix build
* more fixes
* more fixes
* up vendors after fixing sdk
* Update post_processor_mock.hcl2spec.go
* Leave implementatino of MapOf in the sdk for plugi tests
Other wise use the interface
* go mod tidy
* add MapOfDatasource type too
Before this change loading of a packerconfig would display `loaded
plugin ...` for any plugin defined in the packerconfig - even if it
didn't exist on disk. This change updates how plugins defined in
packerconfig are loaded to ensure that only successfully loaded plugins
get the lovely message `loaded plugin ...`. For any plugin that fails to
load Packer will log that it failed to load the plugin and continue
processing any other defined plugins.
* Add a test to ensure loadSingleComponent errors when plugin does not
exists
This change introduces a loadExternalComponent which can be used for
loading a single plugin path. The function is a combination of
the discoverSingle and discoverExternalComponents functions.
