github.com/hashicorp/packer@v1.14.3/website/content/docs/post-processors/manifest.mdx (about) 1 --- 2 description: > 3 The `manifest` post-processor creates a JSON file that contains data about a Packer build's artifacts, letting you track a run's outputs. 4 page_title: manifest post-processor reference 5 --- 6 7 <BadgesHeader> 8 <PluginBadge type="official" /> 9 </BadgesHeader> 10 11 # `manifest` post-processor 12 13 Artifact BuilderId: `packer.post-processor.manifest` 14 15 The manifest post-processor writes a JSON file with a list of all of the 16 artifacts packer produces during a run. If your Packer template includes 17 multiple builds, this helps you keep track of which output artifacts (files, 18 AMI IDs, Docker containers, etc.) correspond to each build. 19 20 The manifest post-processor is invoked each time a build completes and 21 _updates_ data in the manifest file. Builds are identified by name and type, 22 and include their build time, artifact ID, and file list. 23 24 If packer is run with the `-force` flag the manifest file will be truncated 25 automatically during each packer run. Otherwise, subsequent builds will be 26 added to the file. You can use the timestamps to see which is the latest 27 artifact. 28 29 You can specify manifest more than once and write each build to its own file, 30 or write all builds to the same file. For simple builds manifest only needs to 31 be specified once (see below) but you can also chain it together with other 32 post-processors such as Docker and Artifice. 33 34 ## Configuration 35 36 ### Optional: 37 38 @include 'post-processor/manifest/Config-not-required.mdx' 39 40 ~> **Note**: Unlike most other post-processors, the keep_input_artifact option doesn't apply for the manifest 41 post-processor. We will always retain the input artifact for manifest, since deleting the files we just recorded 42 is not a behavior anyone should ever expect. 43 44 ### Example Configuration 45 46 The minimal way to use the manifest post-processor is by just writing its definition, like: 47 48 <Tabs> 49 <Tab heading="HCL2"> 50 51 ```hcl 52 post-processor "manifest" {} 53 ``` 54 55 </Tab> 56 <Tab heading="JSON"> 57 58 ```json 59 { 60 "post-processors": [ 61 { 62 "type": "manifest" 63 } 64 ] 65 } 66 ``` 67 68 </Tab> 69 </Tabs> 70 71 A more complete example: 72 73 <Tabs> 74 <Tab heading="HCL2"> 75 76 ```hcl 77 post-processor "manifest" { 78 output = "manifest.json" 79 strip_path = true 80 custom_data = { 81 my_custom_data = "example" 82 } 83 } 84 ``` 85 86 </Tab> 87 <Tab heading="JSON"> 88 89 ```json 90 { 91 "post-processors": [ 92 { 93 "type": "manifest", 94 "output": "manifest.json", 95 "strip_path": true, 96 "custom_data": { 97 "my_custom_data": "example" 98 } 99 } 100 ] 101 } 102 ``` 103 104 </Tab> 105 </Tabs> 106 107 An example manifest file looks like: 108 109 ```json 110 { 111 "builds": [ 112 { 113 "name": "docker", 114 "builder_type": "docker", 115 "build_time": 1507245986, 116 "files": [ 117 { 118 "name": "packer_example", 119 "size": 102219776 120 } 121 ], 122 "artifact_id": "Container", 123 "packer_run_uuid": "6d5d3185-fa95-44e1-8775-9e64fe2e2d8f", 124 "custom_data": { 125 "my_custom_data": "example" 126 } 127 } 128 ], 129 "last_run_uuid": "6d5d3185-fa95-44e1-8775-9e64fe2e2d8f" 130 } 131 ``` 132 133 If the build is run again, the new build artifacts will be added to the 134 manifest file rather than replacing it. It is possible to grab specific build 135 artifacts from the manifest by using `packer_run_uuid`. 136 137 The above manifest was generated with the following template: 138 139 <Tabs> 140 <Tab heading="HCL2"> 141 142 ```hcl 143 source "docker" "docker"{ 144 image = "ubuntu:latest" 145 export_path = "packer_example" 146 run_command = ["-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}"] 147 } 148 149 build { 150 sources = ["docker.docker"] 151 152 post-processor "manifest" { 153 output = "manifest.json" 154 strip_path = true 155 custom_data = { 156 my_custom_data = "example" 157 } 158 } 159 } 160 ``` 161 162 </Tab> 163 <Tab heading="JSON"> 164 165 ```json 166 { 167 "builders": [ 168 { 169 "type": "docker", 170 "image": "ubuntu:latest", 171 "export_path": "packer_example", 172 "run_command": ["-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}"] 173 } 174 ], 175 "post-processors": [ 176 { 177 "type": "manifest", 178 "output": "manifest.json", 179 "strip_path": true, 180 "custom_data": { 181 "my_custom_data": "example" 182 } 183 } 184 ] 185 } 186 ``` 187 188 </Tab> 189 </Tabs> 190 191 Example usage: 192 193 The manifest can be very useful for cleaning up old artifacts, or printing 194 important values to logs. The following example uses jq, a command-line tool for 195 parsing json output, to find and echo the AWS ami-id of an AMI created by a 196 build. 197 198 ```bash 199 200 #!/bin/bash 201 202 AMI_ID=$(jq -r '.builds[-1].artifact_id | split(":") | .[1]' manifest.json) 203 echo $AMI_ID 204 205 ```