intro nav

website/_redirects

@@ -24,3 +24,5 @@
 /docs/machine-readable/*                        /docs/commands/index.html                   301!
 /docs/command-line/*                            /docs/commands/:splat                       200
 /docs/extend/*                                  /docs/extending/:splat                      200
+/intro/getting-started/install                  /intro/getting-started                      301!
+/intro/getting-started/install.html             /intro/getting-started                      301!

website/data/intro-navigation.js

@@ -5,4 +5,11 @@
 // - All directories must have an "index.mdx" file to serve as
 //   the landing page for the category
 
-export default []
+export default [
+  'why',
+  'use-cases',
+  {
+    category: 'getting-started',
+    content: ['build-image', 'provision', 'parallel-builds', 'vagrant', 'next']
+  }
+]

website/layouts/intro.jsx

@@ -18,7 +18,7 @@ function IntroLayoutWrapper(pageMeta) {
         }}
         sidenav={{
           Link,
-          category: 'guides',
+          category: 'intro',
           currentPage: props.path,
           data,
           order

website/pages/intro/getting-started/build-image.mdx

@@ -2,6 +2,7 @@
 layout: intro
 sidebar_current: intro-getting-started-build-image
 page_title: Build an Image - Getting Started
+sidebar_title: 'Build an Image'
 description: |-
   With Packer installed, let's just dive right into it and build our first
   image. Our first image will be an Amazon EC2 AMI with Redis pre-installed.
@@ -197,7 +198,7 @@ how to validate and build templates into machine images.
 
 Create a file named `welcome.txt` and add the following:
 
-```
+```text
 WELCOME TO PACKER!
 ```
 
@@ -211,7 +212,7 @@ echo "hello"
 Set your access key and id as environment variables, so we don't need to pass
 them in through the command line:
 
-```
+```text
 export AWS_ACCESS_KEY_ID=MYACCESSKEYID
 export AWS_SECRET_ACCESS_KEY=MYSECRETACCESSKEY
 ```
@@ -270,7 +271,7 @@ it might look something like this: `"source_ami": "ami-fce3c696"`.
 
 Your output will look like this:
 
-```
+```shell
 amazon-ebs output will be in this color.
 
 ==> amazon-ebs: Prevalidating AMI Name: packer-linux-aws-demo-1507231105
@@ -407,29 +408,22 @@ https://cloudywindows.io/post/winrm-for-provisioning-close-the-door-on-the-way-o
 
 Save the above code in a file named `bootstrap_win.txt`.
 
--> **A quick aside/warning:**<br />
+-> **A quick aside/warning:** Windows administrators in the know might be wondering why we haven't simply
-Windows administrators in the know might be wondering why we haven't simply
 used a `winrm quickconfig -q` command in the script above, as this would
 _automatically_ set up all of the required elements necessary for connecting
-over WinRM. Why all the extra effort to configure things manually?<br />
+over WinRM. Why all the extra effort to configure things manually?<br /><br />
 Well, long and short, use of the `winrm quickconfig -q` command can sometimes
 cause the Packer build to fail shortly after the WinRM connection is
-established. How?<br />
+established. How?<br /><br />1. Among other things, as well as setting up the listener for WinRM, the
-
+quickconfig command also configures the firewall to allow management messages
-1. Among other things, as well as setting up the listener for WinRM, the
+to be sent over HTTP.<br />2. This undoes the previous command in the script that configured the
-   quickconfig command also configures the firewall to allow management messages
+firewall to prevent this access.<br />3. The upshot is that the system is configured and ready to accept WinRM
-   to be sent over HTTP.<br />
+connections earlier than intended.<br />4. If Packer establishes its WinRM connection immediately after execution of
-2. This undoes the previous command in the script that configured the
+the 'winrm quickconfig -q' command, the later commands within the script that
-   firewall to prevent this access.<br />
+restart the WinRM service will unceremoniously pull the rug out from under
-3. The upshot is that the system is configured and ready to accept WinRM
+the connection.<br />5. While Packer does _a lot_ to ensure the stability of its connection in to
-   connections earlier than intended.<br />
+your instance, this sort of abuse can prove to be too much and _may_ cause
-4. If Packer establishes its WinRM connection immediately after execution of
+your Packer build to stall irrecoverably or fail!
-   the 'winrm quickconfig -q' command, the later commands within the script that
-   restart the WinRM service will unceremoniously pull the rug out from under
-   the connection.<br />
-5. While Packer does _a lot_ to ensure the stability of its connection in to
-   your instance, this sort of abuse can prove to be too much and _may_ cause
-   your Packer build to stall irrecoverably or fail!
 
 Now we've got the business of getting Packer connected to our instance
 taken care of, let's get on with the _real_ reason we're doing all this,
@@ -462,13 +456,13 @@ Write-Host "Finally, VAR4 is:" $Env:VAR4
 Write-Host "None of the special characters needed escaping in the template"
 ```
 
-Finally, we need to create the actual [build template](/docs/templates/index.html).
+Finally, we need to create the actual [build template](/docs/templates).
 Remember, this template is the core configuration file that Packer uses to
 understand what you want to build, and how you want to build it.
 
 As mentioned earlier, the specific builder we are using in this example
-is the [Amazon EBS builder](/docs/builders/amazon-ebs.html).
+is the [Amazon EBS builder](/docs/builders/amazon-ebs).
-The template below demonstrates use of the [`source_ami_filter`](/docs/builders/amazon-ebs.html#source_ami_filter) configuration option
+The template below demonstrates use of the [`source_ami_filter`](/docs/builders/amazon-ebs#source_ami_filter) configuration option
 available within the builder for automatically selecting the _latest_
 suitable source Windows AMI provided by Amazon.
 We also use the `user_data_file` configuration option provided by the builder
@@ -478,8 +472,8 @@ actually spinning up the instance, so that later on, our instance is
 configured to allow Packer to connect in to it.
 
 The `"provisioners"` section of the template demonstrates use of the
-[powershell](/docs/provisioners/powershell.html) and
+[powershell](/docs/provisioners/powershell) and
-[windows-restart](/docs/provisioners/windows-restart.html) provisioners to
+[windows-restart](/docs/provisioners/windows-restart) provisioners to
 customize and control the build process:
 
 ```json
@@ -555,7 +549,7 @@ Finally, we can create our new AMI by running `packer build firstrun.json`
 
 You should see output like this:
 
-```
+```shell
 amazon-ebs output will be in this color.
 
 ==> amazon-ebs: Prevalidating AMI Name: packer-demo-1518111383
@@ -626,18 +620,18 @@ set the value for the name field within `source_ami_filter` as required:
 For Windows 2008 SP2:
 
 ```
-          "name": "*Windows_Server-2008-SP2*English-64Bit-Base*",
+"name": "*Windows_Server-2008-SP2*English-64Bit-Base*",
 ```
 
 For Windows 2016:
 
 ```
-          "name": "*Windows_Server-2016-English-Full-Base*",
+"name": "*Windows_Server-2016-English-Full-Base*",
 ```
 
 The bootstrapping and sample provisioning should work the same across all
 Windows server versions.
 
-[Continue to provisioning an image](./provision.html)
+[Continue to provisioning an image &raquo;](/intro/getting-started/provision)
 
-[platforms]: /docs/builders/index.html
+[platforms]: /docs/builders

website/pages/intro/getting-started/index.mdx

@@ -2,6 +2,7 @@
 layout: intro
 sidebar_current: intro-getting-started-install
 page_title: Install Packer - Getting Started
+sidebar_title: 'Getting Started'
 description: >-
   Packer must first be installed on the machine you want to run it on. To make
 
@@ -30,7 +31,7 @@ Packer may be installed in the following ways:
 
 ## Precompiled Binaries
 
-To install the precompiled binary, [download](/downloads.html) the appropriate
+To install the precompiled binary, [download](/downloads) the appropriate
 package for your system. Packer is currently packaged as a zip file. We do not
 have any near term plans to provide system packages.
 
@@ -131,4 +132,4 @@ To fix this, you can create a symlink to packer that uses a different name like
 `packer.io`, or invoke the `packer` binary you want using its absolute path,
 e.g. `/usr/local/packer`.
 
-[Continue to building an image](./build-image.html)
+[Continue to building an image »](/intro/getting-started/build-image)

website/pages/intro/getting-started/next.mdx

@@ -2,6 +2,7 @@
 layout: intro
 sidebar_current: intro-getting-started-next
 page_title: Next Steps - Getting Started
+sidebar_title: 'Next Steps'
 description: |-
   That concludes the getting started guide for Packer. You should now be
   comfortable with basic Packer usage, should understand templates, defining
@@ -17,10 +18,10 @@ builds, provisioners, etc. At this point you're ready to begin playing with and
 using Packer in real scenarios.
 
 From this point forward, the most important reference for you will be the
-[documentation](/docs/index.html). The documentation is less of a guide and more of a
+[documentation](/docs). The documentation is less of a guide and more of a
 reference of all the overall features and options of Packer.
 
 As you use Packer more, please voice your comments and concerns on the [mailing
-list or IRC](/community.html). Additionally, Packer is [open
+list or IRC](/community). Additionally, Packer is [open
 source](https://github.com/hashicorp/packer) so please contribute if you'd like
 to. Contributions are very welcome.

website/pages/intro/getting-started/parallel-builds.mdx

@@ -2,6 +2,7 @@
 layout: intro
 sidebar_current: intro-getting-started-parallel-builds
 page_title: Parallel Builds - Getting Started
+sidebar_title: 'Parallel Builds'
 description: |-
   So far we've shown how Packer can automatically build an image and provision
   it. This on its own is already quite powerful. But Packer can do better than
@@ -178,4 +179,4 @@ At the end of the build, Packer outputs both of the artifacts created (an AMI
 and a DigitalOcean snapshot). Both images created are bare bones Ubuntu
 installations with Redis pre-installed.
 
-[Continue to Vagrant boxes](./vagrant.html)
+[Continue to Vagrant boxes »](/intro/getting-started/vagrant)

website/pages/intro/getting-started/provision.mdx

@@ -2,6 +2,7 @@
 layout: intro
 sidebar_current: intro-getting-started-provision
 page_title: Provision - Getting Started
+sidebar_title: 'Provision'
 description: |-
   In the previous page of this guide, you created your first image with Packer.
   The image you just built, however, was basically just a repackaging of a
@@ -104,4 +105,4 @@ pre-installed. Additionally, since everything is pre-installed, you can test the
 images as they're built and know that when they go into production, they'll be
 functional.
 
-[Continue to parallel builds](./parallel-builds.html)
+[Continue to parallel builds »](/intro/getting-started/parallel-builds)

website/pages/intro/getting-started/vagrant.mdx

@@ -2,6 +2,7 @@
 layout: intro
 sidebar_current: intro-getting-started-vagrant
 page_title: Vagrant Boxes - Getting Started
+sidebar_title: 'Vagrant Boxes'
 description: |-
   Packer also has the ability to take the results of a builder (such as an AMI
   or plain VMware image) and turn it into a Vagrant box.
@@ -12,7 +13,7 @@ description: |-
 Packer also has the ability to take the results of a builder (such as an AMI or
 plain VMware image) and turn it into a [Vagrant](https://www.vagrantup.com) box.
 
-This is done using [post-processors](/docs/templates/post-processors.html).
+This is done using [post-processors](/docs/templates/post-processors).
 These take an artifact created by a previous builder or post-processor and
 transforms it into a new one. In the case of the Vagrant post-processor, it
 takes an artifact from a builder and transforms it into a Vagrant box file.
@@ -44,9 +45,9 @@ Your template should look like the following:
 
 In this case, we're enabling a single post-processor named "vagrant". This
 post-processor is built-in to Packer and will create Vagrant boxes. You can
-always create [new post-processors](/docs/extending/custom-post-processors.html), however.
+always create [new post-processors](/docs/extending/custom-post-processors), however.
 The details on configuring post-processors is covered in the
-[post-processors](/docs/templates/post-processors.html) documentation.
+[post-processors](/docs/templates/post-processors) documentation.
 
 Validate the configuration using `packer validate`.
 
@@ -77,4 +78,4 @@ image, if you turn it into a Vagrant box, the files of the VMware image will be
 deleted since they were compressed into the Vagrant box. With creating AWS
 images, however, the AMI is kept around, since Vagrant needs it to function.
 
-[Continue to Next Steps](./next.html)
+[Continue to Next Steps »](/intro/getting-started/next)

website/pages/intro/use-cases.mdx

@@ -2,6 +2,7 @@
 layout: intro
 sidebar_current: intro-use-cases
 page_title: Use Cases - Introduction
+sidebar_title: 'Use Cases'
 description: |-
   By now you should know what Packer does and what the benefits of image
   creation are. In this section, we'll enumerate *some* of the use cases for

website/pages/intro/why.mdx

@@ -2,6 +2,7 @@
 layout: intro
 sidebar_current: intro-why
 page_title: Why Packer - Introduction
+sidebar_title: 'Why Use Packer?'
 description: |-
   Pre-baked machine images have a lot of advantages, but most have been unable
   to benefit from them because images have been too tedious to create and

website/scripts/changelog.md

@@ -0,0 +1 @@
+- `/intro/getting-started/install` redirects to `/intro/getting-started`