This follows #8232 which added the code to generate the code required to parse
HCL files for each packer component.
All old config files of packer will keep on working the same. Packer takes one
argument. When a directory is passed, all files in the folder with a name
ending with “.pkr.hcl” or “.pkr.json” will be parsed using the HCL2 format.
When a file ending with “.pkr.hcl” or “.pkr.json” is passed it will be parsed
using the HCL2 format. For every other case; the old packer style will be used.
## 1. the hcl2template pkg can create a packer.Build from a set of HCL (v2) files
I had to make the packer.coreBuild (which is our one and only packer.Build ) a public struct with public fields
## 2. Components interfaces get a new ConfigSpec Method to read a file from an HCL file.
This is a breaking change for packer plugins.
a packer component can be a: builder/provisioner/post-processor
each component interface now gets a `ConfigSpec() hcldec.ObjectSpec`
which allows packer to tell what is the layout of the hcl2 config meant
to configure that specific component.
This ObjectSpec is sent through the wire (RPC) and a cty.Value is now
sent through the already existing configuration entrypoints:
Provisioner.Prepare(raws ...interface{}) error
Builder.Prepare(raws ...interface{}) ([]string, error)
PostProcessor.Configure(raws ...interface{}) error
close#1768
Example hcl files:
```hcl
// file amazon-ebs-kms-key/run.pkr.hcl
build {
sources = [
"source.amazon-ebs.first",
]
provisioner "shell" {
inline = [
"sleep 5"
]
}
post-processor "shell-local" {
inline = [
"sleep 5"
]
}
}
// amazon-ebs-kms-key/source.pkr.hcl
source "amazon-ebs" "first" {
ami_name = "hcl2-test"
region = "us-east-1"
instance_type = "t2.micro"
kms_key_id = "c729958f-c6ba-44cd-ab39-35ab68ce0a6c"
encrypt_boot = true
source_ami_filter {
filters {
virtualization-type = "hvm"
name = "amzn-ami-hvm-????.??.?.????????-x86_64-gp2"
root-device-type = "ebs"
}
most_recent = true
owners = ["amazon"]
}
launch_block_device_mappings {
device_name = "/dev/xvda"
volume_size = 20
volume_type = "gp2"
delete_on_termination = "true"
}
launch_block_device_mappings {
device_name = "/dev/xvdf"
volume_size = 500
volume_type = "gp2"
delete_on_termination = true
encrypted = true
}
ami_regions = ["eu-central-1"]
run_tags {
Name = "packer-solr-something"
stack-name = "DevOps Tools"
}
communicator = "ssh"
ssh_pty = true
ssh_username = "ec2-user"
associate_public_ip_address = true
}
```
* I had to contextualise Communicator.Start and RemoteCmd.StartWithUi
NOTE: Communicator.Start starts a RemoteCmd but RemoteCmd.StartWithUi will run the cmd and wait for a return, so I renamed StartWithUi to RunWithUi so that the intent is clearer.
Ideally in the future RunWithUi will be named back to StartWithUi and the exit status or wait funcs of the command will allow to wait for a return. If you do so please read carrefully https://golang.org/pkg/os/exec/#Cmd.Stdout to avoid a deadlock
* cmd.ExitStatus to cmd.ExitStatus() is now blocking to avoid race conditions
* also had to simplify StartWithUi
move comments outside of datastructure
remove duplicated section
fix line-endings
Golang doesn't use C-style comments
run gofmt for alignment and whitespace management
remove danling "options" and fix class reference
syncronize tests to new command structure
Previous implementation hardcoded "mkdir -p" which is fine for Unix, but
fails on Windows. This change draws on the example in the chef-solo
provisioner on how to detect the OS in use and use an appropriate mkdir
command.
In addition to updating the mkdir command, the actual executeCommand
needs to be OS specific, since Windows doesn't have sudo and Unix
doesn't require 'SET' when trying to change the value of a variable.
Modify the actual Windows command used to run Puppet.
Since the Facter vars on Windows are set with 'SET <varname>=<value>', a
'&&' is needed between the SET commands and the actual Puppet
invocation.
* Add puppet-masterless test for packer_build_name default fact
* Add puppet-masterless test for packer_builder_type default fact
* Add puppet-server test for puppet bin directory
When puppet is executed in masterless mode it didn't remove
staging directory, this can be a problem because it leaves all
the modules and manifests in the built image.
This is specially problematic when building docker images as they
can be left in the layers unless an specific cleanup is done after
running puppet.
This change adds a flag `clean_staging_directory` to puppet
masterless provisioner so it takes care of this cleanup.
Adrien Delorme
Adrien Delorme
Megan Marsh
Matt Dainty
Matthew Patton
DanHam
Matthew Patton
Matthew Hooker
c22
Sam Kerr
Luke Farnell
Sean Malloy
Rickard von Essen
mexisme
Keyan Pishdadian
Chris Bednarski
Trevor Suarez
Jaime Soriano Pastor