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.
9 Some initial set up is required to connect a project with
10 the master document structure and enable automated publishing of
11 changes as summarized in the following diagram and description below
19 DA [label = "Doc Project\nAuthor/Committer", color=lightblue];
20 DR [label = "Doc Gerrit Repo" , color=pink];
21 PR [label = "Other Project\nGerrit Repo", color=pink ];
22 PA [label = "Other Project\nAuthor/Committer", color=lightblue];
24 PA -> DR [label = "Add project repo as\ngit submodule" ];
25 DR -> DA [label = "Review & Plan to\nIntegrate Content with\nTocTree Structure" ];
26 DR <-- DA [label = "Vote +2/Merge" ];
27 PA <-- DR [label = "Merge Notification" ];
28 PA -> PR [label = "Create in project repo\ntop level directory and index.rst" ];
29 PR -> DA [label = "Add as Reviewer" ];
30 PR <-- DA [label = "Approve and Integrate" ];
31 PA <-- PR [label = "Merge" ];
34 Setup project repositories(s)
35 -----------------------------
36 These steps are performed for each project repository that
37 provides documentation.
39 First let's set two variables that will be used in the subsequent steps.
40 Set *reponame* to the project repository you are setting up
41 just as it appears in the **Project Name** column of
42 the Gerrit projects page.
43 Set *lfid* to your Linux Foundation identity that you use to
44 login to gerrit or for git clone requests over ssh.
51 The next step is to add a directory in the doc project where your
52 project will be included as a submodule and at least one reference
53 from the doc project to the documentation index in your repository.
54 The following sequence will do this over ssh.
58 If your access network restricts ssh, you will need to use equivalent
59 git commands and HTTP Passwords as described `here <http://wiki.onap.org/x/X4AP>`_.
63 Don't replace ../ in *git submodule add* with any relative path on
64 your local file system. It refers to the location of your repository
69 git clone ssh://$lfid@gerrit.onap.org:29418/doc
71 mkdir -p `dirname docs/submodules/$reponame`
72 git submodule add ../$reponame docs/submodules/$reponame.git
73 git submodule init docs/submodules/$reponame.git
74 git submodule update docs/submodules/$reponame.git
76 echo " $reponame <../submodules/$reponame.git/docs/index>" >> docs/release/repolist.rst
83 Wait for the above change to be merged before any merge to the
84 project repository that you have just added as a submodule.
85 If the project repository added as submodule changes before the
86 doc project merge, git may not automatically update the submodule
87 reference on changes and/or the verify job will fail in the step below.
90 The last step is to create a docs directory in your repository with
91 an index.rst file. The following sequence will complete the minimum
92 required over ssh. As you have time to convert or add new content you
93 can update the index and add files under the docs folder.
96 If you have additional content, you can include it by editing the
97 index.rst file and/or adding other files before the git commit.
98 See `Templates and Examples`_ below and :ref:`converting-to-rst`
104 git clone ssh://$lfid@gerrit.onap.org:29418/$reponame
107 echo ".. This work is licensed under a Creative Commons Attribution 4.0 International License.
109 TODO Add files to toctree and delete this header
110 ------------------------------------------------
121 The diagram below illustrates what is accomplished in the setup steps
122 above from the perspective of a file structure created for a local test,
123 a jenkins verify job, and/or published release documentation including:
125 - ONAP gerrit project repositories,
127 - doc project repository master document index.rst, templates,
128 configuration, and other documents
130 - submodules directory where other project repositories and
131 directories/files are referenced
133 - file structure: directories (ellipses), files(boxes)
135 - references: directory/files (solid edges), git submodule
136 (dotted edges), sphinx toctree (dashed edges)
141 digraph docstructure {
143 node [fontname = "helvetica"];
144 // Align gerrit repos and docs directories
145 {rank=same doc aaf aai reponame repoelipse vnfsdk vvp}
146 {rank=same confpy release templates masterindex submodules otherdocdocumentelipse}
147 {rank=same releasedocumentindex releaserepolist}
149 //Illustrate Gerrit Repos and provide URL/Link for complete repo list
150 gerrit [label="gerrit.onap.org/r", href="https://gerrit.onap.org/r/#/admin/projects/" ];
151 doc [href="https://gerrit.onap.org/r/gitweb?p=doc.git;a=tree"];
156 gerrit -> repoelipse;
157 repoelipse [label=". . . ."];
161 //Show example of local reponame instance of component info
162 reponame -> reponamedocsdir;
163 reponamesm -> reponamedocsdir;
164 reponamedocsdir [label="docs"];
165 reponamedocsdir -> repnamedocsdirindex;
166 repnamedocsdirindex [label="index.rst", shape=box];
168 //Show detail structure of a portion of doc/docs
171 confpy [label="conf.py",shape=box];
173 masterindex [label="Master\nindex.rst", shape=box];
176 docs -> otherdocdocumentelipse;
177 otherdocdocumentelipse [label="...other\ndocuments"];
180 masterindex -> releasedocumentindex [style=dashed, label="sphinx\ntoctree\nreference"];
182 //Show submodule linkage to docs directory
183 submodules -> reponamesm [style=dotted,label="git\nsubmodule\nreference"];
184 reponamesm [label="reponame.git"];
186 //Example Release document index that references component info provided in other project repo
187 release -> releasedocumentindex;
188 releasedocumentindex [label="index.rst", shape=box];
189 releasedocumentindex -> releaserepolist [style=dashed, label="sphinx\ntoctree\nreference"];
190 releaserepolist [label="repolist.rst", shape=box];
191 release -> releaserepolist;
192 releaserepolist -> repnamedocsdirindex [style=dashed, label="sphinx\ntoctree\nreference"];
196 Branches in the DOC Project
197 ---------------------------
199 The DOC project 'master' branch aggregates the 'latest' content
200 from all ONAP project repositories contributing documentation into a
201 single tree file structure as described in the previous section. This
202 branch is continuously integrated and deployed at Read The
203 Docs as the 'latest' ONAP Documentation by:
205 * Jenkins doc-verify-rtd and doc-merge-rtd jobs triggered whenever patches on
206 contributing repositories contain rst files at or below a top level
209 * Subscription in the DOC project to changes in submodule repositories.
210 These changes appear in the DOC project as commits with title
211 'Updated git submodules' when a change to a contributing project
212 repository is merged. No DOC project code review occurs, only a
213 submodule repository commit hash is updated to track the head of each
214 contributing master branch.
216 For each ONAP named release the DOC project creates a branch with the
217 release name. The timing of the release branch is determined by
218 work needed in the DOC project to prepare the release branch and the
219 amount of change unrelated to the release in the master branch.
220 For example contributing projects that create named release branches
221 early to begin work on the next release and/or contributing projects
222 to the master that are not yet part of the named release would result
223 in an earlier named release branch to cleanly separate work to stabilize
224 a release from other changes in the master branch.
226 A named release branch is integrated and deployed at Read The Docs
227 as the 'named release' by aggregating content from contributing
228 project repositories. A contributing project repository can
229 choose one of the following for the 'named release' branch:
231 * Remove the contributing project repository submodule and RST
232 references when not part of the named release.
234 * Provide a commit hash or tag for the contributing project master
235 branch to be used for the life of the release branch or until a
236 request is submitted to change the commit hash or tag.
238 * Provide the commit hash for the head of a named release branch
239 created in the contributing project repository. This option
240 may be appropriate if frequent changes are expected over the
241 life of the named release and work the same way as the continuous
242 integration and deployment described for the master branch.
244 The decision on option for each contributing project repository
245 can be made or changed before the final release is approved. The
246 amount of change and expected differences between master and a
247 named release branch for each repository should drive the choice of
253 GIT is a powerful tool allowing many actions, but without respecting some rules
254 the GIT structure can be quickly hard to maintain.
256 Here are some conventions about GIT branches:
258 - ALWAYS create a local branch to edit or create any file. This local branch
259 will be considered as a topic in Gerrit and allow contributors to
260 work at the same time on the same project.
262 - 1 feature = 1 branch. In the case of documentation, a new chapter
263 or page about a new code feature can be considered as a 'doc feature'
265 - 1 bug = 1 branch. In the case of documentation, a correction on an
266 existing sentence can be considered as a 'doc bug'
268 - the master branch is considered as "unstable", containing new features that
269 will converge to a stable situation for the release date.
271 The day of the release, the repository owner will create a new branch to
272 fix the code and documentation. This will represent the 'stable' code of the
273 release. In this context:
275 - NEVER push a new feature on a stable branch
277 - Only bug correction are authorized on a stable branch using
280 .. image:: git_branches.png
282 Creating Restructured Text
283 ==========================
285 Templates and Examples
286 ----------------------
287 Templates are available that capture the kinds of information
288 useful for different types of projects and provide some examples of
289 restructured text. We organize templates in the following way to:
291 - help authors understand relationships between documents
293 - keep the user audience context in mind when writing and
295 - tailor sections for different kinds of projects.
298 **Sections** Represent a certain type of content. A section
299 is **provided** in an project repository, to describe something about
300 the characteristics, use, capability, etc. of things in that repository.
301 A section may also be **referenced** from other sections and in
302 other repositories. For example, an API specification provided in a project
303 repository might be referenced to in a Platform API Reference Guide.
304 The notes in the beginning of each section template provide
305 additional detail about what is typically covered and where
306 there may be references to the section.
308 **Collections** Are a set of sections that are typically provided
309 for a particular type of project, repository, guide, reference manual, etc.
310 For example, a collection for a platform component, an SDK, etc.
312 You can: browse the template *collections* and *sections* below;
313 show source to look at the Restructured Text and Sphinx directives used;
314 copy the source either from a browser window or by downloading the
315 file in raw form from
316 the `gerrit doc repository <https://gerrit.onap.org/r/gitweb?p=doc.git;a=tree;f=docs/templates;/>`_ and
317 then add them to your repository docs folder and index.rst.
327 ../../../templates/sections/*
337 ../../../templates/collections/*
341 In addition to these simple templates and examples
342 there are many open source projects (e.g. Open Daylight, Open Stack)
343 that are using Sphinx and Readthedocs where you may find examples
344 to start with. Working with project teams we will continue to enhance
345 templates here and capture frequently asked questions on the developer
346 wiki question topic `documentation <https://wiki.onap.org/questions/topics/16384055/documentation>`_.
350 - decide what is relevant content
352 - determine the best way to create/maintain it in the CI/CD process and
354 - work with the documentation team to reference content from the
355 master index and guides.
357 Consider options including filling in a template, identifying existing
358 content that can be used as is or easily converted, and use of Sphinx
359 directives/extensions to automatically generate restructured text
360 from other source you already have.
364 It's pretty common to want to reference another location in the
365 ONAP documentation and it's pretty easy to do with
366 reStructuredText. This is a quick primer, more information is in the
367 `Sphinx section on Cross-referencing arbitrary locations
368 <http://www.sphinx-doc.org/en/stable/markup/inline.html#ref-role>`_.
370 Within a single document, you can reference another section simply by::
372 This is a reference to `The title of a section`_
374 Assuming that somewhere else in the same file there a is a section
375 title something like::
377 The title of a section
378 ^^^^^^^^^^^^^^^^^^^^^^
380 It's typically better to use ``:ref:`` syntax and labels to provide
381 links as they work across files and are resilient to sections being
382 renamed. First, you need to create a label something like::
386 The title of a section
387 ^^^^^^^^^^^^^^^^^^^^^^
389 .. note:: The underscore (_) before the label is required.
391 Then you can reference the section anywhere by simply doing::
393 This is a reference to :ref:`a-label`
397 This is a reference to :ref:`a section I really liked <a-label>`
399 .. note:: When using ``:ref:``-style links, you don't need a trailing
402 Because the labels have to be unique, it usually makes sense to prefix
403 the labels with the project name to help share the label space, e.g.,
404 ``sfc-user-guide`` instead of just ``user-guide``.
411 It is recommended that all rst content is validated by `doc8 <https://pypi.python.org/pypi/doc8>`_ standards.
412 To validate your rst files using doc8, install doc8.
416 sudo pip install doc8
418 doc8 can now be used to check the rst files. Execute as,
422 doc8 --ignore D000,D001 <file>
428 To test how the documentation renders in HTML, follow these steps:
430 Install virtual environment.
434 sudo pip install virtualenv
436 Download a project repository.
440 git clone http://gerrit.onap.org/r/<project>
442 Download the doc repository.
446 git clone http://gerrit.onap.org/r/doc
448 Change directory to doc & install requirements.
453 sudo pip install -r etc/requirements.txt
455 Copy the conf.py file to your project folder where RST files have been kept:
459 cp docs/conf.py <path-to-project-folder>/<folder where are rst files>
461 Copy the static files to the project folder where RST files have been kept:
465 cp -r docs/_static/ <path-to-project-folder>/<folder where are rst files>
467 Build the documentation from within your project folder:
471 sphinx-build -b html <path-to-project-folder>/<folder where are rst files> <path-to-output-folder>
473 Your documentation shall be built as HTML inside the
474 specified output folder directory.
476 You can use your Web Browser to open
477 and check resulting html pages in the output folder.
479 .. 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.
481 .. _building-all-documentation:
485 To build the all documentation under doc/, follow these steps:
487 Install virtual environment.
491 sudo pip install virtualenv
492 cd /local/repo/path/to/project
494 Download the DOC repository.
498 git clone http://gerrit.onap.org/r/doc
500 Build documentation using tox local environment & then open using any browser.
506 firefox docs/_build/html/index.html
508 .. note:: Make sure to run `tox -elocal` and not just `tox`.
509 This updates all submodule repositories that are integrated
512 There are additional tox environment options for checking External
513 URLs and Spelling. Use the tox environment options below and then
514 look at the output with the Linux `more` or similar command
515 scan for output that applies to the files you are validating.
520 more < docs/_build/linkcheck/output.txt
523 more < docs/_build/spellcheck/output.txt