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.
* Update to v3.21.1 to allow builds to work for darwin arm64
Co-authored-by: Megan Marsh <megan@hashicorp.com>
Co-authored-by: Adrien Delorme <adrien.delorme@icloud.com>
Currently, the oracle-oci builder is broken, because it is unable
to read the key file provide by Oracle cloud. Updating to the
latest oci-go-sdk fixes the issue.
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
tooling. Tested on OSX, `Windows, and Linux. Documented command line dependencies.
Added acceptance tests (behind testacc flag, since there are dependencies).
This option is only implemented for the vmware and hyperv iso builders. It will be
implemented for others in later PRs in order to make review easier.
hcl2_upgrade transforms a JSON build-file in a HCL2 build-file.
This starts a validated Packer core and from that core we generate an HCL 'block' per plugin/configuration. So for a builder, a provisioner, a post-processor or a variable. The contents of each block is just transformed as is and basically all fields are HCL2-ified.
A generated field can be valid in JSON but invalid on HCL2; for example JSON templating (in mapstructure) allows to set arrays of strings - like `x = ["a", "b"]` - with single strings - like `x="a"` -, HCL does not allow this.
Since JSON does not make the distinction between variables and locals, everything will be a variable. So variables that use other variables will not work.
hcl2_upgrade tries to transform go templating interpolation calls to HCL2 calls when possible, leaving the go templating calls like they are in case it cannot.
Work:
* transpiler
* tests
* update hcl v2 library so that output looks great.
* update docs
