Replace URLs into the Ansible docsite with RST references (#3281)

* Replace URLs into the Ansible docsite with RST references.

* Add anscollection role to rstcheck.

docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst

@@ -12,7 +12,7 @@ Collections MUST follow the `semantic versioning <https://semver.org/>`_ rules.
 Release planning and announcement
 ----------------------------------
 
-#. Announce your intention to release the collection in a corresponding pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel <https://docs.ansible.com/projects/ansible/devel/community/communication.html#real-time-chat>`_. Repeat the announcement in any other dedicated channels if they exist.
+#. Announce your intention to release the collection in a corresponding pinned release issue/community pinboard of the collection and in the ``#ansible-community`` :ref:`Matrix/IRC channel <communication_irc>`. Repeat the announcement in any other dedicated channels if they exist.
 
 #. Ensure all the other repository maintainers are informed about the time of the following release.
 
@@ -152,7 +152,7 @@ Publishing the collection
 
 5. Announce the release through the `Bullhorn Newsletter <https://forum.ansible.com/c/news/bullhorn/17>`_.
 
-6. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/Libera.Chat IRC channel <https://docs.ansible.com/projects/ansible/devel/community/communication.html#real-time-chat>`_.
+6. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` :ref:`Matrix/Libera.Chat IRC channel <communication_irc>`.
 
 7. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, ``X.1.0``. Add, commit and push to the **upstream** repository.
 
@@ -207,7 +207,7 @@ Publishing the collection
 
 4. Announce the release through the `Bullhorn Newsletter <https://forum.ansible.com/c/news/bullhorn/17>`_.
 
-5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel <https://docs.ansible.com/projects/ansible/devel/community/communication.html#real-time-chat>`_. Additionally, you can announce it using GitHub's Releases system.
+5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` :ref:`Matrix/IRC channel <communication_irc>`. Additionally, you can announce it using GitHub's Releases system.
 
 6. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, if you have released ``X.1.0``, the next expected version could be ``X.2.0``. Add, commit and push to the **upstream** repository.
 
@@ -291,7 +291,7 @@ Releasing when more minor versions are expected
 
 4. Announce the release through the `Bullhorn Newsletter <https://forum.ansible.com/c/news/bullhorn/17>`_.
 
-5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel <https://docs.ansible.com/projects/ansible/devel/community/communication.html#real-time-chat>`.
+5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` :ref:`Matrix/IRC channel <communication_irc>`.
 
 
 Releasing when no more minor versions are expected
@@ -338,4 +338,4 @@ Releasing when no more minor versions are expected
 
 4. Announce the release through the `Bullhorn Newsletter <https://forum.ansible.com/c/news/bullhorn/17>`_.
 
-5. Announce the release in the pinned issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel <https://docs.ansible.com/projects/ansible/devel/community/communication.html#real-time-chat>`_.
+5. Announce the release in the pinned issue/community pinboard of the collection and in the ``#ansible-community`` :ref:`Matrix/IRC channel <communication_irc>`.

docs/docsite/rst/community/contributor_path.rst

@@ -22,7 +22,7 @@ Find the corresponding project
 These are multiple community projects in the Ansible ecosystem you could contribute to:
 
 - `Ansible Core <https://docs.ansible.com/ansible-core/devel/index.html>`_
-- `Collections <https://docs.ansible.com/projects/ansible/latest/user_guide/collections_using.html>`_
+- :ref:`Collections <collections_index>`
 - `AWX <https://github.com/ansible/awx>`_
 - `Galaxy <https://galaxy.ansible.com/>`_
 - `ansible-lint <https://ansible-lint.readthedocs.io/en/latest/>`_

docs/docsite/rst/community/steering/steering_committee_membership.rst

@@ -129,7 +129,7 @@ In case of absence or irregular participation, the removal process consists of t
 Ansible Community Code of Conduct violations
 .............................................
 
-In case of the `Ansible Community Code of Conduct <https://docs.ansible.com/projects/ansible/latest/community/code_of_conduct.html>`_ violations, the process is the same as above except steps 1-2. Instead:
+In case of the :ref:`Ansible Community Code of Conduct <code_of_conduct>` violations, the process is the same as above except steps 1-2. Instead:
 
 #. The initiator reports the case to the Committee by email.
 

docs/docsite/rst/dev_guide/developing_modules_general.rst

@@ -180,7 +180,7 @@ information, including instructions for :ref:`testing module documentation <test
 
 .. note::
   If contributing to Ansible, every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure.
-  In this case, the tests should be marked with the ``unsupported`` alias in `aliases file <https://docs.ansible.com/projects/ansible/latest/dev_guide/testing/sanity/integration-aliases.html>`_.
+  In this case, the tests should be marked with the ``unsupported`` alias in :ref:`aliases file <integration_aliases>`.
 
 
 Contributing back to Ansible

docs/docsite/rst/dev_guide/testing/sanity/import.rst

@@ -134,6 +134,9 @@ Ansible allows the following unchecked imports from these specific directories:
   * For ``plugins/modules/`` and ``plugins/module_utils/``, unchecked imports are only allowed from the Python standard library;
   * For other directories in ``plugins/`` (see `the community collection requirements <https://docs.ansible.com/projects/ansible/devel/community/collection_contributors/collection_requirements.html#modules-plugins>`_ for a list), unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself.
 
+.. Note that the internal link above needs to stay since that page is not part of the ansible-core documentation,
+   while this document is both part of the ansible-core and the ansible docsite.
+
 Public dependencies of ansible-core are:
 
   * Jinja2

docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst

@@ -1,3 +1,5 @@
+.. _integration_aliases:
+
 integration-aliases
 ===================
 

docs/docsite/rst/dev_guide/testing_integration.rst

@@ -18,7 +18,7 @@ Some tests may require root.
 
 .. note::
   Every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure.
-  In this case, the tests should be marked with the ``unsupported`` alias in `aliases file <https://docs.ansible.com/projects/ansible/latest/dev_guide/testing/sanity/integration-aliases.html>`_.
+  In this case, the tests should be marked with the ``unsupported`` alias in :ref:`aliases file <integration_aliases>`.
 
 Quick Start
 ===========

docs/docsite/rst/inventory_guide/intro_inventory.rst

@@ -19,7 +19,7 @@ Ansible :ref:`inventory_plugins` supports a range of formats and sources, which
 .. contents::
    :local:
 
-The following YAML snippets include an ellipsis (...) to indicate that the snippets are part of a larger YAML file. You can find out more about YAML syntax at `YAML Basics <https://docs.ansible.com/projects/ansible/latest/reference_appendices/YAMLSyntax.html#yaml-basics">`_.
+The following YAML snippets include an ellipsis (...) to indicate that the snippets are part of a larger YAML file. You can find out more about YAML syntax at :ref:`yaml_basics`.
 
 .. _inventoryformat:
 

docs/docsite/rst/playbook_guide/playbooks_tests.rst

@@ -195,7 +195,7 @@ In Ansible 2.14, the ``pep440`` option for ``version_type`` was added, and the r
 
    "{{ '2.14.0rc1' is version('2.14.0', 'lt', version_type='pep440') }}"
 
-When using ``version`` in a playbook or role, don't use ``{{ }}`` as described in the `FAQ <https://docs.ansible.com/projects/ansible/latest/reference_appendices/faq.html#when-should-i-use-also-how-to-interpolate-variables-or-dynamic-variable-names>`_
+When using ``version`` in a playbook or role, don't use ``{{ }}`` as described in the :ref:`FAQ <when_to_use_brackets>`:
 
 .. code-block:: yaml
 

docs/docsite/rst/reference_appendices/YAMLSyntax.rst

@@ -15,6 +15,8 @@ You may also wish to read :ref:`working_with_playbooks` at the same time to see
 is used in practice.
 
 
+.. _yaml_basics:
+
 YAML Basics
 -----------
 

docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst

@@ -66,9 +66,9 @@ Adding a comment (any line starting with ``#``) helps others (and possibly yours
 Use fully qualified collection names
 ------------------------------------
 
-Use `fully qualified collection names (FQCN) <https://docs.ansible.com/projects/ansible/latest/reference_appendices/glossary.html#term-Fully-Qualified-Collection-Name-FQCN>`_ to avoid ambiguity in which collection to search for the correct module or plugin for each task.
+Use :term:`fully qualified collection names (FQCN) <Fully Qualified Collection Name (FQCN)>` to avoid ambiguity in which collection to search for the correct module or plugin for each task.
 
-For `builtin modules and plugins <https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/index.html#plugin-index>`_, use the ``ansible.builtin`` collection name as a prefix, for example, ``ansible.builtin.copy``.
+For :anscollection:`builtin modules and plugins <ansible.builtin>`, use the ``ansible.builtin`` collection name as a prefix, for example, ``ansible.builtin.copy``.
 
 .. _inventory_tips: