1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00

Minor fixes to Developer Docs (#28302)

* Grammar and formatting corrections

Indent JSON code example.
Double backticks for inline code examples.

* Remove trailing spaces

* CI fixes
This commit is contained in:
Sam Doran 2017-08-16 20:56:53 -04:00 committed by Matt Davis
parent 2960f5feac
commit b7aa38c0d8
2 changed files with 22 additions and 19 deletions

View file

@ -96,7 +96,7 @@ Version 1.1 of the metadata
+++++++++++++++++++++++++++
Structure
`````````
^^^^^^^^^
.. code-block:: python
@ -107,7 +107,7 @@ Structure
}
Fields
``````
^^^^^^
:metadata_version: An “X.Y” formatted string. X and Y are integers which
define the metadata format version. Modules shipped with Ansible are
@ -399,13 +399,15 @@ Put your completed module file into the ``lib/ansible/modules/$CATEGORY/`` direc
run the command: ``make webdocs``. The new 'modules.html' file will be
built in the ``docs/docsite/_build/html/$MODULENAME_module.html`` directory.
In order to speed up the build process, you can limit the documentation build to
In order to speed up the build process, you can limit the documentation build to
only include modules you specify, or no modules at all. To do this, run the command:
``MODULES=$MODULENAME make webdocs``. The ``MODULES`` environment variable
accepts a comma-separated list of module names. To skip building
documentation for all modules, specify a non-existent module name, for example:
``MODULES=none make webdocs``.
You may also build a single page of the entire docsite. From ``ansible/docs/docsite`` run ``make htmlsingle rst=[relative path to the .rst file]``, for example: ``make htmlsingle rst=dev_guide/developing_modules_documenting.rst``
To test your documentation against your ``argument_spec`` you can use ``validate-modules``. Note that this option isn't currently enabled in Shippable due to the time it takes to run.
.. code-block:: bash

View file

@ -4,7 +4,7 @@ Ansible Module Development Walkthrough
======================================
In this section, we will walk through developing, testing, and debugging an Ansible module.
In this section, we will walk through developing, testing, and debugging an Ansible module.
What's covered in this section:
@ -51,7 +51,9 @@ working on a whole new file. Here is an example:
- Navigate to the directory that you want to develop your new module
in. E.g. ``$ cd lib/ansible/modules/cloud/azure/``
- Create your new module file: ``$ touch my_new_test_module.py``
- Paste this simple into the new module file: (explanation in comments)::
- Paste this example code into the new module file: (explanation in comments)
.. code:: python
#!/usr/bin/python
@ -187,14 +189,14 @@ that can run locally.
- Create an arguments file in ``/tmp/args.json`` with the following
content: (explanation below)
.. code:: json
.. code:: json
{
"ANSIBLE_MODULE_ARGS": {
"name": "hello",
"new": true
}
}
{
"ANSIBLE_MODULE_ARGS": {
"name": "hello",
"new": true
}
}
- If you are using a virtual environment (highly recommended for
development) activate it: ``$ . venv/bin/activate``
@ -205,7 +207,7 @@ that can run locally.
This should be working output that resembles something like the
following:
::
.. code:: json
{"changed": true, "state": {"original_message": "hello", "new_message": "goodbye"}, "invocation": {"module_args": {"name": "hello", "new": true}}}
@ -221,7 +223,6 @@ Ansible playbook.
- Create a playbook in any directory: ``$ touch testmod.yml``
- Add the following to the new playbook file::
---
- name: test my new module
connection: local
hosts: localhost
@ -238,11 +239,11 @@ Ansible playbook.
- Run the playbook and analyze the output: ``$ ansible-playbook ./testmod.yml``
Debugging (local)
=================
=================
If you want to break into a module and step through with the debugger, locally running the module you can do:
- Set a breakpoint in the module: `import pdb; pdb.set_trace()`
- Set a breakpoint in the module: ``import pdb; pdb.set_trace()``
- Run the module on the local machine: ``$ python -m pdb ./my_new_test_module.py ./args.json``
Debugging (remote)
@ -282,7 +283,7 @@ Going Further
If you are starting new development or fixing a bug, create a new branch:
``$ git checkout -b my-new-branch``.
``$ git checkout -b my-new-branch``.
If you are planning on contributing
back to the main Ansible repository, fork the Ansible repository into
@ -293,7 +294,7 @@ submit a pull request to the Ansible repository.
If you want to submit a new module to the upstream Ansible repo, be sure
to run through sanity checks first. For example:
``$ ansible-test sanity -v --docker --python 2.7 MODULE_NAME``
``$ ansible-test sanity -v --docker --python 2.7 MODULE_NAME``
Note that this example requires docker to be installed and running. If you'd rather not use a
container for this, you can choose to use ``--tox`` instead of ``--docker``.
@ -311,5 +312,5 @@ use the ``#ansible`` channel.
Credit
======
Thank you to Thomas Stringer (`@tstring <https://github.com/tstringer>`_) for contributing source
Thank you to Thomas Stringer (`@tstring <https://github.com/tstringer>`_) for contributing source
material for this topic.