Merge pull request #143 from priteau/master
website: Fix some typos and an error in the website documentation
This commit is contained in:
commit
16be4ed641
|
@ -89,7 +89,7 @@ the prior linked page for information on syntax if you're unfamiliar with it.
|
|||
|
||||
The available variables are shown below:
|
||||
|
||||
* `CreateTime`- This will be replaced with the Unix timestamp of when the
|
||||
* `CreateTime` - This will be replaced with the Unix timestamp of when the
|
||||
image is created.
|
||||
|
||||
## Finding Image, Region, and Size IDs
|
||||
|
|
|
@ -14,7 +14,7 @@ artifacts that are created will be outputted at the end of the build.
|
|||
* `-debug` - Disables parallelization and enables debug mode. Debug mode flags
|
||||
the builders that they should output debugging information. The exact behavior
|
||||
of debug mode is left to the builder. In general, builders usually will stop
|
||||
between each step, waiting keyboard input before continuing. This will allow
|
||||
between each step, waiting for keyboard input before continuing. This will allow
|
||||
the user to inspect state and so on.
|
||||
|
||||
* `-except=foo,bar,baz` - Builds all the builds except those with the given
|
||||
|
|
|
@ -8,7 +8,7 @@ Plugins allow new functionality to be added to Packer without
|
|||
modifying the core source code. Packer plugins are able to add new
|
||||
commands, builders, provisioners, hooks, and more. In fact, much of Packer
|
||||
itself is implemented by writing plugins that are simply distributed with
|
||||
the Packer. For example, all the commands, builders, provisioners, and more
|
||||
Packer. For example, all the commands, builders, provisioners, and more
|
||||
that ship with Packer are implemented as Plugins that are simply hardcoded
|
||||
to load with Packer.
|
||||
|
||||
|
|
|
@ -72,7 +72,7 @@ A **sequence definition** is a JSON array comprised of other **simple** or
|
|||
**detailed** definitions. The post-processors defined in the array are run
|
||||
in order, with the artifact of each feeding into the next, and any intermediary
|
||||
artifacts being discarded. A sequence definition may not contain another
|
||||
sequence definition. Sequnce definitions are used to chain together multiple
|
||||
sequence definition. Sequence definitions are used to chain together multiple
|
||||
post-processors. An example is shown below, where the artifact of a build is
|
||||
compressed then uploaded, but the compressed result is not kept.
|
||||
|
||||
|
@ -93,7 +93,7 @@ are simply shortcuts for a **sequence** definition of only one element.
|
|||
## Input Artifacts
|
||||
|
||||
When using post-processors, the input artifact (coming from a builder or
|
||||
another post-proccessor) is discarded by default after the post-processor runs.
|
||||
another post-processor) is discarded by default after the post-processor runs.
|
||||
This is because generally, you don't want the intermediary artifacts on the
|
||||
way to the final artifact created.
|
||||
|
||||
|
|
|
@ -39,7 +39,7 @@ the `type` key. This key specifies the name of the provisioner to use.
|
|||
Additional keys within the object are used to configure the provisioner,
|
||||
with the exception of a handful of special keys, covered later.
|
||||
|
||||
As an example, the "shell" provisioner requires at least the `script` key,
|
||||
As an example, the "shell" provisioner requires a key such as `script`
|
||||
which specifies a path to a shell script to execute within the machines
|
||||
being created.
|
||||
|
||||
|
|
Loading…
Reference in New Issue