archive
/
ansible
mirror of https://github.com/ansible/ansible.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Backportapalooza 08 11 (#78526)

Browse Source 
* update the documentation for the _collection init_ command (#78404)

(cherry picked from commit 69c7e3f4a3)

* fix configuration name in porting guide 2.12  (#78472)

(cherry picked from commit 82246df5b7)

* docs: misc fixes in The Ansible Development Cycle (#78513)

(cherry picked from commit 0d3523df8f)

Co-authored-by: Alex <aizquier@redhat.com>
Co-authored-by: Akira Yokochi <akira6592@gmail.com>
pull/78594/head
Sandra McCann 3 years ago committed by GitHub
parent fd1935048c
commit e03527e722
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 8 additions and 6 deletions
Show Stats Download Patch File Download Diff File

4
docs/docsite/rst/community/development_process.rst
Unescape Escape View File

@ -45,7 +45,7 @@ Here's an overview of the PR lifecycle:
* Contributor addresses any feedback from reviewers * Contributor addresses any feedback from reviewers
* Developers, maintainers, community re-review * Developers, maintainers, community re-review
* PR merged or closed * PR merged or closed
* PR `backported <backport_process>`_ to one or more ``stable-X.Y`` branches (optional, bugfixes only) * PR :ref:`backported <backport_process>` to one or more ``stable-X.Y`` branches (optional, bugfixes only)
Automated PR review: ansibullbot Automated PR review: ansibullbot
-------------------------------- --------------------------------
@ -369,7 +369,7 @@ We do **not** backport features.
.. code-block:: shell .. code-block:: shell
git fetch upstream git fetch upstream
git checkout -b backport/2.12/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.13 git checkout -b backport/2.13/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.13
#. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary: #. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:

6
docs/docsite/rst/dev_guide/developing_collections_creating.rst
Unescape Escape View File

@ -22,16 +22,18 @@ A user can then install your collection on their systems.
Creating a collection skeleton Creating a collection skeleton
============================== ==============================
To start a new collection: To start a new collection, run the following command in your collections directory:
.. code-block:: bash .. code-block:: bash
collection_dir#> ansible-galaxy collection init my_namespace.my_collection ansible_collections#> ansible-galaxy collection init my_namespace.my_collection
.. note:: .. note::
Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for those requirements. Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for those requirements.
It will create the structure ``[my_namespace]/[my_collection]/[collection skeleton]``.
.. hint:: If Git is used for version control, the corresponding repository should be initialized in the collection directory.
Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections <https://github.com/ansible-collections/>`_ GitHub Org to get a better idea of what you can place inside a collection. Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections <https://github.com/ansible-collections/>`_ GitHub Org to get a better idea of what you can place inside a collection.
Reference: the ``ansible-galaxy collection`` command Reference: the ``ansible-galaxy collection`` command

2
docs/docsite/rst/porting_guides/porting_guide_5.rst
Unescape Escape View File

@ -46,7 +46,7 @@ Playbook
Python Interpreter Discovery Python Interpreter Discovery
============================ ============================
The default value of ``INTERPRETER_PYTHON_FALLBACK`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``. The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``.
``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable. ``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable.

2
docs/docsite/rst/porting_guides/porting_guide_core_2.12.rst
Unescape Escape View File

@ -44,7 +44,7 @@ Playbook
Python Interpreter Discovery Python Interpreter Discovery
============================ ============================
The default value of ``INTERPRETER_PYTHON_FALLBACK`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``. The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``.
``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable. ``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable.

Write Preview
Loading…
Cancel
Save