Add link checker and fix existing links

Signed-off-by: lucperkins <lucperkins@gmail.com>

.gitignore

@@ -2,3 +2,7 @@ node_modules/
 public/
 resources/
 !content/en/docs/resources
+
+# Link checker
+bin/
+tmp/

.htmltest.external.yml

@@ -0,0 +1,3 @@
+DirectoryPath: public
+IgnoreDirectoryMissingTrailingSlash: true
+IgnoreAltMissing: true

.htmltest.yml

@@ -0,0 +1,4 @@
+DirectoryPath: public/docs
+IgnoreDirectoryMissingTrailingSlash: true
+CheckExternal: false
+IgnoreAltMissing: true

Makefile

@@ -17,3 +17,20 @@ serve:
 	--ignoreCache \
 	--disableFastRender \
 	--verbose
+
+clean:
+	rm -rf public
+
+build:
+	hugo
+
+link-checker-setup:
+	curl https://raw.githubusercontent.com/wjdp/htmltest/master/godownloader.sh | bash
+
+run-link-checker:
+	bin/htmltest
+
+check-internal-links: clean build link-checker-setup run-link-checker
+
+check-all-links: clean build link-checker-setup
+	bin/htmltest --conf .htmltest.external.yml

assets/sass/style.sass

@@ -2,8 +2,8 @@
 {{ $fontAwesomeUrl     := printf "https://use.fontawesome.com/releases/v%s/css/all.css" $fontAwesomeVersion }}
 @charset "utf-8"
 
