Ignore new links from markdown link checker because site isnt live

use relative pathing in links
fix vagrant docs link

mlc_config.json

@@ -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": [

website/content/docs/builders/vmware/vsphere-clone.mdx

@@ -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.

website/content/docs/commands/hcl2_upgrade.mdx

@@ -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.

website/content/docs/extending/custom-builders.mdx

@@ -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

website/content/docs/post-processors/googlecompute-export.mdx

@@ -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
 

website/content/docs/post-processors/googlecompute-import.mdx

@@ -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
 

website/content/docs/post-processors/vagrant.mdx

@@ -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.
 

website/content/guides/packer-on-cicd/pipelineing-builds.mdx

@@ -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>