172 lines
6.8 KiB
Plaintext
172 lines
6.8 KiB
Plaintext
---
|
|
description: |
|
|
Packer is controlled using a command-line interface. All interaction with
|
|
Packer is done via the `packer` tool. Like many other command-line tools, the
|
|
`packer` tool takes a subcommand to execute, and that subcommand may have
|
|
additional options as well. Subcommands are executed with `packer SUBCOMMAND`,
|
|
where "SUBCOMMAND" is the actual command you wish to execute.
|
|
layout: docs
|
|
page_title: Commands
|
|
sidebar_title: 'Commands (CLI)'
|
|
sidebar_current: docs-commands
|
|
---
|
|
|
|
# Packer Commands (CLI)
|
|
|
|
Packer is controlled using a command-line interface. All interaction with
|
|
Packer is done via the `packer` tool. Like many other command-line tools, the
|
|
`packer` tool takes a subcommand to execute, and that subcommand may have
|
|
additional options as well. Subcommands are executed with `packer SUBCOMMAND`,
|
|
where "SUBCOMMAND" is the actual command you wish to execute.
|
|
|
|
If you run `packer` by itself, help will be displayed showing all available
|
|
subcommands and a brief synopsis of what they do. In addition to this, you can
|
|
run any `packer` command with the `-h` flag to output more detailed help for a
|
|
specific subcommand.
|
|
|
|
In addition to the documentation available on the command-line, each command is
|
|
documented on this website. You can find the documentation for a specific
|
|
subcommand using the navigation to the left.
|
|
|
|
## Machine-Readable Output
|
|
|
|
By default, the output of Packer is very human-readable. It uses nice
|
|
formatting, spacing, and colors in order to make Packer a pleasure to use.
|
|
However, Packer was built with automation in mind. To that end, Packer supports
|
|
a fully machine-readable output setting, allowing you to use Packer in
|
|
automated environments.
|
|
|
|
Because the machine-readable output format was made with Unix tools in mind, it
|
|
is `awk`/`sed`/`grep`/etc. friendly and provides a familiar interface without
|
|
requiring you to learn a new format.
|
|
|
|
### Enabling Machine-Readable Output
|
|
|
|
The machine-readable output format can be enabled by passing the
|
|
`-machine-readable` flag to any Packer command. This immediately enables all
|
|
output to become machine-readable on stdout. Logging, if enabled, continues to
|
|
appear on stderr. An example of the output is shown below:
|
|
|
|
```text
|
|
$ packer -machine-readable version
|
|
1498365963,,version,1.0.2
|
|
1498365963,,version-prelease,
|
|
1498365963,,version-commit,3ead2750b+CHANGES
|
|
1498365963,,ui,say,Packer v1.0.2
|
|
```
|
|
|
|
The format will be covered in more detail later. But as you can see, the output
|
|
immediately becomes machine-friendly. Try some other commands with the
|
|
`-machine-readable` flag to see!
|
|
|
|
~>; The `-machine-readable` flag is designed for automated environments and
|
|
is mutually-exclusive with the `-debug` flag, which is designed for interactive
|
|
environments.
|
|
|
|
### Format for Machine-Readable Output
|
|
|
|
The machine readable format is a line-oriented, comma-delimited text format.
|
|
This makes it more convenient to parse using standard Unix tools such as `awk`
|
|
or `grep` in addition to full programming languages like Ruby or Python.
|
|
|
|
The format is:
|
|
|
|
```text
|
|
timestamp,target,type,data...
|
|
```
|
|
|
|
Each component is explained below:
|
|
|
|
- `timestamp` is a Unix timestamp in UTC of when the message was printed.
|
|
|
|
- `target` When you call `packer build` this can be either empty or
|
|
individual build names, e.g. `amazon-ebs`. It is normally empty when builds
|
|
are in progress, and the build name when artifacts of particular builds are
|
|
being referred to.
|
|
|
|
- `type` is the type of machine-readable message being outputted. The two
|
|
most common `type`s are `ui` and `artifact`
|
|
|
|
- `data` is zero or more comma-separated values associated with the prior
|
|
type. The exact amount and meaning of this data is type-dependent, so you
|
|
must read the documentation associated with the type to understand fully.
|
|
|
|
Within the format, if data contains a comma, it is replaced with
|
|
`%!(PACKER_COMMA)`. This was preferred over an escape character such as `\'`
|
|
because it is more friendly to tools like `awk`.
|
|
|
|
Newlines within the format are replaced with their respective standard escape
|
|
sequence. Newlines become a literal `\n` within the output. Carriage returns
|
|
become a literal `\r`.
|
|
|
|
### Machine-Readable Message Types
|
|
|
|
Here's an incomplete list of types you may see in the machine-readable output:
|
|
|
|
You'll see these data types when you run `packer build`:
|
|
|
|
- `ui`: this means that the information being provided is a human-readable
|
|
string that would be sent to stdout even if we aren't in machine-readable
|
|
mode. There are three "data" subtypes associated with this type:
|
|
|
|
- `say`: in a non-machine-readable format, this would be bolded. Normally
|
|
it is used for anouncements about beginning new steps in the build
|
|
process
|
|
|
|
- `message`: the most commonly used message type, used for basic updates
|
|
during the build process.
|
|
|
|
- `error`: reserved for errors
|
|
|
|
- `artifact-count`: This data type tells you how many artifacts a particular
|
|
build produced.
|
|
|
|
- `artifact`: This data type tells you information about what Packer created
|
|
during its build. An example of output follows the pattern
|
|
`timestamp, buildname, artifact, artifact_number, key, value` where `key`
|
|
and `value` contain information about the artifact.
|
|
|
|
For example:
|
|
|
|
```shell
|
|
1539967803,,ui,say,\n==> Builds finished. The artifacts of successful builds are:
|
|
1539967803,amazon-ebs,artifact-count,2
|
|
1539967803,amazon-ebs,artifact,0,builder-id,mitchellh.amazonebs
|
|
1539967803,amazon-ebs,artifact,0,id,eu-west-1:ami-04d23aca8bdd36e30
|
|
1539967803,amazon-ebs,artifact,0,string,AMIs were created:\neu-west-1: ami-04d23aca8bdd36e30\n
|
|
1539967803,amazon-ebs,artifact,0,files-count,0
|
|
1539967803,amazon-ebs,artifact,0,end
|
|
1539967803,,ui,say,--> amazon-ebs: AMIs were created:\neu-west-1: ami-04d23aca8bdd36e30\n
|
|
1539967803,amazon-ebs,artifact,1,builder-id,
|
|
1539967803,amazon-ebs,artifact,1,id,
|
|
1539967803,amazon-ebs,artifact,1,string,
|
|
1539967803,amazon-ebs,artifact,1,files-count,0
|
|
2018/10/19 09:50:03 waiting for all plugin processes to complete...
|
|
1539967803,amazon-ebs,artifact,1,end
|
|
```
|
|
|
|
You'll see these data types when you run `packer version`:
|
|
|
|
- `version`: what version of Packer is running
|
|
|
|
- `version-prerelease`: Data will contain `dev` if version is prerelease, and
|
|
otherwise will be blank.
|
|
|
|
- `version-commit`: The git hash for the commit that the branch of Packer is
|
|
currently on; most useful for Packer developers.
|
|
|
|
## Autocompletion
|
|
|
|
The `packer` command features opt-in subcommand autocompletion that you can
|
|
enable for your shell with `packer -autocomplete-install`. After doing so, you
|
|
can invoke a new shell and use the feature.
|
|
|
|
For example, assume a tab is typed at the end of each prompt line:
|
|
|
|
```shell
|
|
$ packer p
|
|
plugin build
|
|
$ packer build -
|
|
-color -debug -except -force -machine-readable -on-error -only -parallel -timestamp -var -var-file
|
|
```
|