Docs: call linkcheck Sphinx builder for our docs

.readthedocs.yml

@@ -14,6 +14,9 @@ build:
   os: ubuntu-20.04
   tools:
     python: "3.8"
+  jobs:
+    pre_build:
+      - sphinx-build -W --keep-going -q -b linkcheck -d _build/doctrees docs/ _build/linkcheck
 
 search:
   ranking:

docs/dev/design/in-doc-search-ui.rst

@@ -20,7 +20,6 @@ The final result may look something like this:
 
 .. figure:: /_static/images/design-docs/in-doc-search-ui/in-doc-search-ui-demo.gif
     :align: center
-    :target: /_static/images/design-docs/in-doc-search-ui/in-doc-search-ui-demo.gif
 
     Short demo
 

docs/dev/i18n.rst

@@ -295,7 +295,7 @@ not compile the translation files, so you have to do this after the pull (see
 the `Compiling to MO`_ section).
 
 For more information about the ``tx`` command, read the `Transifex client's
-help pages <http://help.transifex.com/features/client/>`_.
+help pages <https://docs.transifex.com/client/introduction/>`_.
 
 
 .. note::

docs/dev/install.rst

@@ -204,7 +204,6 @@ For others, the webhook will simply fail to connect when there are new commits t
 .. figure:: /_static/images/development/bitbucket-oauth-setup.png
     :align: center
     :figwidth: 80%
-    :target: /_static/images/development/bitbucket-oauth-setup.png
 
     Configuring an OAuth consumer for local development on Bitbucket
 

docs/user/automatic-redirects.rst

@@ -27,9 +27,9 @@ For example::
     docs.readthedocs.io -> docs.readthedocs.io/en/latest/
     www.pip-installer.org -> www.pip-installer.org/en/latest/
 
-This only works for the root URL, not for internal pages. It's designed to redirect people from http://pip.readthedocs.io/ to the default version of your documentation, since serving up a 404 here would be a pretty terrible user experience. (If your "develop" branch was designated as your default version, then it would redirect to http://pip.readthedocs.io/en/develop.) But, it's not a universal redirecting solution. So, for example, a link to an internal page like http://pip.readthedocs.io/usage.html doesn't redirect to http://pip.readthedocs.io/en/latest/usage.html.
+This only works for the root URL, not for internal pages. It's designed to redirect people from ``http://pip.readthedocs.io/`` to the default version of your documentation, since serving up a 404 here would be a pretty terrible user experience. (If your "develop" branch was designated as your default version, then it would redirect to ``http://pip.readthedocs.io/en/develop``.) But, it's not a universal redirecting solution. So, for example, a link to an internal page like ``http://pip.readthedocs.io/usage.html`` doesn't redirect to ``http://pip.readthedocs.io/en/latest/usage.html``.
 
-The reasoning behind this is that RTD organizes the URLs for docs so that multiple translations and multiple versions of your docs can be organized logically and consistently for all projects that RTD hosts. For the way that RTD views docs, http://pip.readthedocs.io/en/latest/ is the root directory for your default documentation in English, not http://pip.readthedocs.io/. Just like http://pip.readthedocs.io/en/develop/ is the root for your development documentation in English.
+The reasoning behind this is that RTD organizes the URLs for docs so that multiple translations and multiple versions of your docs can be organized logically and consistently for all projects that RTD hosts. For the way that RTD views docs, ``http://pip.readthedocs.io/en/latest/`` is the root directory for your default documentation in English, not ``http://pip.readthedocs.io/``. Just like ``http://pip.readthedocs.io/en/develop/`` is the root for your development documentation in English.
 
 Among all the multiple versions of docs, you can choose which is the "default" version for RTD to display, which usually corresponds to the git branch of the most recent official release from your project.
 

docs/user/faq.rst

@@ -137,7 +137,7 @@ https://celery.readthedocs.io/projects/kombu/en/latest/
 
 This also works the same for custom domains:
 
-http://docs.celeryproject.org/projects/kombu/en/latest/
+http://docs..org/projects/kombu/en/latest/
 
 You can add subprojects in the project admin dashboard.
 

docs/user/guides/conda.rst

