summaryrefslogtreecommitdiffstats
path: root/docs/arno
diff options
context:
space:
mode:
authorUli Kleber <ulrich.kleber@huawei.com>2015-12-18 11:35:35 +0100
committerUli Kleber <ulrich.kleber@huawei.com>2015-12-18 15:01:17 +0100
commita7b9a43192c9d4c1245839e28eb5fc0748122aa3 (patch)
tree13b73b200307fd47cd82b1f4cf9c2a175ac5c32f /docs/arno
parentbe1b876c56adee484957f8a8f1c614eacdc828f5 (diff)
Fix Line Length etc for existing docs
Jira: DOCS-68 Fixing errors reported by the new tooling. platformoverview/index.rst will be fixed with the new platformoverview document (see separate patch) corrected importing logo images Change-Id: I08f73dcfeef4f2ff3a38a0372491a46798b4026b Signed-off-by: Uli Kleber <ulrich.kleber@huawei.com>
Diffstat (limited to 'docs/arno')
-rw-r--r--docs/arno/enable_docu_gen.rst37
-rw-r--r--docs/arno/index.rst2
-rw-r--r--docs/arno/opnfv-jjb-usage.rst5
-rw-r--r--docs/arno/opnfvdocs_info.rst12
-rw-r--r--docs/arno/other_options_for_docu_gen.rst29
5 files changed, 62 insertions, 23 deletions
diff --git a/docs/arno/enable_docu_gen.rst b/docs/arno/enable_docu_gen.rst
index 6f02cdacd..0340801d3 100644
--- a/docs/arno/enable_docu_gen.rst
+++ b/docs/arno/enable_docu_gen.rst
@@ -61,7 +61,8 @@ Enter the project settings::
**Create the verify & build scripts**
-The scripts are the same for most projects and if you need customizations copy them under your project in releng/jjb/<project>/::
+The scripts are the same for most projects and if you need customizations copy them
+under your project in releng/jjb/<project>/::
cp releng/jjb/opnfvdocs/build-docu.sh releng/jjb/<your-project>/
@@ -265,8 +266,11 @@ Variant 2 - custom
"node: master" is important here as all documentations are built on Jenkins master node for now.
-Please reffer to the releng repository for the correct indentation as JJB is very picky with those and also for the rest of the code that is missing in the example code and replaced by "...".
-Also you must have your documentation under docs/ in the repository or gsutil will fail to copy them; for customizations you might need to addapt build-docu.sh as we did for genesis project as different documents need to go into different places.
+Please reffer to the releng repository for the correct indentation as JJB is very picky
+with those and also for the rest of the code that is missing in the example code and replaced by "...".
+Also you must have your documentation under docs/ in the repository or gsutil will fail to copy them;
+for customizations you might need to addapt build-docu.sh as we did for genesis project
+as different documents need to go into different places.
Stage files example::
@@ -302,9 +306,16 @@ http://artifacts.opnfv.org/
**Scrape content from html artifacts on wiki**
-This section describes how the html build artifacts can be made visible on Wiki using he scrape method. DokuWiki speeds up browsing through the wiki by caching parsed files1). If a currently cached version of a document exists, this cached copy is delivered instead of parsing the data again. On editing and previewing no cache is used.
+This section describes how the html build artifacts can be made visible on Wiki using he scrape method.
+DokuWiki speeds up browsing through the wiki by caching parsed files1).
+If a currently cached version of a document exists, this cached copy is delivered
+instead of parsing the data again. On editing and previewing no cache is used.
-To prevent a page from ever being cached, use the NOCACHE tag anywhere in the document. This is useful if the page contains dynamic content, e.g. PHP code that pulls in outside information, where the caching would prevent the most recent information from being displayed. Same applies if documentation artifacts are rebuilt the cached version is shown if the NOCACHE tag is not used.
+To prevent a page from ever being cached, use the NOCACHE tag anywhere in the document.
+This is useful if the page contains dynamic content, e.g. PHP code that pulls in outside information,
+where the caching would prevent the most recent information from being displayed.
+Same applies if documentation artifacts are rebuilt the cached version is shown
+if the NOCACHE tag is not used.
https://www.dokuwiki.org/caching
@@ -317,15 +328,22 @@ example::
{{scrape>http://artifacts.opnfv.org/opnfvdocs/docs/enable_docu_gen.html}}
-Please try to write documentation as accurate and clear as possible as once reviewed and merged it will be automatically built and displayed on Wiki and everyone would apreciate a good written/nice looking guide.
+Please try to write documentation as accurate and clear as possible as once reviewed and
+merged it will be automatically built and displayed on Wiki and
+everyone would apreciate a good written/nice looking guide.
-If you want to see on wiki what code is scraped from the built artifacts click "Show pagesource" in the right (it will appear if you hover over the magnifier icon); this way you know what is written straight on wiki and what is embedded with "scrape". By knowing these details you will be able to prevent damages by manually updating wiki.
+If you want to see on wiki what code is scraped from the built artifacts click "Show pagesource" in the right
+(it will appear if you hover over the magnifier icon);
+this way you know what is written straight on wiki and what is embedded with "scrape".
+By knowing these details you will be able to prevent damages by manually updating wiki.
**Wiki update - how it works**
Edit Wiki page https://wiki.opnfv.org/<page> and look for {{scrape>http://artifacts.opnfv.org/<project>/<folder>/<doc-file>.html}}
-Click "Preview" and see if the change you submitted to Git is present; add a short description in "Edit summary" field, then click "Save" to update the page. This extra step is needed as Wiki does not auto update content for now.
+Click "Preview" and see if the change you submitted to Git is present;
+add a short description in "Edit summary" field, then click "Save" to update the page.
+This extra step is needed as Wiki does not auto update content for now.
**How to track documentation**
@@ -356,7 +374,8 @@ The image will be shown in both .html and .pdf resulting artifacts.
NOTE:
------
-In order to generate html & pdf documentation the needed packages are rst2pdf & python-docutils if the Jenkins is CentOS/RHEL; many variants have been tested but this is the cleanest solution found.
+In order to generate html & pdf documentation the needed packages are rst2pdf & python-docutils
+if the Jenkins is CentOS/RHEL; many variants have been tested but this is the cleanest solution found.
For html generation it also supports css styles if needed.
diff --git a/docs/arno/index.rst b/docs/arno/index.rst
index 994a20d51..f4bd59bba 100644
--- a/docs/arno/index.rst
+++ b/docs/arno/index.rst
@@ -3,7 +3,7 @@
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
-.. image:: ../etc/opnfv-logo.png
+.. image:: opnfv-logo.png
:height: 40
:width: 200
:alt: OPNFV
diff --git a/docs/arno/opnfv-jjb-usage.rst b/docs/arno/opnfv-jjb-usage.rst
index aabfda7ae..6b3bc93ce 100644
--- a/docs/arno/opnfv-jjb-usage.rst
+++ b/docs/arno/opnfv-jjb-usage.rst
@@ -32,7 +32,10 @@ Job Types
* Trigger: **remerge**
-The verify and merge jobs are retriggerable in Gerrit by simply leaving a comment with one of the keywords listed above. This is useful in case you need to re-run one of those jobs in case if build issues or something changed with the environment.
+The verify and merge jobs are retriggerable in Gerrit by simply leaving a comment
+with one of the keywords listed above.
+This is useful in case you need to re-run one of those jobs in case if build issues or
+something changed with the environment.
You can add below persons as reviewers to your patch in order to get it reviewed and submitted.
diff --git a/docs/arno/opnfvdocs_info.rst b/docs/arno/opnfvdocs_info.rst
index 1c78eeaf0..30bd4f035 100644
--- a/docs/arno/opnfvdocs_info.rst
+++ b/docs/arno/opnfvdocs_info.rst
@@ -22,7 +22,8 @@ Project description:
Scope:
-------
-- Set up a structure, and a template, for document development with source control (same as source code). Leveraging upstream documentation structure and tools.
+- Set up a structure, and a template, for document development with source control
+ (same as source code). Leveraging upstream documentation structure and tools.
- Following as close as possible the same contribution process & tools as our source code
- Structure OPNFV documentation logically
- Develop initial set of release documents:
@@ -33,7 +34,8 @@ Scope:
- API reference (if there is content in release 1)
- Interface specification (if there is content in release 1)
-- Provide language options for documentation where applicable: In first release English only, Wiki (via HTML scraping from Gerrit), and PDF.
+- Provide language options for documentation where applicable: In first release English only,
+ Wiki (via HTML scraping from Gerrit), and PDF.
- Provide tooling and processes for OPNFV projects to implement and follow for consistency
Dependencies:
@@ -41,7 +43,8 @@ Dependencies:
- All OPNFV projects participating in a release.
- Upstream project documentation to be referenced
-- Where there are external fora or standard development organization dependencies, list informative and normative references & specifications.
+- Where there are external fora or standard development organization dependencies,
+ list informative and normative references & specifications.
Committers and Contributors:
@@ -69,7 +72,8 @@ Committers and Contributors:
Description of roles in the documentation project:
- Committers (Editors): has overall responsibility of document structure, editing, style and toolchains
-- opnfvdocs contributors: individual section will have contributors who are domain experts in those areas, other contributors may simply help out working on the documentation and tools as needed.
+- opnfvdocs contributors: individual section will have contributors who are domain experts in those areas,
+ other contributors may simply help out working on the documentation and tools as needed.
- other projects: Committers will be responsible for maintaining documentation artifacts in project repositories.
Planned deliverables
diff --git a/docs/arno/other_options_for_docu_gen.rst b/docs/arno/other_options_for_docu_gen.rst
index ea6ad2598..596f39429 100644
--- a/docs/arno/other_options_for_docu_gen.rst
+++ b/docs/arno/other_options_for_docu_gen.rst
@@ -14,31 +14,39 @@ Description: This was the first discovered method
* Pros:
- standard tools: doxygen, html publisher, LaTeX suite
- - doxygen plugin available in Jenkins, you just need to install it; html publisher plugin available in Jenkins, you just need to install it
+ - doxygen plugin available in Jenkins, you just need to install it;
+ html publisher plugin available in Jenkins, you just need to install it
- destination files are generated fast
- standard reStructuredText or Markdown
* Cons:
- - takes some time to customize the output in matters of template, requires custom html header/footer
+ - takes some time to customize the output in matters of template,
+ requires custom html header/footer
- latex suite is quite substantial in amount of packages and consumed space (around 1.2 GB)
* Tested: roughly, functional tests only
**Maven & clouddocs-maven-plugin (actually used to generate openstack-manuals)**
-Description: It represents the standard tool to generate Openstack documentation manuals, uses maven, maven plugins, clouddocs-maven-plugins; location of finally generated files is the object of a small Bash script that will reside as Post-actions
+Description: It represents the standard tool to generate Openstack documentation manuals,
+uses maven, maven plugins, clouddocs-maven-plugins;
+location of finally generated files is the object of a small Bash script
+that will reside as Post-actions
* Input files: .xml
* Output: .html & .pdf
* Pros:
- quite easy for initial setup
- - uses openstack documentation generation flows as for openstack-manuals (clouddocs-maven-plugin), maven installs all you need generate the documentation
+ - uses openstack documentation generation flows as for
+ openstack-manuals (clouddocs-maven-plugin),
+ maven installs all you need generate the documentation
* Cons:
- - could be tricky to generate a custom layout, knowledge about Maven plugins required, .pom editing
+ - could be tricky to generate a custom layout,
+ knowledge about Maven plugins required, .pom editing
- dependent of multiple maven plugins
- input files are .xml and xml editing knowledge is required
@@ -46,7 +54,10 @@ Description: It represents the standard tool to generate Openstack documentation
**Sphinx & LaTeX suite**
-Description: The easiest to install, the cleanest in matter of folder & files structure, uses standard tools available in repositories; location of finally generated files is the object of a small Bash script that will reside as Post-actions
+Description: The easiest to install, the cleanest in matter of folder & files structure,
+uses standard tools available in repositories;
+location of finally generated files is the object of a small Bash script that will
+reside as Post-actions
* Input files: .rst as default
* Output: .html & .pdf
@@ -55,9 +66,11 @@ Description: The easiest to install, the cleanest in matter of folder & files st
- standard tools: Python Sphinx, LaTeX suite
- destination files are generated fast
- standard reStructuredText as default; other inputs can be configured
- - Sphinx's installation is very clean in matters of folder structure; the cleanest from all tested variants
+ - Sphinx's installation is very clean in matters of folder structure;
+ the cleanest from all tested variants
- latex suite is also easy to install via yum/apt and available in general repos
- - everyone is migration from other tools to Spinx lately; it provides more control and better looking documentation
+ - everyone is migration from other tools to Spinx lately;
+ it provides more control and better looking documentation
- can be used also for source-code documentation, specially if you use Python
* Cons: