From 180507c62b5153295950cfeabbcfa576b2894a14 Mon Sep 17 00:00:00 2001 From: Andrew Klychkov Date: Tue, 18 Aug 2020 19:07:27 +0300 Subject: [PATCH] dev_guide: improve developing_collections.rst (#71332) --- .../rst/dev_guide/developing_collections.rst | 24 ++++++++++--------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/docs/docsite/rst/dev_guide/developing_collections.rst b/docs/docsite/rst/dev_guide/developing_collections.rst index 1854afa4301..f672e0f78e7 100644 --- a/docs/docsite/rst/dev_guide/developing_collections.rst +++ b/docs/docsite/rst/dev_guide/developing_collections.rst @@ -92,9 +92,9 @@ module_utils When coding with ``module_utils`` in a collection, the Python ``import`` statement needs to take into account the FQCN along with the ``ansible_collections`` convention. The resulting Python import will look like ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}`` The following example snippets show a Python and PowerShell module using both default Ansible ``module_utils`` and -those provided by a collection. In this example the namespace is ``ansible_example``, the collection is ``community``. +those provided by a collection. In this example the namespace is ``community``, the collection is ``test_collection``. In the Python example the ``module_util`` in question is called ``qradar`` such that the FQCN is -``ansible_example.community.plugins.module_utils.qradar``: +``community.test_collection.plugins.module_utils.qradar``: .. code-block:: python @@ -103,7 +103,7 @@ In the Python example the ``module_util`` in question is called ``qradar`` such from ansible.module_utils.six.moves.urllib.parse import urlencode, quote_plus from ansible.module_utils.six.moves.urllib.error import HTTPError - from ansible_collections.ansible_example.community.plugins.module_utils.qradar import QRadarRequest + from ansible_collections.community.test_collection.plugins.module_utils.qradar import QRadarRequest argspec = dict( name=dict(required=True, type='str'), @@ -128,13 +128,13 @@ Note that importing something from an ``__init__.py`` file requires using the fi from ansible_collections.namespace.collection_name.plugins.callback.__init__ import CustomBaseClass In the PowerShell example the ``module_util`` in question is called ``hyperv`` such that the FCQN is -``ansible_example.community.plugins.module_utils.hyperv``: +``community.test_collection.plugins.module_utils.hyperv``: .. code-block:: powershell #!powershell #AnsibleRequires -CSharpUtil Ansible.Basic - #AnsibleRequires -PowerShell ansible_collections.ansible_example.community.plugins.module_utils.hyperv + #AnsibleRequires -PowerShell ansible_collections.community.test_collection.plugins.module_utils.hyperv $spec = @{ name = @{ required = $true; type = "str" } @@ -218,7 +218,7 @@ A collection can store some additional metadata in a ``runtime.yml`` file in the Content in a collection that Ansible needs to load from another location or that has been deprecated/removed. The top level keys of ``plugin_routing`` are types of plugins, with individual plugin names as subkeys. To define a new location for a plugin, set the ``redirect`` field to another name. - To deprecate a plugin, use the ``deprecation`` field to provide a custom warning message and the removal date or version. If the plugin has been renamed or moved to a new location, the ``redirect`` field should also be provided. If a plugin is being removed entirely, ``tombstone`` can be used for the fatal error message and removal date or version. + To deprecate a plugin, use the ``deprecation`` field to provide a custom warning message and the removal version or date. If the plugin has been renamed or moved to a new location, the ``redirect`` field should also be provided. If a plugin is being removed entirely, ``tombstone`` can be used for the fatal error message and removal version or date. .. code:: yaml @@ -252,7 +252,7 @@ A collection can store some additional metadata in a ``runtime.yml`` file in the import_redirection: ansible.module_utils.old_utility: - redirect: ansible_collections.collection_name.plugins.module_utils.new_location + redirect: ansible_collections.namespace_name.collection_name.plugins.module_utils.new_location .. _creating_collections_skeleton: @@ -293,7 +293,7 @@ Currently the ``ansible-galaxy collection`` command implements the following sub * ``publish``: Publish a built collection artifact to Galaxy. * ``install``: Install one or more collections. -To learn more about the ``ansible-galaxy`` cli tool, see the :ref:`ansible-galaxy` man page. +To learn more about the ``ansible-galaxy`` command-line tool, see the :ref:`ansible-galaxy` man page. .. _docfragments_collections: @@ -359,7 +359,7 @@ By default the build step will include all the files in the collection directory * ``*.retry`` * ``tests/output`` * previously built artifacts in the root directory -* Various version control directories like ``.git/`` +* various version control directories like ``.git/`` To exclude other files and folders when building the collection, you can set a list of file glob-like patterns in the ``build_ignore`` key in the collection's ``galaxy.yml`` file. These patterns use the following special characters for @@ -524,7 +524,7 @@ will be the version displayed everywhere in Galaxy; however, users will still be Collection versions use `Semantic Versioning `_ for version numbers. Please read the official documentation for details and examples. In summary: * Increment major (for example: x in `x.y.z`) version number for an incompatible API change. -* Increment minor (for example: y in `x.y.z`) version number for new functionality in a backwards compatible manner. +* Increment minor (for example: y in `x.y.z`) version number for new functionality in a backwards compatible manner (for example new modules/plugins, parameters, return values). * Increment patch (for example: z in `x.y.z`) version number for backwards compatible bug fixes. .. _migrate_to_collection: @@ -532,6 +532,8 @@ Collection versions use `Semantic Versioning `_ for version Migrating Ansible content to a different collection ==================================================== +First, look at `Ansible Collection Checklist `_. + To migrate content from one collection to another, you need to create three PRs as follows: #. Create a PR against the old collection to remove the content. @@ -714,7 +716,7 @@ If you clone a fork, add the original repository as a remote ``upstream``:: cd ~/dev/ansible/collections/ansible_collections/community/general git remote add upstream git@github.com:ansible-collections/community.general.git -Now you can use this checkout of ``community.general`` in playbooks and roles with whichever version of Ansible you have installed locally, including a local checkout of the ``devel`` branch. +Now you can use this checkout of ``community.general`` in playbooks and roles with whichever version of Ansible you have installed locally, including a local checkout of the ``main`` branch. For collections hosted in the ``ansible_collections`` GitHub org, create a branch and commit your changes on the branch. When you are done (remember to add tests, see :ref:`testing_collections`), push your changes to your fork of the collection and create a Pull Request. For other collections, especially for collections not hosted on GitHub, check the ``README.md`` of the collection for information on contributing to it.