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