github.com/aclaygray/packer@v1.3.2/website/source/docs/templates/post-processors.html.md (about) 1 --- 2 description: | 3 The post-processor section within a template configures any post-processing 4 that will be done to images built by the builders. Examples of post-processing 5 would be compressing files, uploading artifacts, etc. 6 layout: docs 7 page_title: 'Post-Processors - Templates' 8 sidebar_current: 'docs-templates-post-processors' 9 --- 10 11 # Template Post-Processors 12 13 The post-processor section within a template configures any post-processing that 14 will be done to images built by the builders. Examples of post-processing would 15 be compressing files, uploading artifacts, etc. 16 17 Post-processors are *optional*. If no post-processors are defined within a 18 template, then no post-processing will be done to the image. The resulting 19 artifact of a build is just the image outputted by the builder. 20 21 This documentation page will cover how to configure a post-processor in a 22 template. The specific configuration options available for each post-processor, 23 however, must be referenced from the documentation for that specific 24 post-processor. 25 26 Within a template, a section of post-processor definitions looks like this: 27 28 ``` json 29 { 30 "post-processors": [ 31 // ... one or more post-processor definitions here 32 ] 33 } 34 ``` 35 36 For each post-processor definition, Packer will take the result of each of the 37 defined builders and send it through the post-processors. This means that if you 38 have one post-processor defined and two builders defined in a template, the 39 post-processor will run twice (once for each builder), by default. There are 40 ways, which will be covered later, to control what builders post-processors 41 apply to, if you wish. 42 43 ## Post-Processor Definition 44 45 Within the `post-processors` array in a template, there are three ways to define 46 a post-processor. There are *simple* definitions, *detailed* definitions, and 47 *sequence* definitions. Another way to think about this is that the "simple" and 48 "detailed" definitions are shortcuts for the "sequence" definition. 49 50 A **simple definition** is just a string; the name of the post-processor. An 51 example is shown below. Simple definitions are used when no additional 52 configuration is needed for the post-processor. 53 54 ``` json 55 { 56 "post-processors": ["compress"] 57 } 58 ``` 59 60 A **detailed definition** is a JSON object. It is very similar to a builder or 61 provisioner definition. It contains a `type` field to denote the type of the 62 post-processor, but may also contain additional configuration for the 63 post-processor. A detailed definition is used when additional configuration is 64 needed beyond simply the type for the post-processor. An example is shown below. 65 66 ``` json 67 { 68 "post-processors": [ 69 { 70 "type": "compress", 71 "format": "tar.gz" 72 } 73 ] 74 } 75 ``` 76 77 A **sequence definition** is a JSON array comprised of other **simple** or 78 **detailed** definitions. The post-processors defined in the array are run in 79 order, with the artifact of each feeding into the next, and any intermediary 80 artifacts being discarded. A sequence definition may not contain another 81 sequence definition. Sequence definitions are used to chain together multiple 82 post-processors. An example is shown below, where the artifact of a build is 83 compressed then uploaded, but the compressed result is not kept. 84 85 It is very important that any post processors that need to be run in order, be sequenced! 86 87 ``` json 88 { 89 "post-processors": [ 90 [ 91 "compress", 92 { "type": "upload", "endpoint": "http://example.com" } 93 ] 94 ] 95 } 96 ``` 97 98 As you may be able to imagine, the **simple** and **detailed** definitions are 99 simply shortcuts for a **sequence** definition of only one element. 100 101 ## Input Artifacts 102 103 When using post-processors, the input artifact (coming from a builder or another 104 post-processor) is discarded by default after the post-processor runs. This is 105 because generally, you don't want the intermediary artifacts on the way to the 106 final artifact created. 107 108 In some cases, however, you may want to keep the intermediary artifacts. You can 109 tell Packer to keep these artifacts by setting the `keep_input_artifact` 110 configuration to `true`. An example is shown below: 111 112 ``` json 113 { 114 "post-processors": [ 115 { 116 "type": "compress", 117 "keep_input_artifact": true 118 } 119 ] 120 } 121 ``` 122 123 This setting will only keep the input artifact to *that specific* 124 post-processor. If you're specifying a sequence of post-processors, then all 125 intermediaries are discarded by default except for the input artifacts to 126 post-processors that explicitly state to keep the input artifact. 127 128 -> **Note:** The intuitive reader may be wondering what happens if multiple 129 post-processors are specified (not in a sequence). Does Packer require the 130 configuration to keep the input artifact on all the post-processors? The answer 131 is no, of course not. Packer is smart enough to figure out that at least one 132 post-processor requested that the input be kept, so it will keep it around. 133 134 ## Run on Specific Builds 135 136 You can use the `only` or `except` configurations to run a post-processor only 137 with specific builds. These two configurations do what you expect: `only` will 138 only run the post-processor on the specified builds and `except` will run the 139 post-processor on anything other than the specified builds. 140 141 An example of `only` being used is shown below, but the usage of `except` is 142 effectively the same. `only` and `except` can only be specified on "detailed" 143 configurations. If you have a sequence of post-processors to run, `only` and 144 `except` will only affect that single post-processor in the sequence. 145 146 ``` json 147 { 148 "type": "vagrant", 149 "only": ["virtualbox-iso"] 150 } 151 ``` 152 153 The values within `only` or `except` are *build names*, not builder types. If 154 you recall, build names by default are just their builder type, but if you 155 specify a custom `name` parameter, then you should use that as the value instead 156 of the type.