Commit f623dad8 authored by Mitchell Hashimoto's avatar Mitchell Hashimoto

website: more complete custom builder docs

parent 7f20043b
...@@ -102,18 +102,62 @@ to respond to these cancellations and clean up after itself. ...@@ -102,18 +102,62 @@ to respond to these cancellations and clean up after itself.
## Creating an Artifact ## Creating an Artifact
TODO The `Run` method is expected to return an implementation of the
`packer.Artifact` interface. Each builder must create their own
implementation. The interface is very simple and the documentation on the
interface is quite clear.
The only part of an artifact that may be confusing is the `BuilderId`
method. This method must return an absolutely unique ID for the builder.
In general, I follow the practice of making the ID contain my GitHub username
and then the platform it is building for. For example, the builder ID of
the VMware builder is "mitchellh.vmware" or something similar.
Post-processors use the builder ID value in order to make some assumptions
about the artifact results, so it is important it never changes.
Other than the builder ID, the rest should be self-explanatory by reading
the [packer.Artifact interface documentation](#).
## Hooks ## Hooks
TODO TODO: Hooks are still undergoing some thought...
## Provisioning ## Provisioning
TODO Packer has built-in support for provisioning, but the moment when provisioning
runs must be invoked by the builder itself, since only the builder knows
when the machine is running and ready for communication.
## Caching Files When the machine is ready to be provisioned, run the `packer.HookProvision`
hook, making sure the communicator is not nil, since this is required for
provisioners. An example of calling the hook is shown below:
TODO <pre class="prettyprint">
hook.Run(packer.HookProvision, ui, comm, nil)
</pre>
At this point, Packer will run the provisioners and no additional work
is necessary.
## Caching Files
It is common for some builders to deal with very large files, or files that
take a long time to generate. For example, the VMware builder has the capability
to download the operating system ISO from the internet. This is timely process,
so it would be convenient to cache the file. This sort of caching is a core
part of Packer that is exposed to builders.
The cache interface is `packer.Cache`. It behaves much like a Go
[RWMutex](http://golang.org/pkg/sync/#RWMutex). The builder requests a "lock"
on certain cache keys, and is given exclusive access to that key for the
duration of the lock. This locking mechanism allows multiple builders to
share cache data even though they're running in parallel.
For example, both the VMware and VirtualBox support downloading an operating
system ISO from the internet. Most of the time, this ISO is identical. The
locking mechanisms of the cache allow one of the builders to download it
only once, but allow both builders to share the downloaded file.
The [documentation for packer.Cache](#) is
very detailed in how it works.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment