mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Last docs link fixes (#39391)
* should not need <>, but fails without * adds anchor to keywords page, uses it on plugins pages * fixes envvar link errors * harmonize file name and ref name as python_3 * removes undefined-lable from ignore list
This commit is contained in:
parent
7db5ce2c86
commit
c8a9b411bc
10 changed files with 11 additions and 10 deletions
|
@ -87,7 +87,7 @@ The following topics will discuss how to develop and work with modules:
|
|||
Checklist for contributing your module to Ansible.
|
||||
:doc:`testing`
|
||||
Developing unit and integration tests.
|
||||
:doc:`developing_python3`
|
||||
:ref:`developing_python_3`
|
||||
Adding Python 3 support to modules (all new modules must be Python-2.6 and Python-3.5 compatible).
|
||||
:doc:`developing_modules_in_groups`
|
||||
A guide for partners wanting to submit multiple modules.
|
||||
|
|
|
@ -23,7 +23,7 @@ The following checklist items are important guidelines for people who want to c
|
|||
|
||||
* The shebang must always be ``#!/usr/bin/python``. This allows ``ansible_python_interpreter`` to work
|
||||
* Modules must be written to support Python 2.6. If this is not possible, required minimum Python version and rationale should be explained in the requirements section in ``DOCUMENTATION``. In Ansible-2.3 the minimum requirement for modules was Python-2.4.
|
||||
* Modules must be written to use proper Python-3 syntax. At some point in the future we'll come up with rules for running on Python-3 but we're not there yet. See :doc:`developing_python3` for help on how to do this.
|
||||
* Modules must be written to use proper Python-3 syntax. At some point in the future we'll come up with rules for running on Python-3 but we're not there yet. See :doc:`developing_python_3` for help on how to do this.
|
||||
* Modules must have a metadata section. For the vast majority of new modules,
|
||||
the metadata should look exactly like this:
|
||||
|
||||
|
@ -131,8 +131,8 @@ Read the complete :ref:`module metadata specification <ansible_metadata_block>`
|
|||
module_utils.urls.fetch_url(). If you use those you may find you also want
|
||||
to fallback on environment variables for default values. If you do that,
|
||||
be sure to use non-generic environment variables (like
|
||||
:envvar:`API_<MODULENAME>_USERNAME`). Using generic environment variables
|
||||
like :envvar:`API_USERNAME` would conflict between modules.
|
||||
:code:`API_<MODULENAME>_USERNAME`). Using generic environment variables
|
||||
like :code:`API_USERNAME` would conflict between modules.
|
||||
|
||||
Windows modules checklist
|
||||
=========================
|
||||
|
|
|
@ -342,7 +342,7 @@ the most popular are
|
|||
To be able to view the arguments as passed by Ansible to the module follow
|
||||
these steps.
|
||||
|
||||
- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to specify that Ansible should keep the exec files on the server.
|
||||
- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1<ANSIBLE_KEEP_REMOTE_FILES>` to specify that Ansible should keep the exec files on the server.
|
||||
- Log onto the Windows server using the same user account that Ansible used to execute the module.
|
||||
- Navigate to ``%TEMP%\..``. It should contain a folder starting with ``ansible-tmp-``.
|
||||
- Inside this folder, open the PowerShell script for the module.
|
||||
|
|
|
@ -19,7 +19,7 @@ To get started, select one of the following topics.
|
|||
developing_plugins
|
||||
developing_inventory
|
||||
developing_core
|
||||
developing_python3
|
||||
developing_python_3
|
||||
developing_api
|
||||
developing_rebasing
|
||||
testing
|
||||
|
|
|
@ -29,7 +29,7 @@ into the ``connection_plugins`` directory.
|
|||
Using Connection Plugins
|
||||
++++++++++++++++++++++++
|
||||
|
||||
The transport can be changed via :ref:`configuration<ansible_configuration_settings>`, at the command line (``-c``, ``--connection``), as a :ref:`keyword <playbooks_keywords>` in your play, or by setting a :ref:`variable<behavioral_parameters>`, most often in your inventory.
|
||||
The transport can be changed via :ref:`configuration<ansible_configuration_settings>`, at the command line (``-c``, ``--connection``), as a :ref:`keyword <playbook_keywords>` in your play, or by setting a :ref:`variable<behavioral_parameters>`, most often in your inventory.
|
||||
For example, for Windows machines you might want to use the :doc:`winrm<connection/winrm>` plugin.
|
||||
|
||||
Most connection plugins can operate with a minimum configuration. By default they use the :ref:`inventory hostname<inventory_hostnames_lookup>` and defaults to find the target host.
|
||||
|
|
|
@ -34,7 +34,7 @@ or in the `ansible.cfg` file:
|
|||
[defaults]
|
||||
strategy=linear
|
||||
|
||||
You can also specify the strategy plugin in the play via the :ref:`strategy keyword <playbooks_keywords>` in a play::
|
||||
You can also specify the strategy plugin in the play via the :ref:`strategy keyword <playbook_keywords>` in a play::
|
||||
|
||||
- hosts: all
|
||||
strategy: debug
|
||||
|
|
|
@ -195,7 +195,7 @@ is likely the problem. There are several workarounds:
|
|||
|
||||
solaris1 ansible_remote_tmp=$HOME/.ansible/tmp
|
||||
|
||||
* You can set :ref:`ansible_shell_executable` to the path to a POSIX compatible shell. For
|
||||
* You can set :ref:`ansible_shell_executable<ansible_shell_executable>` to the path to a POSIX compatible shell. For
|
||||
instance, many Solaris hosts have a POSIX shell located at :file:`/usr/xpg4/bin/sh` so you can set
|
||||
this in inventory like so::
|
||||
|
||||
|
|
2
docs/templates/playbooks_keywords.rst.j2
vendored
2
docs/templates/playbooks_keywords.rst.j2
vendored
|
@ -1,3 +1,5 @@
|
|||
.. _playbook_keywords:
|
||||
|
||||
Playbook Keywords
|
||||
=================
|
||||
|
||||
|
|
|
@ -38,7 +38,6 @@ def main():
|
|||
|
||||
ignore_codes = [
|
||||
'literal-block-lex-error',
|
||||
'undefined-label',
|
||||
'reference-target-not-found',
|
||||
'not-in-toc-tree',
|
||||
]
|
||||
|
|
Loading…
Reference in a new issue