|
|
|
|
@ -47,9 +47,6 @@ The available configuration options are listed below. All elements are required.
|
|
|
|
|
- `direction` (string) - The direction of the file transfer. This defaults to
|
|
|
|
|
"upload". If it is set to "download" then the file "source" in the machine
|
|
|
|
|
will be downloaded locally to "destination"
|
|
|
|
|
|
|
|
|
|
The source file must exist before running Packer, this means that creating the
|
|
|
|
|
file with a provisioner does not work.
|
|
|
|
|
|
|
|
|
|
## Directory Uploads
|
|
|
|
|
|
|
|
|
|
@ -78,6 +75,17 @@ directly.
|
|
|
|
|
This behavior was adopted from the standard behavior of rsync. Note that under
|
|
|
|
|
the covers, rsync may or may not be used.
|
|
|
|
|
|
|
|
|
|
## Uploading files that don't exist before Packer starts
|
|
|
|
|
|
|
|
|
|
In general, local files used as the source **must** exist before Packer is run.
|
|
|
|
|
This is great for catching typos and ensuring that once a build is started,
|
|
|
|
|
that it will succeed. However, this also means that you can't generate a file
|
|
|
|
|
during your build and then upload it using the file provisioner later.
|
|
|
|
|
A convenient workaround is to upload a directory instead of a file. The
|
|
|
|
|
directory still must exist, but its contents don't. You can write your
|
|
|
|
|
generated file to the directory during the Packer run, and have it be uploaded
|
|
|
|
|
later.
|
|
|
|
|
|
|
|
|
|
## Symbolic link uploads
|
|
|
|
|
|
|
|
|
|
The behavior when uploading symbolic links depends on the communicator. The
|
|
|
|
|
|