This change adds a new set of maps for builders, provisioners, and
post-processors that store reference to components that were once part
of Packer and are now vendored. This file acts as a single place for
defining this vendored components, which are then merged into the main
components maps to be used in Packer.
Quick test to ensure the exoscale-import post-processor is still loaded
```
// Validate that exoscale-import is in the know post-procoessors list
~> packer.test build docker_centos_shell_provisioner.pkr.hcl
Error: Unknown post-processor type "badlynamed-import"
on docker_centos_shell_provisioner.pkr.hcl line 18:
(source code not available)
known post-processors: [ucloud-import digitalocean-import docker-push
googlecompute-export manifest vsphere-template docker-tag vsphere checksum
docker-import exoscale-import yandex-export compress googlecompute-import
yandex-import vagrant-cloud alicloud-import amazon-import artifice shell-local
docker-save vagrant]
// Validate that exoscale-import get loaded
~> packer.test build docker_centos_shell_provisioner.pkr.hcl
Error: Failed preparing post-processor-block "exoscale-import" ""
on docker_centos_shell_provisioner.pkr.hcl line 18:
(source code not available)
4 error(s) occurred:
* api_key must be set
* api_secret must be set
* image_bucket must be set
* template_zone must be set
==> Wait completed after 2 microseconds
==> Builds finished but no artifacts were created.
```
This change will vendor the new version of the exoscale-import
post-processor component, but remove all of its code from Packer. After
the v1.8.0 release this change should be removed entirely.
This vendor process is being used as a workaround for decoupling the
exoscale-import component without causing a breaking change in Packer.
Users of Exoscale are encouraged to leverage `packer init` for
installing the latest version of packer-plugin-exoscale.
This change removes the generation of command/plugin.go so that plugin
registration can be managed manually. As we begin to break out plugins
we will need to begin modifying this file, possibly with stubs to allow
for the removal of plugins without breaking Packer's backwards
compatibility with 1.7.0. After 1.8.0 is released we should be able to
revet these changes so that we can continue to generate the plugin
file for those plugins core to Packer.