Merge pull request etcd-io#64 from lucperkins/lperkins/link-checker

Add link checker

.gitignore

@@ -4,3 +4,7 @@ node_modules/
 # Hugo-generated assets
 public/
 resources/
+
+# Link checker artifacts
+bin/
+tmp/

.htmltest.yml

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

Makefile

@@ -21,3 +21,14 @@ preview-build:
 		--buildDrafts \
 		--buildFuture \
 		--minify
+
+clean:
+	rm -rf public
+
+link-checker-setup:
+	curl https://htmltest.wjdp.uk | bash
+
+run-link-checker:
+	bin/htmltest
+
+check-links: clean production-build link-checker-setup run-link-checker

config.toml

@@ -8,7 +8,8 @@ enableRobotsTxt = true
 ignoreFiles = [
   "content/docs/v*/README.md",
   "content/docs/v*/*/README.md",
-  "content/docs/v*/docs.md"
+  "content/docs/v*/docs.md",
+  "content/docs/v3.4.0/etcd-mixin",
 ]
 
 [params]
@@ -35,6 +36,9 @@ etcd is written in [Go](https://golang.org), which has excellent cross-platform
 Latency from the etcd leader is the most important metric to track and the built-in dashboard has a view dedicated to this. In our testing, severe latency will introduce instability within the cluster because Raft is only as fast as the slowest machine in the majority. You can mitigate this issue by properly tuning the cluster. etcd has been pre-tuned on cloud providers with highly variable networks.
 """
 
+[markup.goldmark.renderer]
+unsafe = true
+
 [params.versions]
 latest = "3.4.0"
 all    = ["3.4.0", "3.3.13", "3.3.12", "3.2.17", "3.1.12", "2"]

content/docs/v3.3.12/benchmarks/etcd-2-2-0-benchmarks.md

@@ -26,7 +26,7 @@ Go OS/Arch: linux/amd64
 
 ## Testing
 
-Bootstrap another machine, outside of the etcd cluster, and run the [`hey` HTTP benchmark tool](https://github.com/rakyll/hey) with a connection reuse patch to send requests to each etcd cluster member. See the [benchmark instructions](../../hack/benchmark/) for the patch and the steps to reproduce our procedures.
+Bootstrap another machine, outside of the etcd cluster, and run the [`hey` HTTP benchmark tool](https://github.com/rakyll/hey) with a connection reuse patch to send requests to each etcd cluster member. See the [benchmark instructions](https://github.com/etcd-io/etcd/tree/master/hack/benchmark) for the patch and the steps to reproduce our procedures.
 
 The performance is calculated through results of 100 benchmark rounds.
 

content/docs/v3.3.12/benchmarks/etcd-2-2-0-rc-benchmarks.md

@@ -73,4 +73,4 @@ Bootstrap another machine and use the [hey HTTP benchmark tool][hey] to send req
 [hey]: https://github.com/rakyll/hey
 [c7146bd5]: https://github.com/coreos/etcd/commits/c7146bd5f2c73716091262edc638401bb8229144
 [etcd-2.1-benchmark]: etcd-2-1-0-alpha-benchmarks.md
-[hack-benchmark]: ../../hack/benchmark/
+[hack-benchmark]: https://github.com/etcd-io/etcd/tree/master/hack/benchmark

content/docs/v3.3.12/benchmarks/etcd-3-demo-benchmarks.md

@@ -43,4 +43,4 @@ The performance is nearly the same as the one with empty server handler.
 The performance with empty server handler is not affected by one put. So the
 performance downgrade should be caused by storage package.
 
-[etcd-v3-benchmark]: ../../tools/benchmark/
+[etcd-v3-benchmark]: https://github.com/etcd-io/etcd/tree/master/tools/benchmark

content/docs/v3.3.12/dev-guide/api_grpc_gateway.md

@@ -134,4 +134,4 @@ Generated [Swagger][swagger] API definitions can be found at [rpc.swagger.json][
 [grpc-gateway]: https://github.com/grpc-ecosystem/grpc-gateway
 [json-mapping]: https://developers.google.com/protocol-buffers/docs/proto3#json
 [swagger]: http://swagger.io/
-[swagger-doc]: apispec/swagger/rpc.swagger.json
+[swagger-doc]: /apispec/swagger/rpc.swagger.json

content/docs/v3.3.12/op-guide/clustering.md

@@ -494,5 +494,5 @@ To setup an etcd cluster with proxies of v2 API, please read the the [clustering
 [clustering_etcd2]: https://github.com/coreos/etcd/blob/release-2.3/Documentation/clustering.md
 [security-guide]: security.md
 [security-guide-dns-srv]: security.md#notes-for-dns-srv
-[tls-setup]: ../../hack/tls-setup
+[tls-setup]: https://github.com/etcd-io/etcd/tree/master/hack/tls-setup
 [gateway]: gateway.md

content/docs/v3.3.12/op-guide/configuration.md

@@ -424,10 +424,10 @@ Follow the instructions when using these flags.
 [reconfig]: runtime-configuration.md
 [discovery]: clustering.md#discovery
 [iana-ports]: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
-[proxy]: ../v2/proxy.md
-[restore]: ../v2/admin_guide.md#restoring-a-backup
+[proxy]: /docs/v2/proxy.md
+[restore]: /docs/v2/admin_guide.md#restoring-a-backup
 [security]: security.md
 [systemd-intro]: http://freedesktop.org/wiki/Software/systemd/
 [tuning]: ../tuning.md#time-parameters
 [sample-config-file]: ../../etcd.conf.yml.sample
-[recovery]: recovery.md#disaster-recovery
+[recovery]: recovery.md

content/docs/v3.3.12/op-guide/recovery.md

@@ -6,7 +6,7 @@ etcd is designed to withstand machine failures. An etcd cluster automatically re
 
 To recover from disastrous failure, etcd v3 provides snapshot and restore facilities to recreate the cluster without v3 key data loss. To recover v2 keys, refer to the [v2 admin guide][v2_recover].
 
-[v2_recover]: ../v2/admin_guide.md#disaster-recovery
+[v2_recover]: /docs/v2/admin_guide.md#disaster-recovery
 
 ## Snapshotting the keyspace
 

content/docs/v3.3.12/op-guide/security.md

@@ -427,7 +427,7 @@ Make sure to sign the certificates with a Subject Name the member's public IP ad
 The certificate needs to be signed for the member's FQDN in its Subject Name, use Subject Alternative Names (short IP SANs) to add the IP address. The `etcd-ca` tool provides `--domain=` option for its `new-cert` command, and openssl can make [it][alt-name] too.
 
 [cfssl]: https://github.com/cloudflare/cfssl
-[tls-setup]: ../../hack/tls-setup
+[tls-setup]: https://github.com/etcd-io/etcd/tree/master/hack/tls-setup
 [tls-guide]: https://github.com/coreos/docs/blob/master/os/generate-self-signed-certificates.md
 [alt-name]: http://wiki.cacert.org/FAQ/subjectAltName
 [auth]: authentication.md

content/docs/v3.3.12/op-guide/v2-migration.md

@@ -56,4 +56,4 @@ After finishing data migration, the background job writes `true` into the switch
 
 Online migration can be difficult when the application logic depends on store v2 indexes. Applications will need additional logic to convert mvcc store revisions to store v2 indexes.
 
-[migrate_command]: ../../etcdctl/README.md#migrate-options
+[migrate_command]: https://github.com/etcd-io/etcd/tree/master/etcdctl#migrate-options

content/docs/v3.3.12/upgrades/upgrade_3_0.md

@@ -22,7 +22,7 @@ Also, to ensure a smooth rolling upgrade, the running cluster must be healthy. C
 
 Before upgrading etcd, always test the services relying on etcd in a staging environment before deploying the upgrade to the production environment.
 
-Before beginning, [backup the etcd data directory](../v2/admin_guide.md#backing-up-the-datastore). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version.
+Before beginning, [backup the etcd data directory](/docs/v2/admin_guide.md#backing-up-the-datastore). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version.
 
 #### Mixed versions
 
@@ -38,7 +38,7 @@ For a much larger total data size, 100MB or more , this one-time process might t
 
 If all members have been upgraded to v3.0, the cluster will be upgraded to v3.0, and downgrade from this completed state is **not possible**. If any single member is still v2.3, however, the cluster and its operations remains “v2.3”, and it is possible from this mixed cluster state to return to using a v2.3 etcd binary on all members.
 
-Please [backup the data directory](../v2/admin_guide.md#backing-up-the-datastore) of all etcd members to make downgrading the cluster possible even after it has been completely upgraded.
+Please [backup the data directory](/docs/v2/admin_guide.md#backing-up-the-datastore) of all etcd members to make downgrading the cluster possible even after it has been completely upgraded.
 
 ### Upgrade procedure
 
@@ -68,7 +68,7 @@ When each etcd process is stopped, expected errors will be logged by other clust
 2016-06-27 15:21:48.624175 I | rafthttp: the connection with 8211f1d0f64f3269 became inactive
 ```
 
-It’s a good idea at this point to [backup the etcd data directory](../v2/admin_guide.md#backing-up-the-datastore) to provide a downgrade path should any problems occur:
+It’s a good idea at this point to [backup the etcd data directory](/docs/v2/admin_guide.md#backing-up-the-datastore) to provide a downgrade path should any problems occur:
 
 ```
 $ etcdctl backup \

content/docs/v3.3.12/upgrades/upgrade_3_1.md

@@ -31,7 +31,7 @@ Also, to ensure a smooth rolling upgrade, the running cluster must be healthy. C
 
 Before upgrading etcd, always test the services relying on etcd in a staging environment before deploying the upgrade to the production environment.
 
-Before beginning, [backup the etcd data](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](../v2/admin_guide.md#backing-up-the-datastore).
+Before beginning, [backup the etcd data](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](/docs/v2/admin_guide.md#backing-up-the-datastore).
 
 #### Mixed versions
 

content/docs/v3.3.12/upgrades/upgrade_3_2.md

@@ -228,7 +228,7 @@ Also, to ensure a smooth rolling upgrade, the running cluster must be healthy. C
 
 Before upgrading etcd, always test the services relying on etcd in a staging environment before deploying the upgrade to the production environment.
 
-Before beginning, [backup the etcd data](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](../v2/admin_guide.md#backing-up-the-datastore).
+Before beginning, [backup the etcd data](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](/docs/v2/admin_guide.md#backing-up-the-datastore).
 
 #### Mixed versions
 

content/docs/v3.3.12/upgrades/upgrade_3_3.md

@@ -381,7 +381,7 @@ Also, to ensure a smooth rolling upgrade, the running cluster must be healthy. C
 
 Before upgrading etcd, always test the services relying on etcd in a staging environment before deploying the upgrade to the production environment.
 
-Before beginning, [backup the etcd data](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](../v2/admin_guide.md#backing-up-the-datastore).
+Before beginning, [backup the etcd data](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](/docs/v2/admin_guide.md#backing-up-the-datastore).
 
 #### Mixed versions
 
@@ -492,4 +492,4 @@ localhost:22379 is healthy: successfully committed proposal: took = 2.553476ms
 localhost:32379 is healthy: successfully committed proposal: took = 2.517902ms
 ```
 
-[etcd-contact]: https://groups.google.com/forum/#!forum/etcd-dev
+[etcd-contact]: https://groups.google.com/forum/#!forum/etcd-dev

content/docs/v3.3.12/upgrades/upgrade_3_4.md

@@ -230,7 +230,7 @@ Also, to ensure a smooth rolling upgrade, the running cluster must be healthy. C
 
 Before upgrading etcd, always test the services relying on etcd in a staging environment before deploying the upgrade to the production environment.
 
-Before beginning, [download the snapshot backup](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](../v2/admin_guide.md#backing-up-the-datastore).
+Before beginning, [download the snapshot backup](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](/docs/v2/admin_guide.md#backing-up-the-datastore).
 
 #### Mixed versions
 

content/docs/v3.3.12/upgrades/upgrade_3_5.md

@@ -106,7 +106,7 @@ Also, to ensure a smooth rolling upgrade, the running cluster must be healthy. C
 
 Before upgrading etcd, always test the services relying on etcd in a staging environment before deploying the upgrade to the production environment.
 
-Before beginning, [download the snapshot backup](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](../v2/admin_guide.md#backing-up-the-datastore).
+Before beginning, [download the snapshot backup](../op-guide/maintenance.md#snapshot-backup). Should something go wrong with the upgrade, it is possible to use this backup to [downgrade](#downgrade) back to existing etcd version. Please note that the `snapshot` command only backs up the v3 data. For v2 data, see [backing up v2 datastore](/docs/v2/admin_guide.md#backing-up-the-datastore).
 
 #### Mixed versions
 

content/docs/v3.4.0/benchmarks/etcd-2-2-0-benchmarks.md

@@ -26,7 +26,7 @@ Go OS/Arch: linux/amd64
 
 ## Testing
 
-Bootstrap another machine, outside of the etcd cluster, and run the [`hey` HTTP benchmark tool](https://github.com/rakyll/hey) with a connection reuse patch to send requests to each etcd cluster member. See the [benchmark instructions](../../hack/benchmark/) for the patch and the steps to reproduce our procedures.
+Bootstrap another machine, outside of the etcd cluster, and run the [`hey` HTTP benchmark tool](https://github.com/rakyll/hey) with a connection reuse patch to send requests to each etcd cluster member. See the [benchmark instructions](https://github.com/etcd-io/etcd/tree/master/hack/benchmark) for the patch and the steps to reproduce our procedures.
 
 The performance is calculated through results of 100 benchmark rounds.
 

content/docs/v3.4.0/benchmarks/etcd-2-2-0-rc-benchmarks.md

@@ -73,4 +73,4 @@ Bootstrap another machine and use the [hey HTTP benchmark tool][hey] to send req
 [hey]: https://github.com/rakyll/hey
 [c7146bd5]: https://github.com/coreos/etcd/commits/c7146bd5f2c73716091262edc638401bb8229144
 [etcd-2.1-benchmark]: etcd-2-1-0-alpha-benchmarks.md
-[hack-benchmark]: ../../hack/benchmark/
+[hack-benchmark]: https://github.com/etcd-io/etcd/tree/master/hack/benchmark

content/docs/v3.4.0/benchmarks/etcd-3-demo-benchmarks.md

@@ -43,4 +43,4 @@ The performance is nearly the same as the one with empty server handler.
 The performance with empty server handler is not affected by one put. So the
 performance downgrade should be caused by storage package.
 
-[etcd-v3-benchmark]: ../../tools/benchmark/
+[etcd-v3-benchmark]: https://github.com/etcd-io/etcd/tree/master/hack/benchmark

content/docs/v3.4.0/faq.md

@@ -160,6 +160,6 @@ etcd sends a snapshot of its complete key-value store to refresh slow followers
 [api-mvcc]: learning/api.md#revisions
 [maintenance-compact]:  op-guide/maintenance.md#history-compaction
 [maintenance-defragment]: op-guide/maintenance.md#defragmentation
-[maintenance-disarm]: ../etcdctl/README.md#alarm-disarm
+[maintenance-disarm]: https://github.com/etcd-io/etcd/tree/master/etcdctl#alarm-disarm
 [fio]: https://github.com/axboe/fio
 [fio-blog-post]: https://www.ibm.com/blogs/bluemix/2019/04/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcd/

content/docs/v3.4.0/integrations.md

@@ -147,7 +147,7 @@ title: Libraries and tools
 - [cloudfoundry/cf-release](https://github.com/cloudfoundry/cf-release/tree/master/jobs/etcd)
 
 **Projects using etcd**
-- [etcd Raft users](../raft/README.md#notable-users) - projects using etcd's raft library implementation.
+- [etcd Raft users](https://github.com/etcd-io/etcd/tree/master/raft#notable-users) - projects using etcd's raft library implementation.
 - [apache/celix](https://github.com/apache/celix) - an implementation of the OSGi specification adapted to C and C++
 - [binocarlos/yoda](https://github.com/binocarlos/yoda) - etcd + ZeroMQ
 - [blox/blox](https://github.com/blox/blox) - a collection of open source projects for container management and orchestration with AWS ECS

content/docs/v3.4.0/learning/api_guarantees.md

@@ -49,6 +49,6 @@ etcd does not ensure linearizability for watch operations. Users are expected to
 
 etcd ensures linearizability for all other operations by default. Linearizability comes with a cost, however, because linearized requests must go through the Raft consensus process. To obtain lower latencies and higher throughput for read requests, clients can configure a request’s consistency mode to `serializable`, which may access stale data with respect to quorum, but removes the performance penalty of linearized accesses' reliance on live consensus.
 
-[txn]: api.md#transactions
+[txn]: api.md#transaction
 [linearizability]: https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf
 [strict_serializability]: http://jepsen.io/consistency/models/strict-serializable