Ignore new links from markdown link checker because site isnt live
use relative pathing in links fix vagrant docs link
This commit is contained in:
parent
e3b1af4711
commit
a91a8ec63b
|
@ -11,6 +11,15 @@
|
|||
},
|
||||
{
|
||||
"pattern": "^https://github.com/hashicorp/packer-plugin-scaffolding"
|
||||
},
|
||||
{
|
||||
"pattern": "^https://www.packer.io/docs/templates/hcl_templates/"
|
||||
},
|
||||
{
|
||||
"pattern": "^https://packer.io/docs/templates/hcl_templates/"
|
||||
},
|
||||
{
|
||||
"pattern": "^/docs/templates/hcl_templates/"
|
||||
}
|
||||
],
|
||||
"replacementPatterns": [
|
||||
|
|
|
@ -15,7 +15,7 @@ Type: `vsphere-clone`
|
|||
This builder clones VMs from existing templates.
|
||||
|
||||
- VMware Player is not required.
|
||||
- It uses the official vCenter API, and does not require ESXi host [modification](https://www.packer.io/docs/builders/vmware-iso.html#building-on-a-remote-vsphere-hypervisor)
|
||||
- It uses the official vCenter API, and does not require ESXi host [modification](/docs/builders/vmware-iso.html#building-on-a-remote-vsphere-hypervisor)
|
||||
- This builder is supported for vSphere version 6.5 and greater. Builds on lower
|
||||
versions may work, but some configuration options may throw errors because they
|
||||
do not exist in the older versions of the vSphere API.
|
||||
|
|
|
@ -59,7 +59,7 @@ here is the list of calls that should get transformed:
|
|||
- `` {{ user `my_var` }} `` becomes `${var.my_var}`.
|
||||
- `` {{ env `my_var` }} `` becomes `${var.my_var}`. Packer HCL2 supports
|
||||
environment variables through input variables. See
|
||||
[docs](http://packer.io/docs/templates/hcl_templates/variables#environment-variables)
|
||||
[docs](/docs/templates/hcl_templates/variables#environment-variables)
|
||||
for more info.
|
||||
- `{{ timestamp }}` becomes `${local.timestamp}`, the local variable
|
||||
will be created for all generated files.
|
||||
|
|
|
@ -204,8 +204,8 @@ provide to procisioners (see below for more details on generatedData.)
|
|||
|
||||
Packer makes it possible to provide custom template engine variables to be
|
||||
shared with provisioners and post-processors using the `build` function.
|
||||
Json template `build` docs are [here](https://www.packer.io/docs/templates/engine#build)
|
||||
and HCL template build docs are [here](https://www.packer.io/docs/templates/hcl_templates/contextual-variables#build-variables).
|
||||
Json template `build` docs are [here](/docs/templates/engine#build)
|
||||
and HCL template build docs are [here](/docs/templates/hcl_templates/contextual-variables#build-variables).
|
||||
|
||||
As of Packer v1.5.0, builder Prepare() methods return a list of custom variables
|
||||
which we call `generated data`. We use that list of variables to generate a
|
||||
|
|
|
@ -26,7 +26,7 @@ As such, the authentication credentials that built the image must have write
|
|||
permissions to the GCS `paths`.
|
||||
|
||||
~> **Note**: By default the GCE image being exported will be deleted once the image has been exported.
|
||||
To prevent Packer from deleting the image set the `keep_input_artifact` configuration option to `true`. See [Post-Processor Input Artifacts](https://www.packer.io/docs/templates/post-processors#input-artifacts) for more details.
|
||||
To prevent Packer from deleting the image set the `keep_input_artifact` configuration option to `true`. See [Post-Processor Input Artifacts](/docs/templates/post-processors#input-artifacts) for more details.
|
||||
|
||||
## Configuration
|
||||
|
||||
|
|
|
@ -29,7 +29,7 @@ see the [GCE import documentation](https://cloud.google.com/compute/docs/images/
|
|||
for details.
|
||||
|
||||
~> **Note**: To prevent Packer from deleting the compressed RAW disk image set the `keep_input_artifact` configuration option to `true`.
|
||||
See [Post-Processor Input Artifacts](https://www.packer.io/docs/templates/post-processors#input-artifacts) for more details.
|
||||
See [Post-Processor Input Artifacts](/docs/templates/post-processors#input-artifacts) for more details.
|
||||
|
||||
## Configuration
|
||||
|
||||
|
|
|
@ -26,7 +26,7 @@ If you've never used a post-processor before, please read the documentation on
|
|||
This knowledge will be expected for the remainder of this document.
|
||||
|
||||
Because Vagrant boxes are
|
||||
[provider-specific](https://docs.vagrantup.com/v2/boxes/format.html), the
|
||||
[provider-specific](https://www.vagrantup.com/docs/boxes/format), the
|
||||
Vagrant post-processor is hardcoded to understand how to convert the artifacts
|
||||
of certain builders into proper boxes for their respective providers.
|
||||
|
||||
|
|
|
@ -128,7 +128,7 @@ To run the build, call `packer build example_virtualbox_iso.json`.
|
|||
This example does not set the output_directory or output_filename, so the file
|
||||
will be placed in a default name of "output-virtualbox-iso/vbox-example.ovf" --
|
||||
the builder will print this file name to the UI output, but in this example the
|
||||
[manifest](https://www.packer.io/docs/post-processors/manifest) post-processor
|
||||
[manifest](/docs/post-processors/manifest) post-processor
|
||||
to will store build information, including the names of the output files, in a
|
||||
json file named "stage-1-manifest.json". From there, you can programmatically
|
||||
look up the output file information.
|
||||
|
@ -136,7 +136,7 @@ look up the output file information.
|
|||
## Customizing the iso using the virtualbox-ovf builder
|
||||
|
||||
That output filename generated in the first stage can be used as the
|
||||
[source_path](https://www.packer.io/docs/builders/virtualbox/ovf#source_path)
|
||||
[source_path](/docs/builders/virtualbox/ovf#source_path)
|
||||
for the virtualbox-ovf builder.
|
||||
|
||||
<Tabs>
|
||||
|
|
Loading…
Reference in New Issue