Before this change loading of a packerconfig would display `loaded
plugin ...` for any plugin defined in the packerconfig - even if it
didn't exist on disk. This change updates how plugins defined in
packerconfig are loaded to ensure that only successfully loaded plugins
get the lovely message `loaded plugin ...`. For any plugin that fails to
load Packer will log that it failed to load the plugin and continue
processing any other defined plugins.
* Add a test to ensure loadSingleComponent errors when plugin does not
exists
This change introduces a loadExternalComponent which can be used for
loading a single plugin path. The function is a combination of
the discoverSingle and discoverExternalComponents functions.
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
}
```
- Internal plugins are compiled into the same packer binary and invoked through the plugin command
- Search paths allow disk-based plugins to override and should function as normal
- This should allow for a 94% space savings vs statically compiling all the plugins as separate binaries.. approximately 24mb vs 431mb
The null builder is not really a bulider, it just setups a SSH
connection and runs the provisioners. It can be used to debug
provisioners without incurring high wait times. It does not create any
kind of image or artifact.
sylviamoss
Megan Marsh
zhsj
nywilken
Tommy McNeely
Adrien Delorme
Adrien Delorme
Matthew Hooker
Chris Bednarski
Mark Peek
Mitchell Hashimoto
Aneesh Agrawal
Matt Hollingsworth
Jack Pearkes
Rickard von Essen
Florian Noeding
Jan Brauer