docs/guides/onap-documentation/setting-up.rst

   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.
   4 .. Copyright 2022 ONAP
   5
   6 .. _setting-up:
   7
   8 Setting Up
   9 ==========
  10
  11 .. warning:: This guide describes the concept of using 'submodules' for
  12    documentation. Submodules are no longer supported and have been removed.
  13    This guide is partly outdated and needs an update.
  14
  15    The aggregation of individual project documentation to a coherent set of
  16    ONAP release documentation is now done in ReadTheDocs using the ONAP 'doc'
  17    project as its root.
  18
  19 ONAP documentation is stored in git repositories, changes are managed
  20 with gerrit reviews, and published documents generated when there is a
  21 change in any source used to build the documentation.
  22
  23 Authors create source for documents in reStructured Text (RST) that is
  24 rendered to HTML and published on Readthedocs.io.
  25 The developer Wiki or other web sites can reference these rendered
  26 documents directly allowing projects to easily maintain current release
  27 documentation.
  28
  29 Some initial set up is required to connect a project with
  30 the master document structure and enable automated publishing of
  31 changes as summarized in the following diagram and description below
  32 below.
  33
  34 .. seqdiag::
  35    :height: 700
  36    :width: 1000
  37
  38    seqdiag {
  39      DA [label = "Doc Project\nAuthor/Committer",   color=lightblue];
  40      DR [label = "Doc Gerrit Repo" ,                     color=pink];
  41      PR [label = "Other Project\nGerrit Repo",          color=pink ];
  42      PA [label = "Other Project\nAuthor/Committer", color=lightblue];
  43
  44      PA  ->   DR [label = "Add project repo as\ngit submodule" ];
  45      DR  ->   DA [label = "Review & Plan to\nIntegrate Content with\nTocTree Structure" ];
  46      DR  <--  DA [label = "Vote +2/Merge" ];
  47      PA  <--  DR [label = "Merge Notification" ];
  48      PA  ->   PR [label = "Create in project repo\ntop level directory and index.rst" ];
  49      PR  ->   DA [label = "Add as Reviewer" ];
  50      PR  <--  DA [label = "Approve and Integrate" ];
  51      PA  <--  PR [label = "Merge" ];
  52      }
  53
  54 Setup project repositories
  55 --------------------------
  56 These steps are performed for each project repository that
  57 provides documentation.
  58
  59 1. Set two variables that will be used in the subsequent steps.
  60 Set *reponame* to the project repository you are setting up
  61 just as it appears in the **Project Name** column of
  62 the Gerrit projects page.
  63 Set *lfid* to your Linux Foundation identity that you use to
  64 login to gerrit or for git clone requests over ssh.
  65
  66 .. code-block:: bash
  67
  68    reponame=
  69    lfid=
  70
  71 2. Add a directory in the doc project where your
  72 project will be included as a submodule and at least one reference
  73 from the doc project to the documentation index in your repository.
  74 The following sequence will do this over ssh. Please note that the
  75 reference to your project in *repolist.rst* should be considered
  76 temporary and removed when you reference it from more appropriate
  77 place.
  78
  79 .. caution::
  80
  81    If your access network restricts ssh, you will need to use equivalent
  82    git commands and HTTP Passwords as described `here <http://wiki.onap.org/x/X4AP>`_.
  83
  84 .. caution::
  85
  86    Don't replace ../ in *git submodule add* with any relative path on
  87    your local file system. It refers to the location of your repository
  88    on the server.
  89
  90 .. code-block:: bash
  91
  92    git clone ssh://$lfid@gerrit.onap.org:29418/doc
  93    cd doc
  94    mkdir -p `dirname docs/submodules/$reponame`
  95    git submodule add ../$reponame docs/submodules/$reponame.git
  96    git submodule init docs/submodules/$reponame.git
  97    git submodule update docs/submodules/$reponame.git
  98
  99    echo "   $reponame <../submodules/$reponame.git/docs/index>" >> docs/release/repolist.rst
 100
 101    git add .
 102    git commit -s
 103    git review
 104
 105 .. caution::
 106    Wait for the above change to be merged before any merge to the
 107    project repository that you have just added as a submodule.
 108    If the project repository added as submodule changes before the
 109    doc project merge, git may not automatically update the submodule
 110    reference on changes and/or the verify job will fail in the step below.
 111
 112
 113 3. Create a docs directory in your repository with
 114 an index.rst file.  The following sequence will complete the minimum
 115 required over ssh.  As you have time to convert or add new content you
 116 can update the index and add files under the docs folder.
 117
 118 .. hint::
 119    If you have additional content, you can include it by editing the
 120    index.rst file and/or adding other files before the git commit.
 121    Check "Templates and Examples" section in :ref:`setting-up` and
 122    :ref:`converting-to-rst` for more information.
 123
 124
 125 .. code-block:: bash
 126
 127    git clone ssh://$lfid@gerrit.onap.org:29418/$reponame
 128    cd $reponame
 129    mkdir docs
 130    echo ".. This work is licensed under a Creative Commons Attribution 4.0 International License.
 131
 132    TODO Add files to toctree and delete this header
 133    ------------------------------------------------
 134    .. toctree::
 135       :maxdepth: 1
 136
 137    " >  docs/index.rst
 138
 139    git add .
 140    git commit -s
 141    git review
 142
 143
 144 The diagram below illustrates what is accomplished in the setup steps
 145 above from the perspective of a file structure created for a local test,
 146 a jenkins verify job, and/or published release documentation including:
 147
 148 - ONAP gerrit project repositories,
 149
 150 - doc project repository master document index.rst, templates,
 151   configuration, and other documents
 152
 153 - submodules directory where other project repositories and
 154   directories/files are referenced
 155
 156 - file structure: directories (ellipses), files(boxes)
 157
 158 - references: directory/files (solid edges), git submodule
 159   (dotted edges), sphinx toctree (dashed edges)
 160
 161 .. graphviz::
 162
 163
 164    digraph docstructure {
 165    size="8,12";
 166    node [fontname = "helvetica"];
 167    // Align gerrit repos and docs directories
 168    {rank=same doc aaf aai reponame repoelipse vnfsdk vvp}
 169    {rank=same confpy release templates masterindex submodules otherdocdocumentelipse}
 170    {rank=same releasedocumentindex releaserepolist}
 171
 172    //Illustrate Gerrit Repos and provide URL/Link for complete repo list
 173    gerrit [label="gerrit.onap.org/r", href="https://gerrit.onap.org/r/#/admin/projects/" ];
 174    doc [href="https://gerrit.onap.org/r/gitweb?p=doc.git;a=tree"];
 175    gerrit -> doc;
 176    gerrit -> aaf;
 177    gerrit -> aai;
 178    gerrit -> reponame;
 179    gerrit -> repoelipse;
 180              repoelipse [label=". . . ."];
 181    gerrit -> vnfsdk;
 182    gerrit -> vvp;
 183
 184    //Show example of local reponame instance of component info
 185    reponame -> reponamedocsdir;
 186    reponamesm -> reponamedocsdir;
 187                     reponamedocsdir [label="docs"];
 188    reponamedocsdir -> repnamedocsdirindex;
 189                          repnamedocsdirindex [label="index.rst", shape=box];
 190
 191    //Show detail structure of a portion of doc/docs
 192    doc  -> docs;
 193    docs -> confpy;
 194            confpy [label="conf.py",shape=box];
 195    docs -> masterindex;
 196            masterindex [label="Master\nindex.rst", shape=box];
 197    docs -> release;
 198    docs -> templates;
 199    docs -> otherdocdocumentelipse;
 200            otherdocdocumentelipse [label="...other\ndocuments"];
 201    docs -> submodules
 202
 203    masterindex -> releasedocumentindex [style=dashed, label="sphinx\ntoctree\nreference"];
 204
 205    //Show submodule linkage to docs directory
 206    submodules -> reponamesm [style=dotted,label="git\nsubmodule\nreference"];
 207                  reponamesm [label="reponame.git"];
 208
 209    //Example Release document index that references component info provided in other project repo
 210    release -> releasedocumentindex;
 211               releasedocumentindex [label="index.rst", shape=box];
 212    releasedocumentindex -> releaserepolist [style=dashed, label="sphinx\ntoctree\nreference"];
 213         releaserepolist  [label="repolist.rst", shape=box];
 214    release -> releaserepolist;
 215    releaserepolist -> repnamedocsdirindex [style=dashed, label="sphinx\ntoctree\nreference"];
 216
 217    }
 218
 219 Branches in the DOC Project
 220 ---------------------------
 221
 222 The DOC project 'master' branch aggregates the 'latest' content
 223 from all ONAP project repositories contributing documentation into a
 224 single tree file structure as described in the previous section.  This
 225 branch is continuously integrated and deployed at Read The
 226 Docs as the 'latest' ONAP Documentation by:
 227
 228 * Jenkins doc-verify-rtd and doc-merge-rtd jobs triggered whenever patches on
 229   contributing repositories contain rst files at or below a top level
 230   'docs' folder.
 231
 232 * Subscription in the DOC project to changes in submodule repositories.
 233   These changes appear in the DOC project as commits with title
 234   'Updated git submodules' when a change to a contributing project
 235   repository is merged.  No DOC project code review occurs, only a
 236   submodule repository commit hash is updated to track the head of each
 237   contributing master branch.
 238
 239 For each ONAP named release the DOC project creates a branch with the
 240 release name.  The timing of the release branch is determined by
 241 work needed in the DOC project to prepare the release branch and the
 242 amount of change unrelated to the release in the master branch.
 243 For example contributing projects that create named release branches
 244 early to begin work on the next release and/or contributing projects
 245 to the master that are not yet part of the named release would result
 246 in an earlier named release branch to cleanly separate work to stabilize
 247 a release from other changes in the master branch.
 248
 249 A named release branch is integrated and deployed at Read The Docs
 250 as the 'named release' by aggregating content from contributing
 251 project repositories.  A contributing project repository can
 252 choose one of the following for the 'named release' branch:
 253
 254 * Remove the contributing project repository submodule and RST
 255   references when not part of the named release.
 256
 257 * Provide a commit hash or tag for the contributing project master
 258   branch to be used for the life of the release branch or until a
 259   request is submitted to change the commit hash or tag.
 260
 261 * Provide the commit hash for the head of a named release branch
 262   created in the contributing project repository.  This option
 263   may be appropriate if frequent changes are expected over the
 264   life of the named release and work the same way as the continuous
 265   integration and deployment described for the master branch.
 266
 267 The decision on option for each contributing project repository
 268 can be made or changed before the final release is approved.  The
 269 amount of change and expected differences between master and a
 270 named release branch for each repository should drive the choice of
 271 option and timing.
 272
 273 About GIT branches
 274 ------------------
 275
 276 GIT is a powerful tool allowing many actions, but without respecting some rules
 277 the GIT structure can be quickly hard to maintain.
 278
 279 Here are some conventions about GIT branches:
 280
 281   - ALWAYS create a local branch to edit or create any file. This local branch
 282     will be considered as a topic in Gerrit and allow contributors to
 283     work at the same time on the same project.
 284
 285   - 1 feature = 1 branch. In the case of documentation, a new chapter
 286     or page about a new code feature can be considered as a 'doc feature'
 287
 288   - 1 bug = 1 branch. In the case of documentation, a correction on an
 289     existing sentence can be considered as a 'doc bug'
 290
 291   - the master branch is considered as "unstable", containing new features that
 292     will converge to a stable situation for the release date.
 293
 294 The day of the release, the repository owner will create a new branch to
 295 fix the code and documentation. This will represent the 'stable' code of the
 296 release. In this context:
 297
 298   - NEVER push a new feature on a stable branch
 299
 300   - Only bug correction are authorized on a stable branch using
 301     cherry pick method
 302
 303 .. image:: media/git_branches.png