-@import url({{ $fontAwesomeUrl }})
-@import url(https://fonts.googleapis.com/css?family=Open+Sans:300,400,600,700)
+@import url("{{ $fontAwesomeUrl }}")
+@import url("https://fonts.googleapis.com/css?family=Open+Sans:300,400,600,700")
 
 // Vitess colors
 $vitess-orange: #f16626

content/en/docs/concepts/keyspace-id.md

@@ -2,9 +2,9 @@
 title: Keyspace ID
 ---
 
-The *keyspace ID* is the value that is used to decide on which shard a given row lives. [Range-based Sharding](../../sharding/#key-ranges-and-partitions) refers to creating shards that each cover a particular range of keyspace IDs.
+The *keyspace ID* is the value that is used to decide on which shard a given row lives. [Range-based Sharding](../../reference/sharding#key-ranges-and-partitions) refers to creating shards that each cover a particular range of keyspace IDs.
 
 Using this technique means you can split a given shard by replacing it with two or more new shards that combine to cover the original range of keyspace IDs, without having to move any records in other shards.
 
-The keyspace ID itself is computed using a function of some column in your data, such as the user ID. Vitess allows you to choose from a variety of functions ([vindexes](../../schema-management/vschema/)) to perform this mapping. This allows you to choose the right one to achieve optimal distribution of the data across shards.
+The keyspace ID itself is computed using a function of some column in your data, such as the user ID. Vitess allows you to choose from a variety of functions ([vindexes](../../reference/vschema)) to perform this mapping. This allows you to choose the right one to achieve optimal distribution of the data across shards.
 

content/en/docs/concepts/shard.md

@@ -10,7 +10,7 @@ An unsharded keyspace has effectively one shard. Vitess names the shard `0` by c
 
 ## Resharding
 
-Vitess supports [dynamic resharding](../../sharding/#resharding), in which the number of shards is changed on a live cluster. This can be either splitting one or more shards into smaller pieces, or merging neighboring shards into bigger pieces.
+Vitess supports [dynamic resharding](../../reference/sharding#resharding), in which the number of shards is changed on a live cluster. This can be either splitting one or more shards into smaller pieces, or merging neighboring shards into bigger pieces.
 
 During dynamic resharding, the data in the source shards is copied into the destination shards, allowed to catch up on replication, and then compared against the original to ensure data integrity. Then the live serving infrastructure is shifted to the destination shards, and the source shards are deleted.
 

content/en/docs/concepts/vschema.md

@@ -2,9 +2,9 @@
 title: VSchema
 ---
 
-A [VSchema](../../schema-management/vschema/) allows you to describe how data is organized within keyspaces and shards. This information is used for routing queries, and also during resharding operations.
+A [VSchema](../../reference/vschema) allows you to describe how data is organized within keyspaces and shards. This information is used for routing queries, and also during resharding operations.
 
 For a Keyspace, you can specify if it's sharded or not. For sharded keyspaces, you can specify the list of vindexes for each table.
 
-Vitess also supports [sequence generators](../../schema-management/vschema/#sequences) that can be used to generate new ids that work like MySQL auto increment columns. The VSchema allows you to associate table columns to sequence tables. If no value is specified for such a column, then VTGate will know to use the sequence table to generate a new value for it.
+Vitess also supports [sequence generators](../../reference/vschema#sequences) that can be used to generate new ids that work like MySQL auto increment columns. The VSchema allows you to associate table columns to sequence tables. If no value is specified for such a column, then VTGate will know to use the sequence table to generate a new value for it.
 

content/en/docs/get-started/_index.md

@@ -5,4 +5,4 @@ weight: 2
 aliases: ['/docs/tutorials/']
 ---
 
-Vitess supports binary deployment on the following platforms. See also [Build From Source](../../contributing/build-from-source) if you are interesting in building your own binary, or contributing to Vitess.
+Vitess supports binary deployment on the following platforms. See also [Build On CentOS](../contributing/build-on-centos), [Build on MacOS](../contributing/build-on-macos), or [Build on Ubuntu](../contributing/build-on-ubuntu) if you are interesting in building your own binary, or contributing to Vitess.

content/en/docs/reference/mysql-compatibility.md

@@ -16,7 +16,7 @@ The following describes some of the major differences in SQL Syntax handling bet
 
 ### DDL                                                                      
                                                                             
-Vitess supports MySQL DDL, and will send `ALTER TABLE` statements to each of the underlying tablet servers. For large tables it is recommended to use an external schema deployment tool and apply directly to the underlying MySQL shard instances. This is discussed further in [Applying MySQL Schema](../user-guides/making-schema-changes/).
+Vitess supports MySQL DDL, and will send `ALTER TABLE` statements to each of the underlying tablet servers. For large tables it is recommended to use an external schema deployment tool and apply directly to the underlying MySQL shard instances. This is discussed further in [Applying MySQL Schema](../../user-guides/making-schema-changes).
 
 ### Join Queries
 

content/en/docs/reference/schema-management.md

@@ -92,7 +92,7 @@ The [ApplySchema](../../reference/vtctl/#applyvschema) command applies a schema
 
 When the `ApplySchema` action actually applies a schema change to the specified keyspace, it performs the following steps:
 
-1. It finds shards that belong to the keyspace, including newly added shards if a [resharding event](../../sharding/#resharding) has taken place.
+1. It finds shards that belong to the keyspace, including newly added shards if a [resharding event](../sharding/#resharding) has taken place.
 2. It validates the SQL syntax and determines the impact of the schema change. If the scope of the change is too large, Vitess rejects it. See the [permitted schema changes](#permitted-schema-changes) section for more detail.
 3. It employs a pre-flight check to ensure that a schema update will succeed before the change is actually applied to the live database. In this stage, Vitess copies the current schema into a temporary database, applies the change there to validate it, and retrieves the resulting schema. By doing so, Vitess verifies that the change succeeds without actually touching live database tables.
 4. It applies the SQL command on the master tablet in each shard.

content/en/docs/troubleshoot/_index.md

@@ -30,12 +30,12 @@ Diagnosis 4: No particular transaction seems to be the culprit. Nothing seems to
 
 ## Master starts up read-only
 
-To prevent accidentally accepting writes, our default my.cnf settings tell MySQL to always start up read-only. If the master MySQL gets restarted, it will thus come back read-only until you intervene to confirm that it should accept writes. You can use the [`SetReadWrite`](../../reference/vtctl/#setreadwrite) command to do that.
+To prevent accidentally accepting writes, our default my.cnf settings tell MySQL to always start up read-only. If the master MySQL gets restarted, it will thus come back read-only until you intervene to confirm that it should accept writes. You can use the [`SetReadWrite`](../reference/vtctl/#setreadwrite) command to do that.
 
-However, usually if something unexpected happens to the master, it's better to reparent to a different replica with [`EmergencyReparentShard`](../../reference/vtctl/#emergencyreparentshard). If you need to do planned maintenance on the master, it's best to first reparent to another replica with [`PlannedReparentShard`](../../reference/vtctl/#plannedreparentshard).
+However, usually if something unexpected happens to the master, it's better to reparent to a different replica with [`EmergencyReparentShard`](../reference/vtctl/#emergencyreparentshard). If you need to do planned maintenance on the master, it's best to first reparent to another replica with [`PlannedReparentShard`](../reference/vtctl/#plannedreparentshard).
 
 ## Vitess sees the wrong tablet as master
 
-If you do a failover manually (not through Vitess), you'll need to tell Vitess which tablet corresponds to the new master MySQL. Until then, writes will fail since they'll be routed to a read-only replica (the old master). Use the [`TabletExternallyReparented`](../../reference/vtctl/#tabletexternallyreparented) command to tell Vitess the new master tablet for a shard.
+If you do a failover manually (not through Vitess), you'll need to tell Vitess which tablet corresponds to the new master MySQL. Until then, writes will fail since they'll be routed to a read-only replica (the old master). Use the [`TabletExternallyReparented`](../reference/vtctl/#tabletexternallyreparented) command to tell Vitess the new master tablet for a shard.
 
 Tools like [Orchestrator](https://github.com/github/orchestrator) can be configured to call this automatically when a failover occurs. See our sample [orchestrator.conf.json](https://github.com/vitessio/vitess/blob/1129d69282bb738c94b8af661b984b6377a759f7/docker/orchestrator/orchestrator.conf.json#L131) for an example of this.

content/en/docs/user-guides/configuring-components.md

@@ -6,9 +6,9 @@ aliases: ['/docs/launching/server-configuration/', '/docs/user-guides/server-con
 
 ## Managed MySQL
 
-The following describes the requirements for Vitess when fully managing MySQL with `mysqlctl` (see [VTTablet Modes](../vttablet-modes#managed-mysql)).
+The following describes the requirements for Vitess when fully managing MySQL with `mysqlctl` (see [VTTablet Modes](../../reference/vttablet-modes#managed-mysql)).
 
-When using [Unmanaged or Remote MySQL](../vttablet-modes#unmanaged-or-remote-mysql) instead, the requirement is only that the server speak the MySQL protocol.
+When using [Unmanaged or Remote MySQL](../../reference/vttablet-modes#unmanaged-or-remote-mysql) instead, the requirement is only that the server speak the MySQL protocol.
 
 ### Version and Flavor
 

content/en/docs/user-guides/production-planning.md

@@ -48,8 +48,8 @@ Before running Vitess in production, you should become comfortable with the diff
 
 Here is a short list of all the basic workflows Vitess supports:
 
-* [Reparenting](../../user-guides/reparenting)
-* [Backup/Restore](../../user-guides/backup-and-restore)
+* [Reparenting](../reparenting)
+* [Backup/Restore](../backup-and-restore)
 * [Schema Management](../../schema-management)
-* [Resharding](../../reference/sharding#resharding) / [Horizontal Sharding Tutorial](../../user-guides/horizonal-sharding)
-* [Upgrading](../../user-guides/upgrading)
+* [Resharding](../../reference/sharding#resharding) / [Horizontal Sharding Tutorial](../horizontal-sharding)
+* [Upgrading](../upgrading)

content/en/docs/user-guides/vtexplain.md

@@ -4,7 +4,7 @@ title: Explaining how Vitess executes a SQL statement
 
 # Introduction 
 
-This document explains how to learn more about the way Vitess executes a particular SQL statement using the [VTexplain tool](../reference/vtexplain). This tool works similarly to the MySQL `EXPLAIN` statement.
+This document explains how to learn more about the way Vitess executes a particular SQL statement using the [VTexplain tool](../../reference/vtexplain). This tool works similarly to the MySQL `EXPLAIN` statement.
 
 ## Prerequisites
 

content/zh/community.md

@@ -23,7 +23,7 @@ On the third Thursday of the month (unless otherwise specified), the Vitess comm
 To join by phone: 
 
 * US: +16699006833,,314170129#  or +16465588656,,314170129#
-* International dial-in numbers [click here](../dialin)
+* International dial-in numbers [click here](/dialin)
 * Meeting ID (required to join the call): 314 170 129
 
 If you would like to submit a topic for discussion at the meeting, please [email us](mailto:cncf-vitess-maintainers@lists.cncf.io). 

content/zh/docs/get-started/_index.md

@@ -4,4 +4,4 @@ description: 在你最喜爱的平台上部署Vitess
 weight: 2
 ---
 
-Vitess支持在以上平台上进行二进制部署。 如果你对如何构建二进制文件很感兴趣，或者想对vitess做贡献。可以参考[从源码编译](../../contributing/build-from-source)。
+Vitess支持在以上平台上进行二进制部署。 如果你对如何构建二进制文件很感兴趣，或者想对vitess做贡献。可以参考[从源码编译](../contributing/build-from-source)。

content/zh/docs/reference/row-based-replication.md

@@ -63,7 +63,7 @@ Note if the main use case is Filtered Replication for resharding, this limitatio
 
 ### Applying Schema Changes
 
-When using RBR, [Schema Swap](../../schema-management/schema-swap) becomes useless, as replication between hosts with different schemas will most likely break. This is however an existing limitation that is already known and handled by MySQL DBAs.
+When using RBR, [Schema Swap](../vitess-replication#vitess-schema-swap) becomes useless, as replication between hosts with different schemas will most likely break. This is however an existing limitation that is already known and handled by MySQL DBAs.
 
 Vitess at this point does not provide an integrated way of applying involved schema changes through RBR. A number of external tools however already exist to handle this case, like gh-ost.
 

content/zh/docs/reference/sharding.md

@@ -103,6 +103,6 @@ will always contain the full primary key of its affected row.
 
 Vitess provides the following tools to help manage range-based shards:
 
-* The [vtctl](../reference/vtctl) command-line tool supports functions for managing keyspaces, shards, tablets, and more.
+* The [vtctl](../vtctl) command-line tool supports functions for managing keyspaces, shards, tablets, and more.
 * Client APIs account for sharding operations.
 * The [MapReduce framework](https://github.com/vitessio/vitess/tree/master/java/hadoop/src/main/java/io/vitess/hadoop) fully utilizes key ranges to read data as quickly as possible, concurrently from all shards and all replicas.

content/zh/docs/reference/vitess-replication.md

@@ -36,7 +36,7 @@ Also, Vitess adds comments to the rewritten statements that identify the primary
 
 ## Vitess Schema Swap
 
-Within YouTube, we also use a combination of statement based replication and backups to apply long-running schema changes without disrupting ongoing operations. See the [schema swap](../../schema-management/schema-swap) tutorial for a detailed example.
+Within YouTube, we also use a combination of statement based replication and backups to apply long-running schema changes without disrupting ongoing operations. See the [schema swap](../schema-management/schema-swap) tutorial for a detailed example.
 
 This operation, which is called **schema swap**, works as follows:
 

layouts/partials/meta.html

@@ -36,6 +36,6 @@
 <meta name="twitter:site" content="@{{ $twitterHandle }}">
 <meta name="twitter:creator" content="@{{ $twitterHandle }}">
 
-<link rel="canonical" content="{{ .Permalink }}">
+<link rel="canonical" href="{{ .Permalink }}">
 <link rel="shortcut icon" href="{{ $favicon }}" type="image/png">
 {{ hugo.Generator }}

netlify.toml

@@ -3,7 +3,7 @@ publish = "public"
 command = "make production-build"
 
 [build.environment]
-HUGO_VERSION = "0.55.6"
+HUGO_VERSION = "0.65.3"
 
 [context.deploy-preview]
 command = "make preview-build"