From 78ce1dbde9bb8bce18bee00101f3b15da981543d Mon Sep 17 00:00:00 2001
From: Sylvia Moss <moss@hashicorp.com>
Date: Thu, 6 Aug 2020 19:43:35 +0200
Subject: [PATCH] Add manifest hcl2 examples (#9721)

---
 .../pages/docs/post-processors/manifest.mdx   | 104 +++++++++++++-----
 1 file changed, 76 insertions(+), 28 deletions(-)

diff --git a/website/pages/docs/post-processors/manifest.mdx b/website/pages/docs/post-processors/manifest.mdx
index abbe5d453..820ce3497 100644
--- a/website/pages/docs/post-processors/manifest.mdx
+++ b/website/pages/docs/post-processors/manifest.mdx
@@ -1,9 +1,7 @@
 ---
 description: >
   The manifest post-processor writes a JSON file with the build artifacts and
-  IDs
-
-  from a packer run.
+  IDs from a packer run.
 layout: docs
 page_title: Manifest - Post-Processors
 sidebar_title: Manifest
@@ -38,17 +36,37 @@ post-processors such as Docker and Artifice.
 
 @include 'post-processor/manifest/Config-not-required.mdx'
 
-- `keep_input_artifact` (boolean) - Unlike most other post-processors, the
-  keep_input_artifact option will have no effect for the manifest
-  post-processor. We will always retain the input artifact for manifest,
-  since deleting the files we just recorded is not a behavior anyone should
-  ever expect. `keep_input_artifact will` therefore always be evaluated as
-  true, regardless of the value you enter into this field.
-
 ### Example Configuration
 
-You can simply add `{"type":"manifest"}` to your post-processor section. Below
-is a more complete example:
+The minimal way to use the manifest post-processor is by just writing its definition, like:
+
+<Tabs>
+<Tab heading="JSON">
+
+```json
+{
+  "post-processors": [
+    {
+      "type": "manifest"
+    }
+  ]
+}
+```
+
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+post-processor "manifest" {}
+```
+
+</Tab>
+</Tabs>
+
+A more complete example:
+
+<Tabs>
+<Tab heading="JSON">
 
 ```json
 {
@@ -65,6 +83,22 @@ is a more complete example:
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+post-processor "manifest" {
+    output = "manifest.json"
+    strip_path = true
+    custom_data = {
+      my_custom_data = "example"
+    }
+}
+```
+
+</Tab>
+</Tabs>
+
 An example manifest file looks like:
 
 ```json
@@ -95,7 +129,10 @@ If the build is run again, the new build artifacts will be added to the
 manifest file rather than replacing it. It is possible to grab specific build
 artifacts from the manifest by using `packer_run_uuid`.
 
-The above manifest was generated with this packer.json:
+The above manifest was generated with the following template:
+
+<Tabs>
+<Tab heading="JSON">
 
 ```json
 {
@@ -107,21 +144,6 @@ The above manifest was generated with this packer.json:
       "run_command": ["-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}"]
     }
   ],
-  "provisioners": [
-    {
-      "type": "shell",
-      "inline": "mkdir /Setup"
-    },
-    {
-      "type": "file",
-      "source": "../scripts/dummy_bash.sh",
-      "destination": "/Setup"
-    },
-    {
-      "type": "shell",
-      "inline": ["ls -alh /Setup/"]
-    }
-  ],
   "post-processors": [
     {
       "type": "manifest",
@@ -135,6 +157,32 @@ The above manifest was generated with this packer.json:
 }
 ```
 
+</Tab>
+<Tab heading="HCL2">
+
+```hcl
+source "docker" "docker"{
+    image = "ubuntu:latest"
+    export_path = "packer_example"
+    run_command = ["-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}"]
+}
+
+build {
+    sources = ["docker.docker"]
+
+    post-processor "manifest" {
+        output = "manifest.json"
+        strip_path = true
+        custom_data = {
+          my_custom_data = "example"
+        }
+    }
+}
+```
+
+</Tab>
+</Tabs>
+
 Example usage:
 
 The manifest can be very useful for cleaning up old artifacts, or printing