1 .. This work is licensed under a Creative Commons Attribution 4.0
2 .. International License. http://creativecommons.org/licenses/by/4.0
3 .. Copyright 2017 AT&T Intellectual Property. All rights reserved.
8 Creating ReStructuredText
9 =========================
11 ReStructuredText markup conventions
12 -----------------------------------
13 For detailed information on ReStructuredText and how to best use the format,
16 - `ReStructured Text Primer <http://docutils.sourceforge.net/docs/user/rst/quickstart.html>`_
17 - `ReStructured Text Quick Reference <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_
20 Templates and Examples
21 ----------------------
22 Templates are available that capture the kinds of information
23 useful for different types of projects and provide some examples of
24 restructured text. We organize templates in the following way to:
26 - help authors understand relationships between documents
28 - keep the user audience context in mind when writing and
30 - tailor sections for different kinds of projects.
33 **Sections** Represent a certain type of content. A section
34 is **provided** in an project repository, to describe something about
35 the characteristics, use, capability, etc. of things in that repository.
36 A section may also be **referenced** from other sections and in
37 other repositories. For example, an API specification provided in a project
38 repository might be referenced to in a Platform API Reference Guide.
39 The notes in the beginning of each section template provide
40 additional detail about what is typically covered and where
41 there may be references to the section.
43 **Collections** Are a set of sections that are typically provided
44 for a particular type of project, repository, guide, reference manual, etc.
45 For example, a collection for a platform component, an SDK, etc.
47 You can: browse the template *collections* and *sections* below;
48 show source to look at the Restructured Text and Sphinx directives used.
53 Section examples are available here: :ref:`Templates<templates>`
58 In addition to these simple templates and examples
59 there are many open source projects (e.g. Open Daylight, Open Stack)
60 that are using Sphinx and Readthedocs where you may find examples
61 to start with. Working with project teams we will continue to enhance
62 templates here and capture frequently asked questions on the developer
63 wiki question topic `documentation <https://wiki.onap.org/questions/topics/16384055/documentation>`_.
67 - decide what is relevant content
69 - determine the best way to create/maintain it in the CI/CD process and
71 - work with the documentation team to reference content from the
72 master index and guides.
74 Consider options including filling in a template, identifying existing
75 content that can be used as is or easily converted, and use of Sphinx
76 directives/extensions to automatically generate restructured text
77 from other source you already have.
79 Collection examples are available here: :ref:`Templates<templates>`
83 It's pretty common to want to reference another location in the
84 ONAP documentation and it's pretty easy to do with
85 reStructuredText. This is a quick primer, more information is in the
86 `Sphinx section on Cross-referencing arbitrary locations
87 <http://www.sphinx-doc.org/en/stable/markup/inline.html>`_.
89 Within a single document, you can reference another section simply by::
91 This is a reference to `The title of a section`_
93 Assuming that somewhere else in the same file there a is a section
94 title something like::
96 The title of a section
97 ^^^^^^^^^^^^^^^^^^^^^^
99 It's typically better to use ``:ref:`` syntax and labels to provide
100 links as they work across files and are resilient to sections being
101 renamed. First, you need to create a label something like::
105 The title of a section
106 ^^^^^^^^^^^^^^^^^^^^^^
108 .. note:: The underscore (_) before the label is required.
110 Then you can reference the section anywhere by simply doing::
112 This is a reference to :ref:`a-label`
116 This is a reference to :ref:`a section I really liked <a-label>`
118 .. note:: When using ``:ref:``-style links, you don't need a trailing
121 Because the labels have to be unique, it usually makes sense to prefix
122 the labels with the project name to help share the label space, e.g.,
123 ``sfc-user-guide`` instead of just ``user-guide``.
128 The index file must relatively reference your other rst files in that directory.
130 Here is an example index.rst :
142 documentation-example
147 Document source files have to be written in reStructuredText format (rst).
148 Each file would be built as an html page.
150 Here is an example source rst file :
169 See http://sphinx-doc.org/rest.html .
172 You can add html content that only appears in html output by using the
173 'only' directive with build type
174 ('html' and 'singlehtml') for an ONAP document. But, this is not encouraged.
179 This line will be shown only in html version.
185 Building an index for your Sphinx project is relatively simple. First, tell Sphinx that
186 you want it to build an index by adding something like this after your TOC tree:
197 Note that search was included here. It works out of the box with any Sphinx project, so you
198 don't need to do anything except include a reference to it in your :code:`index.rst` file.
200 Now, to generate a index entry in your RST, do one of the following:
204 Some content that requires an :index:`index`.
213 Some header containing myterm
214 =============================
216 In the second case, Sphinx will create a link in the index to the paragraph that follows
217 the index entry declaration.
219 When your project is built, Sphinx will generate an index page populated with the entries
220 you created in the source RST.
222 These are simple cases with simple options. For more information about indexing with Sphinx,
223 please see the `official Sphinx documentation <http://www.sphinx-doc.org/en/stable/markup/misc.html>`_.
232 The verify job name is **doc-{stream}-verify-rtd**
234 Proposed changes in files in any repository with top level docs folder
235 in the repository and RST files in below this folder
236 will be verified by this job as part of a gerrit code review.
239 The contributing author and every reviewer on a gerrit code review
240 should always review the Jenkins log before approving and merging a
241 change. The log review should include:
243 * Using a browser or other editor to search for a pattern in the
244 *console log* that matches files in the patch set. This will quickly
245 identify errors and warnings that are related to the patch set and
246 repository being changed.
248 * Using a browser to click on the *html* folder included in the log
249 and preview how the proposed changes will look when published at
250 Read The Docs. Small changes can be easily made in the patch set.
255 The merge job name is **doc-{stream}-merge-rtd**.
257 When a committer merges a patch that includes files matching the
258 path described above, the doc project merge job will trigger an
259 update at readthedocs. There may be some delay after the merge job
260 completes until new version appears at Read The Docs.
267 It is recommended that all rst content is validated by `doc8 <https://pypi.python.org/pypi/doc8>`_ standards.
268 To validate your rst files using doc8, install doc8.
272 sudo pip install doc8
274 doc8 can now be used to check the rst files. Execute as,
278 doc8 --ignore D000,D001 <file>
284 To test how the documentation renders in HTML, follow these steps:
286 Install `virtual environment <https://pypi.org/project/virtualenv>`_ & create one.
290 sudo pip install virtualenv
293 Activate `onap_docs` virtual environment.
297 source onap_docs/bin/activate
299 .. note:: Virtual environment activation has to be performed before attempting to build documentation.
300 Otherwise, tools necessary for the process might not be available.
302 Download a project repository.
306 git clone http://gerrit.onap.org/r/<project>
308 Download the doc repository.
312 git clone http://gerrit.onap.org/r/doc
314 Change directory to doc & install requirements.
319 pip install -r etc/requirements.txt
323 Just follow the next step (copying conf.py from Doc project to your project)
324 if that is your intention, otherwise skip it. Currently all projects should already have a conf.py file.
325 Through the next step, this file and potential extensions in your project get overriden.
327 Copy the conf.py file to your project folder where RST files have been kept:
331 cp docs/conf.py <path-to-project-folder>/<folder where are rst files>
333 Copy the static files to the project folder where RST files have been kept:
337 cp -r docs/_static/ <path-to-project-folder>/<folder where are rst files>
339 Build the documentation from within your project folder:
343 sphinx-build -b html <path-to-project-folder>/<folder where are rst files> <path-to-output-folder>
345 Your documentation shall be built as HTML inside the
346 specified output folder directory.
348 You can use your Web Browser to open
349 and check resulting html pages in the output folder.
351 .. note:: Be sure to remove the `conf.py`, the static/ files and the output folder from the `<project>/docs/`. This is for testing only. Only commit the rst files and related content.
353 .. _building-all-documentation:
357 To build the all documentation under doc/, follow these steps:
359 Install `tox <https://pypi.org/project/tox>`_.
365 Download the DOC repository.
369 git clone http://gerrit.onap.org/r/doc
371 Build documentation using tox local environment & then open using any browser.
377 firefox docs/_build/html/index.html
379 .. note:: Make sure to run `tox -elocal` and not just `tox`.
380 This updates all submodule repositories that are integrated
383 There are additional tox environment options for checking External
384 URLs and Spelling. Use the tox environment options below and then
385 look at the output with the Linux `more` or similar command
386 scan for output that applies to the files you are validating.
391 more < docs/_build/linkcheck/output.txt
394 more < docs/_build/spellcheck/output.txt