Fix broken links in documentation (#4746)

docs/deploy/baremetal.md

@@ -367,7 +367,7 @@ address of all nodes running the NGINX Ingress controller.
 [taints]: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
 [daemonset]: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
 [dnspolicy]: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy
-[cli-args]: ../../user-guide/cli-arguments/
+[cli-args]: ../user-guide/cli-arguments.md
 
 ## Using a self-provisioned edge
 

docs/development.md

@@ -20,7 +20,7 @@ cd ingress-nginx
 ### Initial developer environment build
 
 >**Prequisites**: Minikube must be installed.
-See [releases](https://github.com/kubernetes/minikube/releases) for installation instructions. 
+See [releases](https://github.com/kubernetes/minikube/releases) for installation instructions.
 
 If you are using **MacOS** and deploying to **minikube**, the following command will build the local nginx controller container image and deploy the ingress controller onto a minikube cluster with RBAC enabled in the namespace `ingress-nginx`:
 
@@ -55,8 +55,8 @@ Check the version of `dep` you are using and make sure it is up to date.
 $ dep version
 dep:
  version     : devel
- build date  : 
- git hash    : 
+ build date  :
+ git hash    :
  go version  : go1.9
  go compiler : gc
  platform    : linux/amd64
@@ -134,7 +134,7 @@ $ TAG=<tag> REGISTRY=$USER/ingress-controller make push
 ## Deploying
 
 There are several ways to deploy the ingress controller onto a cluster.
-Please check the [deployment guide](./deploy)
+Please check the [deployment guide](../deploy/)
 
 ## Testing
 
@@ -152,7 +152,7 @@ $ cd $GOPATH/src/k8s.io/ingress-nginx
 $ make e2e-test
 ```
 
-NOTE: if your e2e pod keeps hanging in an ImagePullBackoff, make sure you've made your e2e nginx-ingress-controller image available to minikube as explained in [Building the e2e test image](./Building the e2e test image)
+NOTE: if your e2e pod keeps hanging in an ImagePullBackoff, make sure you've made your e2e nginx-ingress-controller image available to minikube as explained in the **Building the e2e test image** section
 
 To run unit-tests for lua code locally, run:
 
@@ -162,7 +162,7 @@ $ ./rootfs/etc/nginx/lua/test/up.sh
 $ make lua-test
 ```
 
-Lua tests are located in `$GOPATH/src/k8s.io/ingress-nginx/rootfs/etc/nginx/lua/test`. When creating a new test file it must follow the naming convention `<mytest>_test.lua` or it will be ignored. 
+Lua tests are located in `$GOPATH/src/k8s.io/ingress-nginx/rootfs/etc/nginx/lua/test`. When creating a new test file it must follow the naming convention `<mytest>_test.lua` or it will be ignored.
 
 ## Releasing
 

docs/examples/affinity/cookie/README.md

@@ -30,12 +30,12 @@ You can confirm that the Ingress works:
 $ kubectl describe ing nginx-test
 Name:			nginx-test
 Namespace:		default
-Address:		
+Address:
 Default backend:	default-http-backend:80 (10.180.0.4:8080,10.240.0.2:8080)
 Rules:
   Host	                        Path	Backends
   ----	                        ----	--------
-  stickyingress.example.com     
+  stickyingress.example.com
                                 /   	 nginx-service:80 (<none>)
 Annotations:
   affinity:	cookie
@@ -46,7 +46,7 @@ Events:
   FirstSeen	LastSeen	Count	From				SubObjectPath	Type		Reason	Message
   ---------	--------	-----	----				-------------	--------	------	-------
   7s		7s		1	{nginx-ingress-controller }			Normal		CREATE	default/nginx-test
-  
+
 
 $ curl -I http://stickyingress.example.com
 HTTP/1.1 200 OK
@@ -69,8 +69,8 @@ If the backend pool grows NGINX will keep sending the requests through the same
 
 When the backend server is removed, the requests are re-routed to another upstream server. This does not require the cookie to be updated because the key's [consistent hash][consistent-hashing] will change.
 
-When you have a Service pointing to more than one Ingress, with only one containing affinity configuration, the first created Ingress will be used. 
+When you have a Service pointing to more than one Ingress, with only one containing affinity configuration, the first created Ingress will be used.
 This means that you can face the situation that you've configured session affinity on one Ingress and it doesn't work because the Service is pointing to another Ingress that doesn't configure this.
 
-[ingress-paths]: ../../../user-guide/ingress-path-matching
+[ingress-paths]: ../../../user-guide/ingress-path-matching.md
 [consistent-hashing]: https://en.wikipedia.org/wiki/Consistent_hashing

docs/examples/rewrite/README.md

@@ -6,7 +6,7 @@ This example demonstrates how to use the Rewrite annotations
 
 You will need to make sure your Ingress targets exactly one Ingress
 controller by specifying the [ingress.class annotation](../../user-guide/multiple-ingress.md),
-and that you have an ingress controller [running](../../deploy) in your cluster.
+and that you have an ingress controller [running](../../deploy/) in your cluster.
 
 ## Deployment
 
@@ -26,9 +26,9 @@ Rewriting can be controlled using the following annotations:
 
 !!! attention
     Starting in Version 0.22.0, ingress definitions using the annotation `nginx.ingress.kubernetes.io/rewrite-target` are not backwards compatible with previous versions. In Version 0.22.0 and beyond, any substrings within the request URI that need to be passed to the rewritten path must explicitly be defined in a [capture group](https://www.regular-expressions.info/refcapture.html).
-    
+
 !!! note
-    [Captured groups](https://www.regular-expressions.info/refcapture.html) are saved in numbered placeholders, chronologically, in the form `$1`, `$2` ... `$n`. These placeholders can be used as parameters in the `rewrite-target` annotation. 
+    [Captured groups](https://www.regular-expressions.info/refcapture.html) are saved in numbered placeholders, chronologically, in the form `$1`, `$2` ... `$n`. These placeholders can be used as parameters in the `rewrite-target` annotation.
 
 Create an Ingress rule with a rewrite annotation:
 
@@ -53,7 +53,7 @@ spec:
 ' | kubectl create -f -
 ```
 
-In this ingress definition, any characters captured by `(.*)` will be assigned to the placeholder `$2`, which is then used as a parameter in the `rewrite-target` annotation. 
+In this ingress definition, any characters captured by `(.*)` will be assigned to the placeholder `$2`, which is then used as a parameter in the `rewrite-target` annotation.
 
 For example, the ingress definition above will result in the following rewrites:
 - `rewrite.bar.com/something` rewrites to `rewrite.bar.com/`

docs/examples/static-ip/README.md

@@ -7,7 +7,7 @@ This example demonstrates how to assign a static-ip to an Ingress on through the
 You need a [TLS cert](../PREREQUISITES.md#tls-certificates) and a [test HTTP service](../PREREQUISITES.md#test-http-service) for this example.
 You will also need to make sure your Ingress targets exactly one Ingress
 controller by specifying the [ingress.class annotation](../../user-guide/multiple-ingress.md),
-and that you have an ingress controller [running](../../deploy) in your cluster.
+and that you have an ingress controller [running](../../deploy/) in your cluster.
 
 ## Acquiring an IP
 

docs/index.md

@@ -8,4 +8,4 @@ Learn more about using Ingress on [k8s.io](http://kubernetes.io/docs/user-guide/
 
 ## Getting Started
 
-See [Deployment](./deploy) for a whirlwind tour that will get you started.
+See [Deployment](./deploy/) for a whirlwind tour that will get you started.

docs/user-guide/custom-errors.md

@@ -28,4 +28,4 @@ See also the [Custom errors][example-custom-errors] example.
 
 [cm-custom-http-errors]: ./nginx-configuration/configmap.md#custom-http-errors
 [img-custom-error-pages]: https://github.com/kubernetes/ingress-nginx/tree/master/images/custom-error-pages
-[example-custom-errors]: ../examples/customization/custom-errors
+[example-custom-errors]: ../../examples/customization/custom-errors

docs/user-guide/tls.md

@@ -39,7 +39,7 @@ have a `secretName` option.
 
 ## SSL Passthrough
 
-The [`--enable-ssl-passthrough`](cli-arguments/) flag enables the SSL Passthrough feature, which is disabled by
+The [`--enable-ssl-passthrough`](cli-arguments.md) flag enables the SSL Passthrough feature, which is disabled by
 default. This is required to enable passthrough backends in Ingress objects.
 
 !!! warning

mkdocs.yml

@@ -11,10 +11,10 @@ markdown_extensions:
   - pymdownx.tasklist:
       custom_checkbox: true
   - pymdownx.superfences
-  - toc:
-      permalink: true
   - meta
-
+  - toc:
+      # insert a blank space before the character
+      permalink: " ¶"
 theme:
   name: material
   feature: