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
pull/37324/head
Alicia Cozine 7 years ago committed by GitHub
parent 7db5ce2c86
commit c8a9b411bc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -87,7 +87,7 @@ The following topics will discuss how to develop and work with modules:
Checklist for contributing your module to Ansible. Checklist for contributing your module to Ansible.
:doc:`testing` :doc:`testing`
Developing unit and integration tests. 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). Adding Python 3 support to modules (all new modules must be Python-2.6 and Python-3.5 compatible).
:doc:`developing_modules_in_groups` :doc:`developing_modules_in_groups`
A guide for partners wanting to submit multiple modules. 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 * 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 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, * Modules must have a metadata section. For the vast majority of new modules,
the metadata should look exactly like this: 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 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, to fallback on environment variables for default values. If you do that,
be sure to use non-generic environment variables (like be sure to use non-generic environment variables (like
:envvar:`API_<MODULENAME>_USERNAME`). Using generic environment variables :code:`API_<MODULENAME>_USERNAME`). Using generic environment variables
like :envvar:`API_USERNAME` would conflict between modules. like :code:`API_USERNAME` would conflict between modules.
Windows modules checklist 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 To be able to view the arguments as passed by Ansible to the module follow
these steps. 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. - 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-``. - Navigate to ``%TEMP%\..``. It should contain a folder starting with ``ansible-tmp-``.
- Inside this folder, open the PowerShell script for the module. - 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_plugins
developing_inventory developing_inventory
developing_core developing_core
developing_python3 developing_python_3
developing_api developing_api
developing_rebasing developing_rebasing
testing testing

@ -29,7 +29,7 @@ into the ``connection_plugins`` directory.
Using Connection Plugins 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. 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. 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] [defaults]
strategy=linear 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 - hosts: all
strategy: debug strategy: debug

@ -195,7 +195,7 @@ is likely the problem. There are several workarounds:
solaris1 ansible_remote_tmp=$HOME/.ansible/tmp 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 instance, many Solaris hosts have a POSIX shell located at :file:`/usr/xpg4/bin/sh` so you can set
this in inventory like so:: this in inventory like so::

@ -1,3 +1,5 @@
.. _playbook_keywords:
Playbook Keywords Playbook Keywords
================= =================

@ -38,7 +38,6 @@ def main():
ignore_codes = [ ignore_codes = [
'literal-block-lex-error', 'literal-block-lex-error',
'undefined-label',
'reference-target-not-found', 'reference-target-not-found',
'not-in-toc-tree', 'not-in-toc-tree',
] ]

Loading…
Cancel
Save