Type '/' to Search

»The post-processor block

Note: This page is about HCL2 Packer templates. HCL2 templates were first introduced as a beta feature into Packer version 1.5. As of v1.7, HCL2 support is no longer in beta, and is the preferred way to write Packer configuration. For the old-style stable configuration language see template docs. As of v1.6.2, you can convert your legacy JSON template into an HCL2 config file using the hcl2_upgrade command.

The post-processor block defines how a post-processor is configured.

# builds.pkr.hcl
build {
  # ... build image
  post-processor "checksum" { # checksum image
    checksum_types = [ "md5", "sha512" ] # checksum the artifact
    keep_input_artifact = true           # keep the artifact
  }

  post-processor "amazon-import" { # upload image to amazon
  }
}

# builds.pkr.hclbuild {  # ... build image  post-processor "checksum" { # checksum image    checksum_types = [ "md5", "sha512" ] # checksum the artifact    keep_input_artifact = true           # keep the artifact  }
  post-processor "amazon-import" { # upload image to amazon  }}

Each post-processor runs after each defined build. A post-processor takes the Artifact from a build. Post-processors are optional, and they can be used to upload artifacts, re-package, or more. The list of available post-processors can be found in the post-processors section.

A post-processor can also take the Artifact from another post-processor when it is defined in a post-processors block list, that is a list of chained post processors.

Note: The input 'artifact' received by a post-processor will be automatically deleted by default.

»Keep an input artifact

To prevent an input artifact from being deleted, you can set the keep_input_artifact field to true to make Packer keep both artifacts. For example if we want to checksum an artifact and keep the artifact:

# builds.pkr.hcl
build {
  # ...
  post-processor "checksum" {
    checksum_types = [ "md5", "sha512" ]
    keep_input_artifact = true
  }
}

# builds.pkr.hclbuild {  # ...  post-processor "checksum" {    checksum_types = [ "md5", "sha512" ]    keep_input_artifact = true  }}

»Run on Specific Builds

You can use the only or except configurations to run a post-processor only with specific sources. These two configurations do what you expect: only will only run the post-processor on the specified sources and except will run the post-processor on anything other than the specified sources.

An example of only being used is shown below, but the usage of except is effectively the same:

# builds.pkr.hcl
build {
  # ...
  post-processor "checksum" {
    checksum_types = [ "md5", "sha512" ]
    keep_input_artifact = true
    only = ["amazon-ebs.example"]
  }
}

# builds.pkr.hclbuild {  # ...  post-processor "checksum" {    checksum_types = [ "md5", "sha512" ]    keep_input_artifact = true    only = ["amazon-ebs.example"]  }}

The values within only or except are source names, not builder types.

If you want to exclude certain post-processors when running packer build from the command line, you can do so:

packer build --except=checksum mytemplate.pkr.hcl will not run the checksum post-processor. This command line exclusion works by referencing post-processor name. By default, the post-processor is named after is its type, as demonstrated above in the checksum example. You can make a post-processor's name unique by adding a "name" field to each post-processor block.

While the -except flag can be used to filter out post-processors on the command line, the -only flag does not work for post-processors. If you wish to only run a post-processor for a given source build you must use the only=[source] syntax inside of your hcl templates, as described above.

»Build Contextual Variables

Packer allows to access connection information and basic instance state information from a post-processor. These information are stored in the build variable. Check out the Contextual Variables documentation to learn more about and see some examples of how to use them.

»Related

  • The post-processors block allows to define one or more chain of post-processors that will take the output from the build and provision steps.