* Check if IP address is IPv4 before returning it
Returns the first IPv4 address instead of the first IP address which is an IPv6 for Windows VMs
* Updated the go module
* Reversed the order of checks
First check if it's a loopback and check for ipv4 afterwards
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>
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
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
