github.com/ratanraj/packer@v1.3.2/website/source/docs/post-processors/manifest.html.md (about)

     1  ---
     2  description: |
     3      The manifest post-processor writes a JSON file with the build artifacts and
     4      IDs from a packer run.
     5  layout: docs
     6  page_title: 'Manifest - Post-Processors'
     7  sidebar_current: 'docs-post-processors-manifest'
     8  ---
     9  
    10  # Manifest Post-Processor
    11  
    12  Type: `manifest`
    13  
    14  The manifest post-processor writes a JSON file with a list of all of the artifacts packer produces during a run. If your packer template includes multiple builds, this helps you keep track of which output artifacts (files, AMI IDs, docker containers, etc.) correspond to each build.
    15  
    16  The manifest post-processor is invoked each time a build completes and *updates* data in the manifest file. Builds are identified by name and type, and include their build time, artifact ID, and file list.
    17  
    18  If packer is run with the `-force` flag the manifest file will be truncated automatically during each packer run. Otherwise, subsequent builds will be added to the file. You can use the timestamps to see which is the latest artifact.
    19  
    20  You can specify manifest more than once and write each build to its own file, or write all builds to the same file. For simple builds manifest only needs to be specified once (see below) but you can also chain it together with other post-processors such as Docker and Artifice.
    21  
    22  ## Configuration
    23  
    24  ### Optional:
    25  
    26  -   `output` (string) The manifest will be written to this file. This defaults to `packer-manifest.json`.
    27  -   `strip_path` (boolean) Write only filename without the path to the manifest file. This defaults to false.
    28  
    29  ### Example Configuration
    30  
    31  You can simply add `{"type":"manifest"}` to your post-processor section. Below is a more verbose example:
    32  
    33  ``` json
    34  {
    35    "post-processors": [
    36      {
    37        "type": "manifest",
    38        "output": "manifest.json",
    39        "strip_path": true
    40      }
    41    ]
    42  }
    43  ```
    44  
    45  An example manifest file looks like:
    46  
    47  ``` json
    48  {
    49    "builds": [
    50      {
    51        "name": "docker",
    52        "builder_type": "docker",
    53        "build_time": 1507245986,
    54        "files": [
    55          {
    56            "name": "packer_example",
    57            "size": 102219776
    58          }
    59        ],
    60        "artifact_id": "Container",
    61        "packer_run_uuid": "6d5d3185-fa95-44e1-8775-9e64fe2e2d8f"
    62      }
    63    ],
    64    "last_run_uuid": "6d5d3185-fa95-44e1-8775-9e64fe2e2d8f"
    65  }
    66  ```
    67  
    68  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`.
    69  
    70  The above manifest was generated with this packer.json:
    71  
    72  ```json
    73  {
    74    "builders": [
    75      {
    76        "type":        "docker",
    77        "image":       "ubuntu:latest",
    78        "export_path": "packer_example",
    79        "run_command": [ "-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}" ]
    80      }
    81    ],
    82      "provisioners": [
    83      {
    84        "type": "shell",
    85        "inline": "mkdir /Setup"
    86      },
    87      {
    88        "type": "file",
    89        "source": "../scripts/dummy_bash.sh",
    90        "destination": "/Setup"
    91      },
    92      {
    93        "type": "shell",
    94        "inline":["ls -alh /Setup/"]
    95      }
    96    ],
    97    "post-processors": [
    98      {
    99        "type": "manifest",
   100        "output": "manifest.json",
   101        "strip_path": true
   102      }
   103    ]
   104  }
   105  ```