docs: fix very many broken/redirecting links

.github/PULL_REQUEST_TEMPLATE.md

@@ -12,4 +12,4 @@ https://github.com/jupyterhub/binderhub/compare/<OLD-HASH>...<NEW-HASH>
 
 This is a repo2docker version bump. See the link below for a diff of new changes:
 
-https://github.com/jupyter/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
+https://github.com/jupyterhub/repo2docker/compare/<OLD-HASH>...<NEW-HASH>

README.md

@@ -26,7 +26,7 @@ If you wish to deploy your own Binder instance, please **do not use** these file
 Instead, you should review the [BinderHub documentation][] and the
 [`jupyterhub/binderhub`][] repo to set up your deployment.
 
-## Site Reliability Guide [![Documentation Status](http://readthedocs.org/projects/mybinder-sre/badge/?version=latest)](http://mybinder-sre.readthedocs.io/en/latest/?badge=latest)
+## Site Reliability Guide [![Documentation Status](https://readthedocs.org/projects/mybinder-sre/badge/?version=latest)](https://mybinder-sre.readthedocs.io/en/latest/?badge=latest)
 
 [Site Reliability Guide](https://mybinder-sre.readthedocs.io/en/latest/index.html), the collected wisdom of operating mybinder.org.
 

docs/source/analytics/events-archive.rst

@@ -14,7 +14,7 @@ interpret it.
 File format
 ===========
 
-All data files are in `jsonl <http://jsonlines.org/>`_ format. Each line,
+All data files are in `jsonl <https://jsonlines.org/>`_ format. Each line,
 delimited by a ``\n`` is a is a well formed JSON object. These files can
 be read / written in a streaming fashion, one line at a time, without
 having to read the entire file into memory.

docs/source/components/cloud.md

@@ -117,8 +117,8 @@ of nodes.
 ## Google Container Registry
 
 A core part of mybinder.org is building, storing and then running docker images
-(built by [repo2docker](https://github.com/jupyter/repo2docker)). Docker images
-are generally stored in a [docker registry](https://github.com/docker/distribution),
+(built by [repo2docker](https://github.com/jupyterhub/repo2docker)). Docker images
+are generally stored in a [docker registry](https://github.com/distribution/distribution),
 using a well-defined standard API.
 
 We use Google Cloud's hosted docker registry - [Google Container Registry (GCR)](https://cloud.google.com/container-registry/).
@@ -131,7 +131,7 @@ without having to run any of that infrastructure ourselves.
 GCR is private by default, and can be only used from inside the Google Cloud project
 the registry is located in. When using GKE, the authentication for pulling images
 to run is already set up for us, so we do not need to do anything special. For pushing
-images, we authenticate via a [service account](https://cloud.google.com/container-registry/docs/advanced-authentication#using_a_json_key_file).
+images, we authenticate via a [service account](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key).
 
 You can find this service account credential under `registry` in `secrets/config/prod.yaml`
 and `secrets/config/staging.yaml`.
@@ -156,7 +156,7 @@ We do not allow users to pull our images, for a few reasons:
    break other users who might depend on this.
 
 For users who want access to a docker image similar to how it is built with Binder,
-we recommend using [repo2docker](https://github.com/jupyter/repo2docker) to build
+we recommend using [repo2docker](https://github.com/jupyterhub/repo2docker) to build
 your own, and push it to a registry of your choice.
 
 ### Naming
@@ -181,7 +181,7 @@ Changing this prefix will invalidate all existing images.
 
 ## Logging, Metrics, and Dashboarding
 
-We use [Google Stackdriver](https://cloud.google.com/stackdriver/) for logging
+We use [Google Stackdriver](https://cloud.google.com/products/operations) for logging
 activity on the Kubernetes deployment. This is useful for listing the raw
 logs coming out of BinderHub, though we don't use it for dashboarding (see below).
 

docs/source/components/dashboards.md

@@ -34,23 +34,23 @@ to see what queries make up the dashboard, and how you can edit it.
 All the dashboard definitions are stored in an `sqlite` database on a
 disk attached to the running grafana instance.
 
-The [Grafana documentation](http://docs.grafana.org/guides/basic_concepts/)
+The [Grafana documentation](https://grafana.com/docs/grafana/latest/basics/)
 has more info on the various concepts in Grafana, and how you can use them.
 You can also create a new dashboard and play with it. Be careful before
 editing currently used dashboards!
 
 ## Installation & Configuration
 
-Grafana is installed with the [Grafana helm chart](https://github.com/kubernetes/charts/tree/master/stable/grafana).
+Grafana is installed with the [Grafana helm chart](https://github.com/helm/charts/tree/master/stable/grafana).
 You can see the options for configuring it documented in its
-[`values.yaml`](https://github.com/kubernetes/charts/blob/master/stable/grafana/values.yaml)
+[`values.yaml`](https://github.com/helm/charts/blob/master/stable/grafana/values.yaml)
 file. You can also see the specific ways we have configured it
 in the `grafana` section of `mybinder/values.yaml`, `config/prod.yaml`
 and `config/staging.yaml`.
 
 ## Annotations
 
-[Annotations](http://docs.grafana.org/reference/annotations/) are
+[Annotations](https://grafana.com/docs/grafana/latest/dashboards/annotations/) are
 a cool feature of Grafana that lets us add arbitrary markers tagged to
 all graphs marking an event that has happened. For example, you can
 create an annotation each time a deployment happens - this puts a

docs/source/components/ingress.md

@@ -29,7 +29,7 @@ we decided to use nginx instead for the following reasons:
 
 ### Installation
 
-nginx-ingress is installed using the [nginx-ingress helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress).
+nginx-ingress is installed using the [nginx-ingress helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress).
 This installs the following components:
 
 1. `nginx-ingress-controller` - keeps the HTTPS rules in sync with `Ingress`
@@ -53,7 +53,7 @@ present with `kubectl --namespace=prod get ingress`.
 The following ingress objects currently exist:
 
 * `jupyterhub` - Directs traffic to `hub.mybinder.org`.
-  The zero-to-jupyterhub guide has more [documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/advanced.html#ingress).
+  The zero-to-jupyterhub guide has more [documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/administrator/advanced.html#ingress).
 * `binderhub` - Directs traffic to `mybinder.org`. You can find more details
    about this in the [binderhub helm chart](https://github.com/jupyterhub/binderhub/tree/master/helm-chart).
 * `redirector` - Directs traffic to the HTTP redirector we run for `mybinder.org`.
@@ -84,7 +84,7 @@ Kube-lego is deprecated, and we should move to
 
 ### Installation
 
-kube-lego is installed using the [kube-lego](https://github.com/kubernetes/charts/tree/master/stable/kube-lego).
+kube-lego is installed using the [kube-lego](https://github.com/helm/charts/tree/master/stable/kube-lego).
 
 ### Configuration
 

docs/source/components/metrics.md

@@ -45,7 +45,7 @@ You do not need to become an expert, but a basic understanding is useful.
 There are also [examples](https://prometheus.io/docs/prometheus/latest/querying/examples/)
 to pick up and play with!
 
-[prometheus.mybinder.org](https://prometheus.mybinder.org) is our public
+[prometheus.mybinder.org](https://prometheus.mybinder.org/graph) is our public
 prometheus installation, and you can practice your queries there! 
 
 
@@ -88,23 +88,23 @@ these containers using right now', etc. These are usually prefixed with
 
 #### HTTP request information
 
-We use the [nginx-ingress helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress)
+We use the [nginx-ingress helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
 to let all HTTP traffic into our cluster. This allows us to use
 the [nginx VTS exporter](https://hnlq715.github.io/nginx-vts-exporter/)
 to collect information in prometheus about requests / responses.
 These metrics are prefixed with `nginx_`.
 
 #### BinderHub information
 
-[BinderHub](http://github.com/jupyterhub/binderhub) itself exposes
+[BinderHub](https://github.com/jupyterhub/binderhub) itself exposes
 metrics about its operations in the prometheus format, using 
 the [python prometheus client library](https://github.com/prometheus/client_python).
 These are currently somewhat limited, and prefixed with `binderhub_`
 
 ### Configuration
 
 Prometheus is installed using the 
-[prometheus helm chart](https://github.com/kubernetes/charts/tree/master/stable/prometheus).
+[prometheus helm chart](https://github.com/helm/charts/tree/master/stable/prometheus).
 This installs the following components:
 
 1. Prometheus server (storage + querying)
@@ -116,6 +116,6 @@ kubernetes component), and the prometheus helm chart has configuration
 that adds those as targets.
 
 You can see the available options for configuring the prometheus
-helm chart in its [values.yaml](https://github.com/kubernetes/charts/blob/master/stable/prometheus/values.yaml)
+helm chart in its [values.yaml](https://github.com/helm/charts/blob/master/stable/prometheus/values.yaml)
 file. You can see the current configuration we have under the `prometheus`
 section of `mybinder/values.yaml`, `config/prod.yaml` and `config/staging.yaml`.

docs/source/conf.py

@@ -48,3 +48,19 @@
 html_static_path = ['_static']
 
 html_logo = '_static/images/logo.png'
+
+
+# -- Options for linkcheck builder -------------------------------------------
+# ref: https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-the-linkcheck-builder
+#
+linkcheck_ignore = [
+    r"(.*)github\.com(.*)#",  # javascript based anchors
+    r"(.*)/#%21(.*)/(.*)",  # /#!forum/jupyter - encoded anchor edge case
+    "https://grafana.mybinder.org", # likely no longer functional links from incident reports
+    "https://console.cloud.google.com",  # sign-in redirect noise
+    "https://console.developers.google.com",  # sign-in redirect noise
+]
+linkcheck_anchors_ignore = [
+    "/#!",
+    "/#%21",
+]

docs/source/deployment/how.md

@@ -4,7 +4,7 @@ This document explains **how** to deploy a change to mybinder.org.
 For information on what exactly a deployment does, see [what](what).
 
 When a new change has landed in either [BinderHub](https://github.com/jupyterhub/binderhub)
-or [repo2docker](https://github.com/jupyter/repo2docker), they need to be explicitly
+or [repo2docker](https://github.com/jupyterhub/repo2docker), they need to be explicitly
 deployed to mybinder.org for users to benefit from them. This is the most common kind of
 change deployed to mybinder.org.
 
@@ -55,7 +55,7 @@ updating the BinderHub Helm chart version, which we step through below.
        ---------------------
 
        BinderHub: https://github.com/jupyterhub/binderhub/compare/<OLD-HASH>...<NEW-HASH>
-       repo2docker: https://github.com/jupyter/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
+       repo2docker: https://github.com/jupyterhub/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
        JupyterHub: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/<OLD-HASH>...<NEW-HASH>
 
        ---------------------
@@ -109,7 +109,7 @@ The following lines describe how to point mybinder.org to the new repo2docker im
        ---------------------
 
        BinderHub: https://github.com/jupyterhub/binderhub/compare/<OLD-HASH>...<NEW-HASH>
-       repo2docker: https://github.com/jupyter/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
+       repo2docker: https://github.com/jupyterhub/repo2docker/compare/<OLD-HASH>...<NEW-HASH>
        JupyterHub: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/<OLD-HASH>...<NEW-HASH>
 
        ---------------------
@@ -170,7 +170,7 @@ master.
 7. If the tests fail, the change will *not* be deployed to mybinder.org.
    You must then investigate why it failed. **If you can
    not figure out a cause in about 10 minutes, revert the change.**
-   You can revert the change with [the GitHub UI](https://help.github.com/articles/reverting-a-pull-request/) and immediately
+   You can revert the change with [the GitHub UI](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request) and immediately
    merge the reversion PR that GitHub creates.
 8. Troubleshoot and make changes to your fork. Repeat the process from Step 1.
 

docs/source/deployment/prereqs.md

@@ -23,7 +23,7 @@ things when deployments fail.
 
 ## Kubernetes
 
-We heavily use [Kubernetes](https://k8s.io) for the mybinder.org deployment, and it is important you
+We heavily use [Kubernetes](https://kubernetes.io/) for the mybinder.org deployment, and it is important you
 have a working knowledge of how to use Kubernetes. Detailed explanations are out
 of the scope of this repository, but there is a good [list of tutorials](https://kubernetes.io/docs/tutorials/).
 Specifically, going through the [interactive tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/)
@@ -36,13 +36,13 @@ have a working knowledge of how to use helm. Detailed explanations are out of th
 scope of this repository, but [docs.helm.sh](https://docs.helm.sh) is an excellent
 source of information. At a minimum, you must at least understand:
 
-* [What is a chart?](https://docs.helm.sh/developing_charts/#charts)
-* [What are values files?](https://docs.helm.sh/chart_template_guide/#values-files)
-* [How do chart dependencies work?](https://docs.helm.sh/developing_charts/#chart-dependencies)
+* [What is a chart?](https://helm.sh/docs/chart_template_guide/getting_started/#charts)
+* [What are values files?](https://helm.sh/docs/chart_template_guide/values_files/)
+* [How do chart dependencies work?](https://helm.sh/docs/chart_template_guide/subcharts_and_globals/)
 
 ## Travis
 
-We use [Travis CI](http://travis-ci.org/) for doing all our deployments. Our
+We use [Travis CI](https://travis-ci.org/) for doing all our deployments. Our
 `.travis.yml` file contains the entire configuration for our deployment. Travis CI
 has documentation on the [various components of the `.travis.yml` file](https://docs.travis-ci.com/user/customizing-the-build/).
 

docs/source/deployment/what.md

@@ -32,7 +32,7 @@ need them on your local computer.
    and upgrading the various components running mybinder.org (BinderHub, JupyterHub,
    extra mybinder.org-specific services, etc)
 
-3. [`kubectl`](https://kubernetes.io/docs/reference/kubectl/overview/)
+3. [`kubectl`](https://kubernetes.io/docs/reference/kubectl/)
 
    `kubectl` is the canonical command line client for interacting with the Kubernetes
    API. We primarily use it to explicitly wait for our deployment to complete
@@ -136,9 +136,9 @@ are available in unencrypted form.
 
 #### Background
 
-We use [helm charts](https://github.com/kubernetes/helm/blob/master/docs/charts.md)
+We use _helm charts_
 to configure mybinder.org. We use charts both from the 
-[official kubernetes charts repository](https://github.com/kubernetes/charts),
+[official kubernetes charts repository](https://github.com/helm/charts),
 as well as the [JupyterHub charts repository](https://jupyterhub.github.io/helm-chart).
 
 #### What happens
@@ -176,7 +176,7 @@ charts.
 
 ### Step 3: Tell Grafana our deployment is starting
 
-We create an [annotation](http://docs.grafana.org/reference/annotations/)
+We create an [annotation](https://grafana.com/docs/grafana/latest/dashboards/annotations/)
 in Grafana, recording the fact that a deployment is starting.
 
 This is very useful when looking at dashboards, since you can see
@@ -198,7 +198,7 @@ following:
 1. Use the Google Cloud Service Accounts we decrypted in Stage 2, Step 1 to get
    a valid [~/.kube/config](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
    file. This file is used by both `helm` and `kubectl` to access the cluster.
-2. Use [`helm upgrade`](https://github.com/kubernetes/helm/blob/master/docs/helm/helm_upgrade.md)
+2. Use `helm upgrade`
    to actually do the deployment. This deploys whatever changes the commit has -
    new chart versions, changes to configuration, new repo2docker version, etc.
    We have a ten minute timeout here.
@@ -217,8 +217,7 @@ the helm deployment is complete!
    YAML syntax can be finnicky sometimes, and fail in non-obvious ways. The most common
    error is the presence of tab characters in YAML, which will make them always fail.
 
-   The Helm community has [some tips](https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/yaml_techniques.md)
-   on common YAML issues. Learn X in Y Minutes also has a nice [guide on YAML](https://learnxinyminutes.com/docs/yaml/).
+   Learn X in Y Minutes also has a nice [guide on YAML](https://learnxinyminutes.com/docs/yaml/).
    You can also use [yamllint](https://github.com/adrienverge/yamllint) locally to validate
    your YAML files.
 

docs/source/getting_started/getting_started.md

@@ -14,15 +14,15 @@ to get access.
 The most important tool for keeping an eye on the Kubernetes deployment is
 `kubectl` and the `gcloud` SDK. These will let you run queries on the
 `mybinder.org` deployment from your command line. To set this up, check
-out the [Zero to JupyterHub Google SDK section](https://zero-to-jupyterhub.readthedocs.io/en/latest/create-k8s-cluster.html#setting-up-kubernetes-on-google-cloud).
+out the [Zero to JupyterHub Google SDK section](https://zero-to-jupyterhub.readthedocs.io/en/latest/kubernetes/google/step-zero-gcp.html).
 (everything before the part where you create a google cloud cluster).
 
 When you run `gcloud init` for the first time, it'll ask you to authenticate
 and to choose a project / default region. You should authenticate with
 the email that's been given privileges to work on `mybinder.org`, choose
 the project `binderhub`, and use the region `us-central1`.
 
-We recommend enabling [`kubectl` autocompletion](https://kubernetes.io/docs/tasks/tools/install-kubectl/#enabling-shell-autocompletion)
+We recommend enabling [`kubectl` autocompletion](https://kubernetes.io/docs/tasks/tools/#kubectl)
 as well.
 
 ## Set up `kubectl` to connect to `mybinder.org`
@@ -56,8 +56,7 @@ gcloud container clusters get-credentials staging --zone us-central1-a --project
 ```
 
 You can now switch between the `prod` and `staging` deployments by changing your
-`kubectl` context. See the [Kubectl context documentation](https://kubernetes-v1-4.github.io/docs/user-guide/kubectl/kubectl_config_use-context/)
-for more information.
+`kubectl` context.
 
 ## Look at the project Grafana