Initial work

add hcl examples to shell provisioner docs

CHANGELOG.md

@@ -1,3 +1,5 @@
+## 1.6.2 (Upcoming)
+
 ## 1.6.1 (July 30, 2020)
 
 ### BACKWARDS INCOMPATABILITIES:

builder/qemu/builder.go

@@ -86,17 +86,17 @@ type Config struct {
 	// accelerator you specified. When no accelerator is specified, Packer will try
 	// to use `kvm` if it is available but will default to `tcg` otherwise.
 	//
-	// -> The `hax` accelerator has issues attaching CDROM ISOs. This is an
+	// ~> The `hax` accelerator has issues attaching CDROM ISOs. This is an
 	// upstream issue which can be tracked
 	// [here](https://github.com/intel/haxm/issues/20).
 	//
-	// -> The `hvf` and `whpx` accelerator are new and experimental as of
+	// ~> The `hvf` and `whpx` accelerator are new and experimental as of
 	// [QEMU 2.12.0](https://wiki.qemu.org/ChangeLog/2.12#Host_support).
 	// You may encounter issues unrelated to Packer when using these.  You may need to
 	// add [ "-global", "virtio-pci.disable-modern=on" ] to `qemuargs` depending on the
 	// guest operating system.
 	//
-	// -> For `whpx`, note that [Stefan Weil's QEMU for Windows distribution](https://qemu.weilnetz.de/w64/)
+	// ~> For `whpx`, note that [Stefan Weil's QEMU for Windows distribution](https://qemu.weilnetz.de/w64/)
 	// does not include WHPX support and users may need to compile or source a
 	// build of QEMU for Windows themselves with WHPX support.
 	Accelerator string `mapstructure:"accelerator" required:"false"`
@@ -208,7 +208,7 @@ type Config struct {
 	// as an empty string is ignored. All values after the switch are
 	// concatenated with no separator.
 	//
-	// ~> **Warning:** The qemu command line allows extreme flexibility, so
+	// ~> **Warning:** The qemu command line allows extreme flexibility, so
 	// beware of conflicting arguments causing failures of your run. For
 	// instance, using --no-acpi could break the ability to send power signal
 	// type commands (e.g., shutdown -P now) to the virtual machine, thus
@@ -218,8 +218,8 @@ type Config struct {
 	//
 	// The following shows a sample usage:
 	//
+	// In JSON:
 	// ```json
-	//{
 	//   "qemuargs": [
 	//     [ "-m", "1024M" ],
 	//     [ "--no-acpi", "" ],
@@ -231,7 +231,21 @@ type Config struct {
 	//     ],
 	//     [ "-device", "virtio-net,netdev=mynet0" ]
 	//   ]
-	// }
+	// ```
+	//
+	// In HCL2:
+	// ```hcl
+	//   qemuargs = [
+	//     [ "-m", "1024M" ],
+	//     [ "--no-acpi", "" ],
+	//     [
+	//       "-netdev",
+	//       "user,id=mynet0,",
+	//       "hostfwd=hostip:hostport-guestip:guestport",
+	//       ""
+	//     ],
+	//     [ "-device", "virtio-net,netdev=mynet0" ]
+	//   ]
 	// ```
 	//
 	// would produce the following (not including other defaults supplied by
@@ -243,7 +257,7 @@ type Config struct {
 	// virtio-net,netdev=mynet0"
 	// ```
 	//
-	// ~> **Windows Users:** [QEMU for Windows](https://qemu.weilnetz.de/)
+	// ~> **Windows Users:** [QEMU for Windows](https://qemu.weilnetz.de/)
 	// builds are available though an environmental variable does need to be
 	// set for QEMU for Windows to redirect stdout to the console instead of
 	// stdout.txt.
@@ -258,15 +272,21 @@ type Config struct {
 	// You can also use the `SSHHostPort` template variable to produce a packer
 	// template that can be invoked by `make` in parallel:
 	//
+	// In JSON:
 	// ```json
-	//{
 	//   "qemuargs": [
 	//     [ "-netdev", "user,hostfwd=tcp::{{ .SSHHostPort }}-:22,id=forward"],
 	//     [ "-device", "virtio-net,netdev=forward,id=net0"]
 	//   ]
-	// }
 	// ```
 	//
+	// In HCL2:
+	// ```hcl
+	//   qemuargs = [
+	//     [ "-netdev", "user,hostfwd=tcp::{{ .SSHHostPort }}-:22,id=forward"],
+	//     [ "-device", "virtio-net,netdev=forward,id=net0"]
+	//   ]
+	//
 	// `make -j 3 my-awesome-packer-templates` spawns 3 packer processes, each
 	// of which will bind to their own SSH port as determined by each process.
 	// This will also work with WinRM, just change the port forward in

builder/scaleway/builder_test.go

@@ -41,6 +41,19 @@ func TestBuilder_Prepare_BadType(t *testing.T) {
 	}
 }
 
+func TestBuilderPrepare(t *testing.T) {
+	var b Builder
+	config := testConfig()
+
+	_, warnings, err := b.Prepare(config)
+	if len(warnings) > 0 {
+		t.Fatalf("bad: %#v", warnings)
+	}
+	if err != nil {
+		t.Fatal("should not have errors")
+	}
+}
+
 func TestBuilderPrepare_InvalidKey(t *testing.T) {
 	var b Builder
 	config := testConfig()

builder/scaleway/config.go

@@ -67,7 +67,7 @@ type Config struct {
 
 	RemoveVolume bool `mapstructure:"remove_volume"`
 
-	UserAgent string
+	UserAgent string `mapstructure-to-hcl2:",skip"`
 	ctx       interpolate.Context
 }
 

builder/scaleway/config.hcl2spec.go

@@ -74,7 +74,6 @@ type FlatConfig struct {
 	Bootscript                *string           `mapstructure:"bootscript" required:"false" cty:"bootscript" hcl:"bootscript"`
 	BootType                  *string           `mapstructure:"boottype" required:"false" cty:"boottype" hcl:"boottype"`
 	RemoveVolume              *bool             `mapstructure:"remove_volume" cty:"remove_volume" hcl:"remove_volume"`
-	UserAgent                 *string           `cty:"user_agent" hcl:"user_agent"`
 }
 
 // FlatMapstructure returns a new FlatConfig.
@@ -154,7 +153,6 @@ func (*FlatConfig) HCL2Spec() map[string]hcldec.Spec {
 		"bootscript":                   &hcldec.AttrSpec{Name: "bootscript", Type: cty.String, Required: false},
 		"boottype":                     &hcldec.AttrSpec{Name: "boottype", Type: cty.String, Required: false},
 		"remove_volume":                &hcldec.AttrSpec{Name: "remove_volume", Type: cty.Bool, Required: false},
-		"user_agent":                   &hcldec.AttrSpec{Name: "user_agent", Type: cty.String, Required: false},
 	}
 	return s
 }

command/inspect_test.go

@@ -94,6 +94,26 @@ Use it at will.
         manifest
         shell-local
 
+`},
+		{[]string{"inspect", "-var=fruit=peach", filepath.Join(testFixture("var-arg"), "fruit_builder.json")}, nil, `Packer Inspect: JSON mode
+Required variables:
+
+  fruit
+
+Optional variables and their defaults:
+
+
+Builders:
+
+  null
+
+Provisioners:
+
+  <No provisioners>
+
+Note: If your build names contain user variables or template
+functions such as 'timestamp', these are processed at build time,
+and therefore only show in their raw form here.
 `},
 	}
 
@@ -107,7 +127,7 @@ Use it at will.
 			}
 			actual := string(bs)
 			if diff := cmp.Diff(tc.expected, actual); diff != "" {
-				t.Fatalf("unexpected ouput %s", diff)
+				t.Fatalf("unexpected output %s", diff)
 			}
 		})
 	}

command/test-fixtures/var-arg/fruit_builder.json

@@ -1,6 +1,6 @@
 {
     "variables": {
-        "fruit": ""
+        "fruit": null
     },
     "builders": [
         {

version/version.go

@@ -9,12 +9,12 @@ import (
 var GitCommit string
 
 // The main version number that is being run at the moment.
-const Version = "1.6.1"
+const Version = "1.6.2"
 
 // A pre-release marker for the version. If this is "" (empty string)
 // then it means that it is a final release. Otherwise, this is a pre-release
 // such as "dev" (in development), "beta", "rc1", etc.
-const VersionPrerelease = ""
+const VersionPrerelease = "dev"
 
 func FormattedVersion() string {
 	var versionString bytes.Buffer

website/pages/docs/builders/docker.mdx

@@ -39,6 +39,9 @@ documentation.
 Below is a fully functioning example. It doesn't do anything useful, since no
 provisioners are defined, but it will effectively repackage an image.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "type": "docker",
@@ -47,12 +50,32 @@ provisioners are defined, but it will effectively repackage an image.
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "docker" "example" {
+    image = "ubuntu"
+    export_path = "image.tar"
+}
+
+build {
+  sources = ["source.docker.example"]
+}
+```
+
+</Tab>
+</Tabs>
+
 ## Basic Example: Commit
 
 Below is another example, the same as above but instead of exporting the
 running container, this one commits the container to an image. The image can
 then be more easily tagged, pushed, etc.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "type": "docker",
@@ -61,6 +84,23 @@ then be more easily tagged, pushed, etc.
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "docker" "example" {
+    image = "ubuntu"
+    commit = true
+}
+
+build {
+  sources = ["source.docker.example"]
+}
+```
+
+</Tab>
+</Tabs>
+
 ## Basic Example: Changes to Metadata
 
 Below is an example using the changes argument of the builder. This feature
@@ -72,6 +112,9 @@ Docker](https://docs.docker.com/engine/reference/commandline/commit/).
 Example uses of all of the options, assuming one is building an NGINX image
 from ubuntu as an simple example:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "type": "docker",
@@ -91,6 +134,30 @@ from ubuntu as an simple example:
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "docker" "example" {
+    image = "ubuntu"
+    commit = true
+      changes = [
+      "USER www-data",
+      "WORKDIR /var/www",
+      "ENV HOSTNAME www.example.com",
+      "VOLUME /test1 /test2",
+      "EXPOSE 80 443",
+      "LABEL version=1.0",
+      "ONBUILD RUN date",
+      "CMD [\"nginx\", \"-g\", \"daemon off;\"]",
+      "ENTRYPOINT /var/www/start.sh"
+    ]
+}
+```
+
+</Tab>
+</Tabs>
+
 Allowed metadata fields that can be changed are:
 
 - CMD
@@ -164,21 +231,43 @@ created image. This is accomplished using a sequence definition (a collection
 of post-processors that are treated as as single pipeline, see
 [Post-Processors](/docs/templates/post-processors) for more information):
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "post-processors": [
     [
       {
         "type": "docker-import",
-        "repository": "hashicorp/packer",
+        "repository": "myrepo/myimage",
         "tag": "0.7"
       },
-      "docker-push"
+      {
+        "type": "docker-push"
+      }
     ]
   ]
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+  post-processors {
+    post-processor "docker-import" {
+        repository =  "myrepo/myimage"
+        tag = "0.7"
+      }
+    post-processor "docker-push" {}
+  }
+}
+```
+
+</Tab>
+</Tabs>
+
 In the above example, the result of each builder is passed through the defined
 sequence of post-processors starting first with the `docker-import`
 post-processor which will import the artifact as a docker image. The resulting
@@ -204,21 +293,43 @@ definition (a collection of post-processors that are treated as as single
 pipeline, see [Post-Processors](/docs/templates/post-processors) for more
 information):
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "post-processors": [
     [
       {
         "type": "docker-tag",
-        "repository": "hashicorp/packer",
+        "repository": "myrepo/myimage",
         "tag": "0.7"
       },
-      "docker-push"
+      {
+        "type": "docker-push"
+      }
     ]
   ]
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+  post-processors {
+    post-processor "docker-tag" {
+        repository =  "myrepo/myimage"
+        tag = "0.7"
+      }
+    post-processor "docker-push" {}
+  }
+}
+```
+
+</Tab>
+</Tabs>
+
 In the above example, the result of each builder is passed through the defined
 sequence of post-processors starting first with the `docker-tag` post-processor
 which tags the committed image with the supplied repository and tag
@@ -230,13 +341,16 @@ Going a step further, if you wanted to tag and push an image to multiple
 container repositories, this could be accomplished by defining two,
 nearly-identical sequence definitions, as demonstrated by the example below:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "post-processors": [
     [
       {
         "type": "docker-tag",
-        "repository": "hashicorp/packer1",
+        "repository": "myrepo/myimage1",
         "tag": "0.7"
       },
       "docker-push"
@@ -244,7 +358,7 @@ nearly-identical sequence definitions, as demonstrated by the example below:
     [
       {
         "type": "docker-tag",
-        "repository": "hashicorp/packer2",
+        "repository": "myrepo/myimage2",
         "tag": "0.7"
       },
       "docker-push"
@@ -253,6 +367,30 @@ nearly-identical sequence definitions, as demonstrated by the example below:
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+  post-processors {
+    post-processor "docker-tag" {
+        repository =  "myrepo/myimage1"
+        tag = "0.7"
+      }
+    post-processor "docker-push" {}
+  }
+  post-processors {
+    post-processor "docker-tag" {
+        repository =  "myrepo/myimage2"
+        tag = "0.7"
+      }
+    post-processor "docker-push" {}
+  }
+}
+```
+
+</Tab>
+</Tabs>
+
 <span id="amazon-ec2-container-registry"></span>
 
 ## Docker For Windows
@@ -268,6 +406,9 @@ containers, so you must either commit or discard them.
 The following is a fully functional template for building a Windows
 container.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "builders": [
@@ -282,12 +423,34 @@ container.
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "docker" "windows" {
+    image = "ubuntu"
+    container_dir = "c:/app"
+    windows_container = true
+    commit = true
+}
+
+build {
+  sources = ["source.docker.example"]
+}
+```
+
+</Tab>
+</Tabs>
+
 ## Amazon EC2 Container Registry
 
 Packer can tag and push images for use in [Amazon EC2 Container
 Registry](https://aws.amazon.com/ecr/). The post processors work as described
 above and example configuration properties are shown below:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "post-processors": [
@@ -309,6 +472,27 @@ above and example configuration properties are shown below:
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+post-processors {
+  post-processor "docker-tag" {
+      repository = "12345.dkr.ecr.us-east-1.amazonaws.com/packer"
+      tag = "0.7"
+  }
+  post-processor "docker-push" {
+      ecr_login = true
+      aws_access_key = "YOUR KEY HERE"
+      aws_secret_key = "YOUR SECRET KEY HERE"
+      login_server = "https://12345.dkr.ecr.us-east-1.amazonaws.com/"
+  }
+}
+```
+
+</Tab>
+</Tabs>
+
 [Learn how to set Amazon AWS
 credentials.](/docs/builders/amazon#specifying-amazon-credentials)
 

website/pages/docs/builders/qemu.mdx

@@ -26,14 +26,16 @@ necessary to run the virtual machine on KVM or Xen.
 Here is a basic example. This example is functional so long as you fixup paths
 to files, URLS for ISOs and checksums.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "builders": [
     {
       "type": "qemu",
       "iso_url": "http://mirror.raystedman.net/centos/6/isos/x86_64/CentOS-6.9-x86_64-minimal.iso",
-      "iso_checksum": "af4a1640c0c6f348c6c41f1ea9e192a2",
-      "iso_checksum_type": "md5",
+      "iso_checksum": "md5:af4a1640c0c6f348c6c41f1ea9e192a2",
       "output_directory": "output_centos_tdhtest",
       "shutdown_command": "echo 'packer' | sudo -S shutdown -P now",
       "disk_size": "5000M",
@@ -55,6 +57,37 @@ to files, URLS for ISOs and checksums.
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "qemu" "example" {
+  iso_url           = "http://mirror.raystedman.net/centos/6/isos/x86_64/CentOS-6.9-x86_64-minimal.iso"
+  iso_checksum      = "md5:af4a1640c0c6f348c6c41f1ea9e192a2"
+  output_directory  = "output_centos_tdhtest"
+  shutdown_command  = "echo 'packer' | sudo -S shutdown -P now"
+  disk_size         = "5000M"
+  format            = "qcow2"
+  accelerator       = "kvm"
+  http_directory    = "path/to/httpdir"
+  ssh_username      = "root"
+  ssh_password      = "s0m3password"
+  ssh_timeout       = "20m"
+  vm_name           = "tdhtest"
+  net_device        = "virtio-net"
+  disk_interface    = "virtio"
+  boot_wait         = "10s"
+  boot_command      = ["<tab> text ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/centos6-ks.cfg<enter><wait>"]
+}
+
+build {
+  sources = ["source.qemu.example"]
+}
+```
+
+</Tab>
+</Tabs>
+
 This is an example only, and will time out waiting for SSH because we have not
 provided a kickstart file. You must add a valid kickstart file to the
 "http_directory" and then provide the file in the "boot_command" in order for

website/pages/docs/builders/vagrant.mdx

@@ -145,6 +145,9 @@ the Compress post-processor will not work with this builder.
 
 Sample for `hashicorp/precise64` with virtualbox provider.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "builders": [
@@ -159,6 +162,25 @@ Sample for `hashicorp/precise64` with virtualbox provider.
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "vagrant" "example" {
+  communicator = "ssh"
+  source_path = "hashicorp/precise64"
+  provider = "virtualbox"
+  add_force = true
+}
+
+build {
+  sources = ["source.vagrant.example"]
+}
+```
+
+</Tab>
+</Tabs>
+
 ## A note on SSH connections
 
 Currently this builder only works for SSH connections, and automatically fills

website/pages/docs/provisioners/ansible.mdx

@@ -27,15 +27,11 @@ DigitalOcean. Replace the mock `api_token` value with your own.
 
 Example Packer template:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
-  "provisioners": [
-    {
-      "type": "ansible",
-      "playbook_file": "./playbook.yml"
-    }
-  ],
-
   "builders": [
     {
       "type": "digitalocean",
@@ -43,10 +39,39 @@ Example Packer template:
       "image": "ubuntu-14-04-x64",
       "region": "sfo1"
     }
+  ],
+  "provisioners": [
+    {
+      "type": "ansible",
+      "playbook_file": "./playbook.yml"
+    }
   ]
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "digitalocean" "example"{
+  api_token = "6a561151587389c7cf8faa2d83e94150a4202da0e2bad34dd2bf236018ffaeeb"
+  image = "ubuntu-14-04-x64"
+  region = "sfo1"
+}
+
+build {
+    sources = [
+        "source.digitalocean.example",
+    ]
+    provisioner {
+      "playbook_file": "./playbook.yml"
+    }
+}
+```
+
+</Tab>
+</Tabs>
+
 Example playbook:
 
 ```yaml
@@ -102,10 +127,23 @@ commonly useful Ansible variables:
 To debug underlying issues with Ansible, add `"-vvvv"` to `"extra_arguments"`
 to enable verbose logging.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
   "extra_arguments": [ "-vvvv" ]
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+  extra_arguments = [ "-vvvv" ]
+```
+
+</Tab>
+</Tabs>
+
 ## Limitations
 
 ### Redhat / CentOS
@@ -123,6 +161,9 @@ Redhat / CentOS builds have been known to fail with the following error due to
 Building within a chroot (e.g. `amazon-chroot`) requires changing the Ansible
 connection to chroot and running Ansible as root/sudo.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "builders": [
@@ -138,7 +179,7 @@ connection to chroot and running Ansible as root/sudo.
       "type": "ansible",
       "extra_arguments": [
         "--connection=chroot",
-        "--inventory-file=/mnt/packer-amazon-chroot,"
+        "--inventory-file=/mnt/packer-amazon-chroot"
       ],
       "playbook_file": "main.yml"
     }
@@ -146,6 +187,33 @@ connection to chroot and running Ansible as root/sudo.
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "amazon-chroot" "example" {
+  mount_path = "/mnt/packer-amazon-chroot"
+    region = "us-east-1"
+    source_ami = "ami-123456"
+}
+
+build {
+  sources = [
+    "source.amazon-chroot.example"
+  ]
+    provisioner "ansible" {
+      extra_arguments = [
+          "--connection=chroot",
+          "--inventory-file=/mnt/packer-amazon-chroot"
+        ]
+    playbook_file = "main.yml"
+    }
+}
+```
+
+</Tab>
+</Tabs>
+
 ### WinRM Communicator
 
 There are two possible methods for using ansible with the WinRM communicator.
@@ -165,6 +233,9 @@ extra_arguments.
 
 Below is a fully functioning Ansible example using WinRM:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "builders": [
@@ -181,7 +252,7 @@ Below is a fully functioning Ansible example using WinRM:
         "most_recent": true,
         "owners": "amazon"
       },
-      "ami_name": "default-packer",
+      "ami_name": "test-ansible-packer",
       "user_data_file": "windows_bootstrap.txt",
       "communicator": "winrm",
       "force_deregister": true,
@@ -202,6 +273,49 @@ Below is a fully functioning Ansible example using WinRM:
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "amazon-ebs" "example" {
+    region = "us-east-1"
+    instance_type = "t2.micro"
+    source_ami_filter {
+        filters =  {
+          "virtualization-type": "hvm",
+          "name": "*Windows_Server-2012*English-64Bit-Base*",
+          "root-device-type": "ebs"
+        }
+        most_recent = true
+        owners = ["amazon"]
+    }
+    ami_name = "test-ansible-packer"
+    user_data_file = "windows_bootstrap.txt"
+    communicator = "winrm"
+    force_deregister = true
+    winrm_username = "Administrator"
+    winrm_insecure = true
+    winrm_use_ssl = true
+}
+
+build {
+    sources = [
+        "source.amazon-ebs.example",
+    ]
+    provisioner "ansible" {
+      playbook_file = "./playbooks/playbook-windows.yml"
+      user = "Administrator"
+      use_proxy = false
+      extra_arguments = [
+        "-e", "ansible_winrm_server_cert_validation=ignore"
+      ]
+    }
+}
+```
+
+</Tab>
+</Tabs>
+
 Note that you do have to set the "Administrator" user, because otherwise Ansible
 will default to using the user that is calling Packer, rather than the user
 configured inside of the Packer communicator. For the contents of
@@ -218,9 +332,21 @@ When running from OSX, you may see an error like:
 If you see this, you may be able to work around the issue by telling Ansible to
 explicitly not use any proxying; you can do this by setting the template option
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 "ansible_env_vars": ["no_proxy=\"*\""],
 ```
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+ansible_env_vars = ["no_proxy=\"*\""]
+```
+
+</Tab>
+</Tabs>
 
 in the above Ansible template.
 
@@ -380,6 +506,9 @@ source /tmp/venv/bin/activate && ANSIBLE_FORCE_COLOR=1 PYTHONUNBUFFERED=1 /tmp/v
 
 The ansible provisioner template remains very simple. For example:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "type": "ansible",
@@ -387,6 +516,18 @@ The ansible provisioner template remains very simple. For example:
   "playbook_file": "./playbook.yml"
 }
 ```
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+provisioner "ansible" {
+  command = "/Path/To/call_ansible.sh"
+  playbook_file = "./playbook.yml"
+}
+```
+
+</Tab>
+</Tabs>
 
 Note that we're calling ansible-playbook at the end of this command and passing
 all command line arguments through into this call; this is necessary for
@@ -396,7 +537,8 @@ arguments with spaces will not be read properly.
 
 ### Docker
 
-When trying to use Ansible with Docker, you need to tweak a few options.
+When trying to use Ansible with Docker, it should "just work" but if it doesn't
+you may need to tweak a few options.
 
 - Change the ansible_connection from "ssh" to "docker"
 - Set a Docker container name via the --name option.
@@ -405,7 +547,10 @@ On a CI server you probably want to overwrite ansible_host with a random name.
 
 Example Packer template:
 
-```hcl
+<Tabs>
+<Tab heading="JSON">
+
+```json
 {
   "variables": {
     "ansible_host": "default",
@@ -432,6 +577,42 @@ Example Packer template:
   ]
 }
 ```
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+variable "ansible_host" {
+  default = "default"
+}
+
+variable "ansible_connection" {
+  default = "docker"
+}
+
+source "docker" "example" {
+      image = "centos:7"
+      commit = true
+      run_command = [ "-d", "-i", "-t", "--name", var.ansible_host, "{{.Image}}", "/bin/bash" ]
+}
+
+build {
+  sources = [
+    "source.docker.example"
+  ]
+
+  provisioner "ansible" {
+      groups = [ "webserver" ]
+      playbook_file = "./webserver.yml"
+      extra_arguments = [
+          "--extra-vars",
+          "ansible_host=${var.ansible_host} ansible_connection=${var.ansible_connection}"
+      ]
+  }
+}
+```
+
+</Tab>
+</Tabs>
 
 Example playbook:
 

website/pages/docs/provisioners/shell.mdx

@@ -24,6 +24,9 @@ Shell](/docs/provisioners/windows-shell) provisioners.
 
 The example below is fully functional.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "type": "shell",
@@ -31,6 +34,18 @@ The example below is fully functional.
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+provisioner "shell" {
+    inline = ["echo foo"]
+}
+```
+
+</Tab>
+</Tabs>
+
 ## Configuration Reference
 
 @include 'provisioners/shell-config.mdx'
@@ -67,8 +82,9 @@ The example below is fully functional.
   - `EnvVarFile` is the path to the file containing env vars, if
     `use_env_var_file` is true.
 
-- `expect_disconnect` (boolean) - Defaults to `false`. When `true`, allow the server to disconnect from Packer without throwing an error.
-  A disconnect might happen if you restart the ssh server or reboot the host.
+- `expect_disconnect` (boolean) - Defaults to `false`. When `true`, allow the
+  server to disconnect from Packer without throwing an error. A disconnect
+  might happen if you restart the ssh server or reboot the host.
 
 - `inline_shebang` (string) - The
   [shebang](https://en.wikipedia.org/wiki/Shebang_%28Unix%29) value to use
@@ -183,6 +199,9 @@ and Packer will start executing the next one before SSH actually quits and the
 machine restarts. For this, put use "pause_before" to make Packer wait before
 executing the next script:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "type": "shell",
@@ -192,6 +211,20 @@ executing the next script:
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+provisioner "shell" {
+  script       = "script.sh"
+  pause_before = "10s"
+  timeout      = "10s"
+}
+```
+
+</Tab>
+</Tabs>
+
 Some OS configurations don't properly kill all network connections on reboot,
 causing the provisioner to hang despite a reboot occurring. In this case, make
 sure you shut down the network interfaces on reboot or in your shell script.
@@ -217,6 +250,9 @@ provisioner](/docs/provisioners/file) (more secure) or using `ssh-keyscan`
 to populate the file (less secure). An example of the latter accessing github
 would be:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "type": "shell",
@@ -228,6 +264,22 @@ would be:
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+provisioner "shell" {
+  inline = [
+    "sudo apt-get install -y git",
+    "ssh-keyscan github.com >> ~/.ssh/known_hosts",
+    "git clone git@github.com:exampleorg/myprivaterepo.git"
+  ]
+}
+```
+
+</Tab>
+</Tabs>
+
 ## Troubleshooting
 
 _My shell script doesn't work correctly on Ubuntu_
@@ -260,6 +312,9 @@ _My builds don't always work the same_
   can create race conditions. Your first provisioner can tell the machine to
   wait until it completely boots.
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
 {
   "type": "shell",
@@ -267,32 +322,77 @@ _My builds don't always work the same_
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+provisioner "shell" {
+  inline = ["sleep 10"]
+}
+```
+
+</Tab>
+</Tabs>
+
 ## Quoting Environment Variables
 
 Packer manages quoting for you, so you should't have to worry about it. Below
 is an example of packer template inputs and what you should expect to get out:
 
+<Tabs>
+<Tab heading="JSON">
+
 ```json
-  "provisioners": [
-    {
-      "type":  "shell",
-      "environment_vars": ["FOO=foo",
-                           "BAR=bar's",
-                           "BAZ=baz=baz",
-                           "QUX==qux",
-                           "FOOBAR=foo bar",
-                           "FOOBARBAZ='foo bar baz'",
-                           "QUX2=\"qux\""],
-      "inline": ["echo \"FOO is $FOO\"",
-                 "echo \"BAR is $BAR\"",
-                 "echo \"BAZ is $BAZ\"",
-                 "echo \"QUX is $QUX\"",
-                 "echo \"FOOBAR is $FOOBAR\"",
-                 "echo \"FOOBARBAZ is $FOOBARBAZ\"",
-                 "echo \"QUX2 is $QUX2\""]
-    }
+"provisioners": [
+  {
+    "type":  "shell",
+    "environment_vars": ["FOO=foo",
+                         "BAR=bar's",
+                         "BAZ=baz=baz",
+                         "QUX==qux",
+                         "FOOBAR=foo bar",
+                         "FOOBARBAZ='foo bar baz'",
+                         "QUX2=\"qux\""],
+    "inline": ["echo \"FOO is $FOO\"",
+               "echo \"BAR is $BAR\"",
+               "echo \"BAZ is $BAZ\"",
+               "echo \"QUX is $QUX\"",
+               "echo \"FOOBAR is $FOOBAR\"",
+               "echo \"FOOBARBAZ is $FOOBARBAZ\"",
+               "echo \"QUX2 is $QUX2\""]
+  }
+]
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+provisioner "shell" {
+  environment_vars = [
+    "FOO=foo",
+    "BAR=bar's",
+    "BAZ=baz=baz",
+    "QUX==qux",
+    "FOOBAR=foo bar",
+    "FOOBARBAZ='foo bar baz'",
+    "QUX2=\"qux\""
+  ]
+  inline = [
+    "echo \"FOO is $FOO\"",
+    "echo \"BAR is $BAR\"",
+    "echo \"BAZ is $BAZ\"",
+    "echo \"QUX is $QUX\"",
+    "echo \"FOOBAR is $FOOBAR\"",
+    "echo \"FOOBARBAZ is $FOOBARBAZ\"",
+    "echo \"QUX2 is $QUX2\""
+  ]
+}
+```
+
+</Tab>
+</Tabs>
+
 Output:
 
 ```text

website/pages/partials/builder/qemu/Config-not-required.mdx

@@ -9,17 +9,17 @@
   accelerator you specified. When no accelerator is specified, Packer will try
   to use `kvm` if it is available but will default to `tcg` otherwise.
   
-  -> The `hax` accelerator has issues attaching CDROM ISOs. This is an
+  ~> The `hax` accelerator has issues attaching CDROM ISOs. This is an
   upstream issue which can be tracked
   [here](https://github.com/intel/haxm/issues/20).
   
-  -> The `hvf` and `whpx` accelerator are new and experimental as of
+  ~> The `hvf` and `whpx` accelerator are new and experimental as of
   [QEMU 2.12.0](https://wiki.qemu.org/ChangeLog/2.12#Host_support).
   You may encounter issues unrelated to Packer when using these.  You may need to
   add [ "-global", "virtio-pci.disable-modern=on" ] to `qemuargs` depending on the
   guest operating system.
   
-  -> For `whpx`, note that [Stefan Weil's QEMU for Windows distribution](https://qemu.weilnetz.de/w64/)
+  ~> For `whpx`, note that [Stefan Weil's QEMU for Windows distribution](https://qemu.weilnetz.de/w64/)
   does not include WHPX support and users may need to compile or source a
   build of QEMU for Windows themselves with WHPX support.
 
@@ -131,7 +131,7 @@
   as an empty string is ignored. All values after the switch are
   concatenated with no separator.
   
-  ~> **Warning:** The qemu command line allows extreme flexibility, so
+  ~> **Warning:** The qemu command line allows extreme flexibility, so
   beware of conflicting arguments causing failures of your run. For
   instance, using --no-acpi could break the ability to send power signal
   type commands (e.g., shutdown -P now) to the virtual machine, thus
@@ -141,8 +141,8 @@
   
   The following shows a sample usage:
   
+  In JSON:
   ```json
-  {
     "qemuargs": [
       [ "-m", "1024M" ],
       [ "--no-acpi", "" ],
@@ -154,7 +154,21 @@
       ],
       [ "-device", "virtio-net,netdev=mynet0" ]
     ]
-  }
+  ```
+  
+  In HCL2:
+  ```hcl
+    qemuargs = [
+      [ "-m", "1024M" ],
+      [ "--no-acpi", "" ],
+      [
+        "-netdev",
+        "user,id=mynet0,",
+        "hostfwd=hostip:hostport-guestip:guestport",
+        ""
+      ],
+      [ "-device", "virtio-net,netdev=mynet0" ]
+    ]
   ```
   
   would produce the following (not including other defaults supplied by
@@ -166,7 +180,7 @@
   virtio-net,netdev=mynet0"
   ```
   
-  ~> **Windows Users:** [QEMU for Windows](https://qemu.weilnetz.de/)
+  ~> **Windows Users:** [QEMU for Windows](https://qemu.weilnetz.de/)
   builds are available though an environmental variable does need to be
   set for QEMU for Windows to redirect stdout to the console instead of
   stdout.txt.
@@ -181,15 +195,21 @@
   You can also use the `SSHHostPort` template variable to produce a packer
   template that can be invoked by `make` in parallel:
   
+  In JSON:
   ```json
-  {
     "qemuargs": [
       [ "-netdev", "user,hostfwd=tcp::{{ .SSHHostPort }}-:22,id=forward"],
       [ "-device", "virtio-net,netdev=forward,id=net0"]
     ]
-  }
   ```
   
+  In HCL2:
+  ```hcl
+    qemuargs = [
+      [ "-netdev", "user,hostfwd=tcp::{{ .SSHHostPort }}-:22,id=forward"],
+      [ "-device", "virtio-net,netdev=forward,id=net0"]
+    ]
+  
   `make -j 3 my-awesome-packer-templates` spawns 3 packer processes, each
   of which will bind to their own SSH port as determined by each process.
   This will also work with WinRM, just change the port forward in