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.
: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::

@ -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…
Cancel
Save