This is the first step in attempting to read a Packer configuration file
via the packer init command. At the present moment it will try to read
one or more configuration templates from a given directory or path. Once
parsed it will error if parsing fails or exist successfully if it is
able to parse the file.
Looking at how the code is structured there will need to be changes made
to the following places:
- When no configuration file is found Packer will display an error. That
error should be bubbled up a bit so that the caller command can
determine if it should be displayed or not. For packer init no
configuration is not an error. Maybe it should be?
- After a configuration has been parsed there needs to be a single way
to determine a list of plugins associated with the configuration. HCL
and JSON configs have fields for this data but some is exported and some
is unexported. Adapting the packerHandler interface may be an option
here. More investigation needed.
Before change
```
Usage: packer [--version] [--help] <command> [<args>]
Available commands are:
build build image(s) from template
console creates a console for testing variable interpolation
fix fixes templates from old versions of packer
hcl2_upgrade build image(s) from template
inspect see components of a template
validate check that a template is valid
version Prints the Packer version
```
After change
```
Usage: packer [--version] [--help] <command> [<args>]
Available commands are:
build build image(s) from template
console creates a console for testing variable interpolation
fix fixes templates from old versions of packer
hcl2_upgrade transform a JSON template into a HCL2 configuration
inspect see components of a template
validate check that a template is valid
version Prints the Packer version
```
when it encounters map[string]interface{} or []interface{} types, hcl2_upgrade now takes the 'most complex' entry from those in order to tell wether this is going to be a body `body {}` or an attribute `attribute = {}`. Before that the hcl2_upgrade command could be a bit random there.
A way better ( but may be somewhat hard ) way to do this would be to use the actual plugins structs in order to generate the HCL2.
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
added `post-processors` block to run chained post-processors after a build.
Before this, defining multiple `post-processor` blocks after
provisioning steps would run them sequentially, now doing this makes them start
from the build's artifact. To queue post-processors you now have to define them
in a `post-processors` block.
This is a breaking change.
The initialization of packer core in JSON also validates that `null` variables were set, except in the case of `packer validate --syntax-only` , but after the refactor to allow to have all commands work with HCL2 and JSON this subtlety was lost.
This refactors the initialisation of the core in order to allow to have `packer validate --syntax-only` not error in case a variable is not set. Since these calls are refactored this works for HCL2 too.
fix#9478
* Update validate command to use FixConfig for checking against known
fixers
* Update validation command flag docs
* Add ConfigFixer method to PackerHandler Interface
* Implement ConfigFixer interface in PackerConfig
* Remove all stdout messaging (i.e calls to c.Ui.Say) in the validate
command. The command will only display hcl.Diagnotic messaging when there is an error or warning.
HCL2 Configs
```
⇶ packer validate docker_centos_shell_provisioner.pkr.hcl
```
JSON Configs
```
⇶ packer validate vmware-iso_ubuntu_minimal/vmware-iso_ubuntu_minimal.json
Error: Failed to prepare build: "vmware-iso"
1 error occurred:
* Deprecated configuration key: 'iso_checksum_type'. Please call `packer fix`
against your template to update your template to be compatable with the current
version of Packer. Visit https://www.packer.io/docs/commands/fix/ for more
detail.
Warning: Fixable configuration found.
You may need to run `packer fix` to get your build to run correctly.
See debug log for more information.
map[string]interface{}{
"builders": []interface{}{
map[string]interface{}{
... // 3 identical entries
"guest_os_type": string("ubuntu-64"),
"http_directory": string("http"),
- "iso_checksum":
string("946a6077af6f5f95a51f82fdc44051c7aa19f9cfc5f737954845a6050543d7c2"),
+ "iso_checksum":
string("sha256:946a6077af6f5f95a51f82fdc44051c7aa19f9cfc5f737954845a6050543d7c2"),
- "iso_checksum_type": string("sha256"),
"iso_url":
string("http://old-releases.ubuntu.com/releases/14.04.1/ubuntu-14.04.1-server-amd64.iso"),
"shutdown_command": string("echo 'vagrant' | sudo -S shutdown -P now"),
... // 4 identical entries
},
},
}
```
* refactor so that json and hcl2 templates are both prepared in the same place in the build call, to make code easier to reason about. Remove overly verbose error output which isn't useful in vast majority of cases
* fix tests
* check err msg
* hcl2template.PackerConfig.GetBuilds: raise a diagnostic in case the packer core build perpare call errors
Co-authored-by: Adrien Delorme <adrien.delorme@icloud.com>