@@ -134,7 +134,7 @@ with these contents:
 You can read more about the :ref:`config-file/v2:build.tools.python` configuration
 in our documentation.
 
-.. _mamba: https://quantstack.net/mamba.html
+.. _mamba: https://github.com/mamba-org/mamba
 .. _a known issue: https://www.anaconda.com/understanding-and-improving-condas-performance/
 
 Mixing conda and pip packages

docs/user/guides/technical-docs-seo-guide.rst

@@ -222,7 +222,6 @@ In Sphinx, you can customize your meta description using the following Restructu
 .. figure:: ../_static/images/guides/google-search-engine-results.png
     :align: center
     :figwidth: 80%
-    :target: ../_static/images/guides/google-search-engine-results.png
 
     Google search engine results showing a customized meta description
 

docs/user/integrations.rst

@@ -108,7 +108,7 @@ On Read the Docs:
 On your Gitea instance:
 
 * Go to the :guilabel:`Settings` > :guilabel:`Webhooks` page for your project on your Gitea instance
-* Create a new webhook of type "Gitea" 
+* Create a new webhook of type "Gitea"
 * For **URL**, use the URL of the integration on Read the Docs,
   found on the :guilabel:`Admin` > :guilabel:`Integrations` page
 * Leave the default **HTTP Method** as POST
@@ -197,7 +197,7 @@ Payload validation
 
 If your project was imported through a connected account,
 we create a secret for every integration that offers a way to verify that a webhook request is legitimate.
-Currently, `GitHub <https://developer.github.com/webhooks/securing/>`__ and `GitLab <https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#secret-token>`__
+Currently, `GitHub <https://developer.github.com/webhooks/securing/>`__ and `GitLab <https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#validate-payloads-by-using-a-secret-token>`__
 offer a way to check this.
 
 Troubleshooting

docs/user/intro/getting-started-with-mkdocs.rst

@@ -54,15 +54,14 @@ You can make changes to your Markdown files and your docs will automatically reb
 
 .. figure:: /_static/images/first-steps/mkdocs-hello-world.png
    :figwidth: 500px
-   :target: /_static/images/first-steps/mkdocs-hello-world.png
    :align: center
 
    Your MkDocs project is built
 
 Once you have your documentation in a public repository such as GitHub, Bitbucket, or GitLab,
 you can start using Read the Docs by :doc:`importing your docs </intro/import-guide>`.
 
-.. _install MkDocs: https://www.mkdocs.org/#installation
+.. _install MkDocs: https://www.mkdocs.org/user-guide/installation/
 
 .. warning::
 

docs/user/intro/getting-started-with-sphinx.rst

@@ -62,7 +62,6 @@ Open this file in your web browser to see your docs.
 
 .. figure:: /_static/images/first-steps/sphinx-hello-world.png
    :figwidth: 500px
-   :target: /_static/images/first-steps/sphinx-hello-world.png
    :align: center
 
    Your Sphinx project is built

docs/user/intro/import-guide.rst

@@ -26,7 +26,6 @@ these properties, and then click **Next** to
 .. figure:: ../_static/images/first-steps/import-a-repository.png
     :align: right
     :figwidth: 300px
-    :target: ../_static/images/first-steps/import-a-repository.png
 
     Importing a repository
 
@@ -60,7 +59,6 @@ for more information on this process.
 
     .. figure:: ../_static/images/first-steps/admin-panel.png
         :figwidth: 400px
-        :target: ../_static/images/first-steps/admin-panel.png
 
 
 Building your documentation

docs/user/pull-requests.rst

@@ -30,7 +30,6 @@ Warning banner
    :align: center
    :alt: GitHub build status reporting for pull requests.
    :figwidth: 80%
-   :target: ../_static/images/guides/github-build-status-reporting.gif
 
    GitHub build status reporting
 

docs/user/tutorial/index.rst

@@ -467,7 +467,7 @@ For that, first navigate to your GitHub repository, click on the branch selector
 type ``1.0.x``, and click on "Create branch: 1.0.x from 'main'"
 (more information `on their documentation`__).
 
-__  https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
+__ https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
 
 Next, go to your :term:`project home`, click on the :guilabel:`Versions` button,
 and under "Active Versions" you will see two entries: