Creating ReStructuredText

ReStructuredText markup conventions

For detailed information on ReStructuredText and how to best use the format, see:

Templates and Examples

Templates are available that capture the kinds of information useful for different types of projects and provide some examples of restructured text. We organize templates in the following way to:

  • help authors understand relationships between documents

  • keep the user audience context in mind when writing and

  • tailor sections for different kinds of projects.

Sections Represent a certain type of content. A section is provided in an project repository, to describe something about the characteristics, use, capability, etc. of things in that repository. A section may also be referenced from other sections and in other repositories. For example, an API specification provided in a project repository might be referenced to in a Platform API Reference Guide. The notes in the beginning of each section template provide additional detail about what is typically covered and where there may be references to the section.

Collections Are a set of sections that are typically provided for a particular type of project, repository, guide, reference manual, etc. For example, a collection for a platform component, an SDK, etc.

You can: browse the template collections and sections below; show source to look at the Restructured Text and Sphinx directives used.


Section examples are available here: Templates


In addition to these simple templates and examples there are many open source projects (e.g. Open Daylight, Open Stack) that are using Sphinx and Readthedocs where you may find examples to start with. Working with project teams we will continue to enhance templates here and capture frequently asked questions on the developer wiki question topic documentation.

Each project should:

  • decide what is relevant content

  • determine the best way to create/maintain it in the CI/CD process and

  • work with the documentation team to reference content from the master index and guides.

Consider options including filling in a template, identifying existing content that can be used as is or easily converted, and use of Sphinx directives/extensions to automatically generate restructured text from other source you already have.

Collection examples are available here: Templates

Index File

The index file must relatively reference your other rst files in that directory.

Here is an example index.rst :

Documentation Title

.. toctree::
   :maxdepth: 2


Source Files

Document source files have to be written in reStructuredText format (rst). Each file would be built as an html page.

Here is an example source rst file :

Chapter Title

Section Title

Subsection Title


Writing RST Markdown

See .

Hint: You can add html content that only appears in html output by using the ‘only’ directive with build type (‘html’ and ‘singlehtml’) for an ONAP document. But, this is not encouraged.

.. only:: html
    This line will be shown only in html version.

Creating Indices

Building an index for your Sphinx project is relatively simple. First, tell Sphinx that you want it to build an index by adding something like this after your TOC tree:

Indices and Search

* :ref:`genindex`
* :ref:`search`

Hint: Note that search was included here. It works out of the box with any Sphinx project, so you don’t need to do anything except include a reference to it in your index.rst file.

Now, to generate a index entry in your RST, do one of the following:

Some content that requires an :index:`index`.


.. index::
    single: myterm

Some header containing myterm

In the second case, Sphinx will create a link in the index to the paragraph that follows the index entry declaration.

When your project is built, Sphinx will generate an index page populated with the entries you created in the source RST.

These are simple cases with simple options. For more information about indexing with Sphinx, please see the official Sphinx documentation.

Jenkins Jobs

Verify Job

The verify job name is doc-{stream}-verify-rtd

Proposed changes in files in any repository with top level docs folder in the repository and RST files in below this folder will be verified by this job as part of a gerrit code review.


The contributing author and every reviewer on a gerrit code review should always review the Jenkins log before approving and merging a change. The log review should include:

  • Using a browser or other editor to search for a pattern in the console log that matches files in the patch set. This will quickly identify errors and warnings that are related to the patch set and repository being changed.

  • Using a browser to click on the html folder included in the log and preview how the proposed changes will look when published at Read The Docs. Small changes can be easily made in the patch set.

Merge Job

The merge job name is doc-{stream}-merge-rtd.

When a committer merges a patch that includes files matching the path described above, the doc project merge job will trigger an update at readthedocs. There may be some delay after the merge job completes until new version appears at Read The Docs.


One RST File

It is recommended that all rst content is validated by doc8 standards. To validate your rst files using doc8, install doc8.

sudo pip install doc8

doc8 can now be used to check the rst files. Execute as,

doc8 --ignore D000,D001 <file>

One Project

To test how the documentation renders in HTML, follow these steps:

Install virtual environment & create one.

sudo pip install virtualenv
virtualenv onap_docs

Activate onap_docs virtual environment.

source onap_docs/bin/activate


Virtual environment activation has to be performed before attempting to build documentation. Otherwise, tools necessary for the process might not be available.

Download a project repository.

git clone<project>

Download the doc repository.

git clone

Change directory to doc & install requirements.

cd doc
pip install -r etc/requirements.txt


Just follow the next step (copying from Doc project to your project) if that is your intention, otherwise skip it. Currently all projects should already have a file. Through the next step, this file and potential extensions in your project get overriden.

Copy the file to your project folder where RST files have been kept:

cp docs/ <path-to-project-folder>/<folder where are rst files>

Copy the static files to the project folder where RST files have been kept:

cp -r docs/_static/ <path-to-project-folder>/<folder where are rst files>

Build the documentation from within your project folder:

sphinx-build -b html <path-to-project-folder>/<folder where are rst files> <path-to-output-folder>

Your documentation shall be built as HTML inside the specified output folder directory.

You can use your Web Browser to open and check resulting html pages in the output folder.


Be sure to remove the, the static/ files and the output folder from the <project>/docs/. This is for testing only. Only commit the rst files and related content.

All Documentation

To build the all documentation under doc/, follow these steps:

Install tox.

sudo pip install tox

Download the DOC repository.

git clone

Build documentation using tox local environment & then open using any browser.

cd doc
tox -elocal
firefox docs/_build/html/index.html


Make sure to run tox -elocal and not just tox. This updates all submodule repositories that are integrated by the doc project.

There are additional tox environment options for checking External URLs and Spelling. Use the tox environment options below and then look at the output with the Linux more or similar command scan for output that applies to the files you are validating.

tox -elinkcheck
more <  docs/_build/linkcheck/output.txt

tox -espellcheck
more <  docs/_build/spellcheck/output.txt