[release_2.1] Fix incorrect formatting in docs (ansible#930)

Fix incorrect formatting in docs

RST uses double backticks to indicate verbatim formatting but there were many places that used only a single backtick, which is correct for Markdown.
Also change the documentation config to catch these errors in CI.

Reviewed-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>
Reviewed-by: Sam Doran <sdoran@redhat.com>
Reviewed-by: David Shrewsbury <None>
Reviewed-by: None <None>.
(cherry picked from commit 6d99dae)

Co-authored-by: Sam Doran <sdoran@redhat.com>

ansible_runner/__main__.py

@@ -548,11 +548,9 @@ def add_args_to_parser(parser, args):
     """
     Traverse a tuple of argments to add to a parser
 
-    :param parser: Instance of a parser, subparser, or argument group
-    :type sys_args: argparse.ArgumentParser
+    :param argparse.ArgumentParser parser: Instance of a parser, subparser, or argument group
 
-    :param args: Tuple of tuples, format ((arg1, arg2), {'kwarg1':'val1'},)
-    :type sys_args: tuple
+    :param tuple args: Tuple of tuples, format ((arg1, arg2), {'kwarg1':'val1'},)
 
     :returns: None
     """
@@ -566,8 +564,7 @@ def main(sys_args=None):
     When the ```ansible-runner``` command is executed, this function
     is the main entry point that is called and executed.
 
-    :param sys_args: List of arguments to be parsed by the parser
-    :type sys_args: list
+    :param list sys_args: List of arguments to be parsed by the parser
 
     :returns: an instance of SystemExit
     :rtype: SystemExit

ansible_runner/runner.py

@@ -546,7 +546,7 @@ def kill_container(self):
     @classmethod
     def handle_termination(cls, pid, pidfile=None, is_cancel=True):
         '''
-        Internal method to terminate a subprocess spawned by `pexpect` representing an invocation of runner.
+        Internal method to terminate a subprocess spawned by ``pexpect`` representing an invocation of runner.
 
         :param pid:       the process id of the running the job.
         :param pidfile:   the daemon's PID file

ansible_runner/utils/__init__.py

@@ -402,17 +402,17 @@ def ensure_str(s, encoding='utf-8', errors='strict'):
     """
     Copied from six==1.12
 
-    Coerce *s* to `str`.
+    Coerce *s* to ``str``.
 
     For Python 2:
 
-      - `unicode` -> encoded to `str`
-      - `str` -> `str`
+      - ``unicode`` -> encoded to ``str``
+      - ``str`` -> ``str``
 
     For Python 3:
 
-      - `str` -> `str`
-      - `bytes` -> decoded to `str`
+      - ``str`` -> ``str``
+      - ``bytes`` -> decoded to ``str``
     """
     if not isinstance(s, (text_type, binary_type)):
         raise TypeError("not expecting type '%s'" % type(s))
@@ -428,7 +428,10 @@ def sanitize_container_name(original_name):
     Docker and podman will only accept certain characters in container names
     This takes a given name from user-specified values and replaces the
     invalid characters so it can be used in docker/podman CLI commands
+
+    :param str original_name: Container name containing potentially invalid characters
     """
+
     return re.sub('[^a-zA-Z0-9_-]', '_', text_type(original_name))
 
 
@@ -456,10 +459,10 @@ def cli_mounts():
 
 def santize_json_response(data):
     '''
-    Removes warning message from response message emitted by ansible
+    Removes warning message from response message emitted by Ansible
     command line utilities.
-    :param action: The string data to be santizied
-    :type action: str
+
+    :param str data: The string data to be sanitized
     '''
     start_re = re.compile("{(.|\n)*", re.MULTILINE)
     data = start_re.search(data).group().strip()

ansible_runner/utils/base64io.py

@@ -306,7 +306,7 @@ def readline(self, limit=-1):
             Because the source that this reads from may not contain any OEL characters, we
             read "lines" in chunks of length ``io.DEFAULT_BUFFER_SIZE``.
 
-        :type limit: int
+        :param int limit: Maximum number of bytes to read
         :rtype: bytes
         """
         return self.read(limit if limit > 0 else io.DEFAULT_BUFFER_SIZE)
@@ -318,7 +318,7 @@ def readlines(self, hint=-1):
         ``hint`` can be specified to control the number of lines read: no more lines will
         be read if the total size (in bytes/characters) of all lines so far exceeds hint.
 
-        :type hint: int
+        :param int hint: Number of lines to read
         :returns: Lines of data
         :rtype: list of bytes
         """

docs/ansible_runner.callbacks.rst

@@ -10,12 +10,10 @@ ansible_runner.callbacks.awx_display module
 .. automodule:: ansible_runner.callbacks.awx_display
     :members:
     :undoc-members:
-    :show-inheritance:
 
 ansible_runner.callbacks.minimal module
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. automodule:: ansible_runner.callbacks.minimal
     :members:
     :undoc-members:
-    :show-inheritance:

docs/ansible_runner.config.rst

@@ -0,0 +1,10 @@
+ansible_runner.config package
+================================
+
+Submodules
+----------
+
+ansible_runner.config.runner module
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. autoclass:: ansible_runner.config.runner.RunnerConfig

docs/ansible_runner.display_callback.rst

@@ -26,15 +26,13 @@ ansible_runner.display_callback.minimal module
 .. automodule:: ansible_runner.display_callback.minimal
     :members:
     :undoc-members:
-    :show-inheritance:
 
 ansible_runner.display_callback.module module
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. automodule:: ansible_runner.display_callback.module
     :members:
     :undoc-members:
-    :show-inheritance:
 
 
 Module contents
@@ -43,4 +41,3 @@ Module contents
 .. automodule:: ansible_runner.display_callback
     :members:
     :undoc-members:
-    :show-inheritance:

docs/ansible_runner.rst

@@ -7,6 +7,7 @@ Subpackages
 .. toctree::
 
     ansible_runner.callbacks
+    ansible_runner.config
     ansible_runner.display_callback
 
 Submodules

docs/conf.py

@@ -25,6 +25,8 @@ def _get_version():
     return '.'.join(version_parts)
 
 
+nitpicky = True
+default_role = 'any'  # This catches single backticks (incorrectly) used for inline code formatting
 project = 'ansible-runner'
 copyright = f'2018-{datetime.datetime.today().year}, Red Hat, Inc'
 author = 'Red Hat, Inc.'

docs/execution_environments.rst

@@ -34,17 +34,17 @@ Using Execution Environments from Protected Registries
 When a job is run that uses an execution environment container image from a private/protected registry,
 you will first need to authenticate to the registry.
 
-If you are running the job manually via `ansible-runner run`, logging in on the command line via
-`podman login` first is a method of authentication. Alternatively, creating a `container_auth_data`
-dictionary with the keys `host`, `username`, and `password` and putting that in the job's `env/settings`
+If you are running the job manually via ``ansible-runner run``, logging in on the command line via
+``podman login`` first is a method of authentication. Alternatively, creating a ``container_auth_data``
+dictionary with the keys ``host``, ``username``, and ``password`` and putting that in the job's ``env/settings``
 file is another way to ensure a successful pull of a protected execution environment container image.
 Note that this involves listing sensitive information in a file which will not automatically get cleaned
 up after the job run is complete.
 
 When running a job remotely via AWX or Ansible Tower, Ansible Runner can pick up the authentication
-information from the Container Registry Credential that was provided by the user. The `host`,
-`username`, `password`, and `verify_ssl` inputs from the credential are passed into Ansible Runner via the `container_auth_data`
-dictionary as key word arguments into a `json` file which gets deleted at the end of the job run (even if
+information from the Container Registry Credential that was provided by the user. The ``host``,
+``username``, ``password``, and ``verify_ssl`` inputs from the credential are passed into Ansible Runner via the ``container_auth_data``
+dictionary as key word arguments into a ``json`` file which gets deleted at the end of the job run (even if
 the job was canceled/interrupted), enabling the bypassing of sensitive information from any potentially
 persistent job-related files.
 

docs/external_interface.rst

@@ -40,13 +40,13 @@ pip::
 
 In order to configure it, you can provide details in the Runner Settings file (see :ref:`runnersettings`):
 
-* `runner_http_url`: The url to receive the ``POST``
-* `runner_http_headers`: Headers to send along with the request.
+* ``runner_http_url``: The url to receive the ``POST``
+* ``runner_http_headers``: Headers to send along with the request.
 
 The plugin also supports unix file-based sockets with:
 
-* `runner_http_url`: The path to the unix socket
-* `runner_http_path`: The path that will be included as part of the request to the socket
+* ``runner_http_url``: The path to the unix socket
+* ``runner_http_path``: The path that will be included as part of the request to the socket
 
 Some of these settings are also available as environment variables:
 

docs/intro.rst

@@ -111,7 +111,7 @@ by providing a yaml or json formatted file with a regular expression and a value
 .. warning::
 
     Current **Ansible Runner** does not validate the command line arguments passed using this method so it is up to the playbook writer to provide a valid set of options
-    The command line options provided by this method are lower priority than the ones set by **Ansible Runner**.  For instance, this will not override `inventory` or `limit` values.
+    The command line options provided by this method are lower priority than the ones set by **Ansible Runner**.  For instance, this will not override ``inventory`` or ``limit`` values.
 
 **Ansible Runner** gathers command line options provided here as a string and supplies them to the **Ansible Process** itself. This file should contain the arguments to be added, for example::
 

docs/python_interface.rst

@@ -84,8 +84,8 @@ response when finished. While running the command within the container the curre
 :meth:`ansible_runner.interface.get_inventory`
 
 When called, this function will take the inputs, and execute the ansible-inventory command to return the inventory releated information based on the action.
-If `action` is `list` it will return all the applicable configuration options for ansible, for `host` action it will return information
-of a single host andf for `graph` action it will return the inventory. The exectuin will be in the foreground and return a tuple of output and error
+If ``action`` is ``list`` it will return all the applicable configuration options for ansible, for ``host`` action it will return information
+of a single host andf for ``graph`` action it will return the inventory. The exectuin will be in the foreground and return a tuple of output and error
 response when finished. While running the command within the container the current local working diretory will be volume mounted within the container.
 
 ``get_ansible_config()`` helper function
@@ -94,8 +94,8 @@ response when finished. While running the command within the container the curre
 :meth:`ansible_runner.interface.get_ansible_config`
 
 When called, this function will take the inputs, and execute the ansible-config command to return the Ansible configuration releated information based on the action.
-If `action` is `list` it will return all the hosts related information including the host and group variables, for `dump` action it will return the enitre active configuration
-and it can be customized to return only the changed configuration value by settingg the `only_changed` boolean parameter to `True`. For `view` action it will return the
+If ``action`` is ``list`` it will return all the hosts related information including the host and group variables, for ``dump`` action it will return the enitre active configuration
+and it can be customized to return only the changed configuration value by settingg the ``only_changed`` boolean parameter to ``True``. For ``view`` action it will return the
 view of the active configuration file. The exectuin will be in the foreground and return a tuple of output and error response when finished.
 While running the command within the container the current local working diretory will be volume mounted within the container.
 
@@ -116,7 +116,7 @@ properties:
 -----------------
 
 The :class:`Runner <ansible_runner.runner.Runner>` object contains a property :attr:`ansible_runner.runner.Runner.stdout` which will return an open file
-handle containing the ``stdout`` of the **Ansible** process.
+handle containing the `stdout` of the **Ansible** process.
 
 ``Runner.stderr``
 -----------------
@@ -146,8 +146,8 @@ will return an open file handle containing the ``stderr`` of the **Ansible** pro
 ``Runner.event_handler``
 ------------------------
 
-A function passed to `__init__` of :class:`Runner <ansible_runner.runner.Runner>`, this is invoked every time an Ansible event is received. You can use this to
-inspect/process/handle events as they come out of Ansible. This function should return `True` to keep the event, otherwise it will be discarded.
+A function passed to ``__init__`` of :class:``Runner <ansible_runner.runner.Runner>``, this is invoked every time an Ansible event is received. You can use this to
+inspect/process/handle events as they come out of Ansible. This function should return ``True`` to keep the event, otherwise it will be discarded.
 
 ``Runner.cancel_callback``
 --------------------------
@@ -170,11 +170,11 @@ This function will be called immediately before the **Runner** event loop finish
 A function passed to ``__init__`` of :class:`Runner <ansible_runner.runner.Runner>` and to the :meth:`ansible_runner.interface.run` interface functions.
 This function will be called any time the ``status`` changes, expected values are:
 
-* `starting`: Preparing to start but hasn't started running yet
-* `running`: The **Ansible** task is running
-* `canceled`: The task was manually canceled either via callback or the cli
-* `timeout`: The timeout configured in Runner Settings was reached (see :ref:`runnersettings`)
-* `failed`: The **Ansible** process failed
+* ``starting``: Preparing to start but hasn't started running yet
+* ``running``: The **Ansible** task is running
+* ``canceled``: The task was manually canceled either via callback or the cli
+* ``timeout``: The timeout configured in Runner Settings was reached (see :ref:`runnersettings`)
+* ``failed``: The **Ansible** process failed
 
 Usage examples
 --------------
@@ -309,5 +309,5 @@ The helper methods are just one possible entrypoint, extending the classes used
 
 Show:
 
-* How :class:`Runner Config <ansible_runner.runner_config.RunnerConfig>` is used and how overriding the methods and behavior can work
+* How :class:`Runner Config <ansible_runner.config.runner.RunnerConfig>` is used and how overriding the methods and behavior can work
 * Show how custom cancel and status callbacks can be supplied.

docs/remote_jobs.rst

@@ -16,27 +16,27 @@ The following command illustrates how the three phases work together::
 
   $ ansible-runner transmit ./demo -p test.yml | ansible-runner worker | ansible-runner process ./demo
 
-In this example, the `ansible-runner transmit` command is given a private data directory of `./demo` and told to select
-the `test.yml` playbook from it.  Instead of executing the playbook as `ansible-runner run` would do, the data dir
-and command line parameters are converted to a compressed binary stream that is emitted as stdout.  The `transmit`
-command generally takes the same command line parameters as the `run` command.
+In this example, the ``ansible-runner transmit`` command is given a private data directory of ``./demo`` and told to select
+the ``test.yml`` playbook from it.  Instead of executing the playbook as ``ansible-runner run`` would do, the data dir
+and command line parameters are converted to a compressed binary stream that is emitted as stdout.  The ``transmit``
+command generally takes the same command line parameters as the ``run`` command.
 
-The `ansible-runner worker` command accepts this stream, runs the playbook, and generates a new compressed binary
+The ``ansible-runner worker`` command accepts this stream, runs the playbook, and generates a new compressed binary
 stream of the resulting job events and artifacts.
-This command optionally accepts the `--private-data-dir` option.
-If provided, it will extract the contents sent from `ansible-runner transmit` into that directory.
+This command optionally accepts the ``--private-data-dir`` option.
+If provided, it will extract the contents sent from ``ansible-runner transmit`` into that directory.
 
-The `ansible-runner process` command accepts the result stream from the worker, and fires all the normal callbacks
+The ``ansible-runner process`` command accepts the result stream from the worker, and fires all the normal callbacks
 and does job event processing.  In the command above, this results in printing the playbook output and saving
-artifacts to the data dir.  The `process` command takes a data dir as a parameter, to know where to save artifacts.
+artifacts to the data dir.  The ``process`` command takes a data dir as a parameter, to know where to save artifacts.
 
 Cleanup of Resources Used by Jobs
 ---------------------------------
 
 The transmit and process commands do not offer any automatic deletion of the
 private data directory or artifacts, because these are how the user interacts with runner.
 
-When running `ansible-runner worker`, if no `--private-data-dir` is given,
+When running ``ansible-runner worker``, if no ``--private-data-dir`` is given,
 it will extract the contents to a temporary directory which is deleted at the end of execution.
 If the ``--private-data-dir`` option is given, then the directory will persist after the run finishes
 unless the ``--delete`` flag is also set. In that case, the private data directory will be deleted before execution if it exists and also removed after execution.
@@ -47,17 +47,17 @@ The following command offers out-of-band cleanup.
 
 This would assure that old directories that fit the file glob "/tmp/foo_*" are deleted,
 which would could be used to assure cleanup of paths created by commands like
-`ansible-runner worker --private_data_dir=/tmp/foo_3`, for example.
-NOTE: see the `--grace-period` option, which sets the time window.
+``ansible-runner worker --private_data_dir=/tmp/foo_3``, for example.
+NOTE: see the ``--grace-period`` option, which sets the time window.
 
-This command also takes a `--remove-images` option to run the podman or docker `rmi` command.
+This command also takes a ``--remove-images`` option to run the podman or docker ``rmi`` command.
 There is otherwise no automatic cleanup of images used by a run,
-even if `container_auth_data` is used to pull from a private container registry.
-To be sure that layers are deleted as well, the `--image-prune` flag is necessary.
+even if ``container_auth_data`` is used to pull from a private container registry.
+To be sure that layers are deleted as well, the ``--image-prune`` flag is necessary.
 
 Python API
 ----------
 
-Python code importing Ansible Runner can make use of these facilities by setting the `streamer` parameter to
-`ansible_runner.interface.run`.  This parameter can be set to `transmit`, `worker` or `process` to invoke
+Python code importing Ansible Runner can make use of these facilities by setting the ``streamer`` parameter to
+``ansible_runner.interface.run``.  This parameter can be set to ``transmit``, ``worker`` or ``process`` to invoke
 each of the three stages.  Other parameters are as normal in the CLI.