diff options
| -rw-r--r-- | docs/enable_docu_gen.rst | 23 | ||||
| -rw-r--r-- | docs/main.rst | 8 | ||||
| -rw-r--r-- | docs/other_options_for_docu_gen.rst | 47 |
3 files changed, 42 insertions, 36 deletions
diff --git a/docs/enable_docu_gen.rst b/docs/enable_docu_gen.rst index 666b1074a..db746bb6c 100644 --- a/docs/enable_docu_gen.rst +++ b/docs/enable_docu_gen.rst @@ -1,7 +1,6 @@ How to setup the workflow of automatic documentation build for your project ---------------------------------------------------------------------------- - **Setup you repository and then clone locally**:: ssh-add your-ssh.key @@ -18,10 +17,17 @@ How to setup the workflow of automatic documentation build for your project /other-docus.rst /images/*.png|*.jpg +More details about the default structure you can find `here <https://wiki.opnfv.org/documentation>`_ at paragraph "How and where to store the document content files in your repository". **In order to obtain a nice .html & .pdf at then end you must write you documentation using reSt markup** -quick guide: http://docutils.sourceforge.net/docs/user/rst/quickref.html +quick guides: + +* http://docutils.sourceforge.net/docs/user/rst/quickref.html +* http://rest-sphinx-memo.readthedocs.org/en/latest/ReST.html +* http://www.math.uiuc.edu/~gfrancis/illimath/windows/aszgard_mini/movpy-2.0.0-py2.4.4/manuals/docutils/ref/rst/directives.html + +An `nice online editor <http://rst.ninjs.org/>`_ that will help you write reSt and see your changes live. After done editing you can copy the source document in the repository and follow the workflow. **Clone the releng repository so you can created jobs for JJB**:: @@ -54,13 +60,12 @@ example: cp releng/jjb/opnfvdocs/build-docu.sh releng/jjb/<your-project>/:: #the double {{ in file_cut="${{file%.*}}" is to escape jjb's yaml - **Edit <your-project>.yml**:: vi releng/jjb/<your-project>/<your-project>.yml -Make sure you have the job-templates set right +Make sure you have the job-templates set correctly as below. example: less releng/jjb/opnfvdocs/opnfvdocs.yml (pay extra attention at the "builder" sections):: @@ -101,6 +106,7 @@ Stage files:: git add build-docu.sh <project>.yml + Commit change with --signoff:: git commit --signoff @@ -111,9 +117,7 @@ Send code for review in Gerrit:: git review -v - - -**Create the documentation using the recommended structure in your repository and submit to gerrit for review** +Create the documentation using the recommended structure in your repository and submit to gerrit for review **Jenkins will take over and produce artifacts in the form of .html & .pdf** @@ -125,9 +129,8 @@ Jenkins has the proper packages installed in order to produce the artifacts. http://artifacts.opnfv.org/ -example: http://artifacts.opnfv.org/opnfvdocs/docs/enable_docu_gen.pdf -Here you can download the PDF version of this guide. +`Here you can download the PDF version <http://artifacts.opnfv.org/opnfvdocs/docs/enable_docu_gen.pdf>`_ of this guide. **Scrape content from html artifacts on wiki** @@ -142,6 +145,8 @@ example:: 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. + NOTE: diff --git a/docs/main.rst b/docs/main.rst index 49ac4329b..9292b13af 100644 --- a/docs/main.rst +++ b/docs/main.rst @@ -92,4 +92,12 @@ Proposed Release Schedule: - Iterative improvements to the processes and toolchains are expected on a release by release basis. +**Documentation tracking** + ++-----------------+---------------------------------------------------------+ +| Revision | ${GIT_REVISION} | ++-----------------+---------------------------------------------------------+ +| Build date | ${BUILD_ID} | ++-----------------+---------------------------------------------------------+ + diff --git a/docs/other_options_for_docu_gen.rst b/docs/other_options_for_docu_gen.rst index 94ba95e6e..2a050a0d3 100644 --- a/docs/other_options_for_docu_gen.rst +++ b/docs/other_options_for_docu_gen.rst @@ -3,7 +3,6 @@ Other options to generate documentation that we tested **Doxygen plugin -> HTML published plugin (html)/ LaTeX (pdf)** - Description: This was the first discovered method - html: using Doxygen plugin + HTML publisher @@ -17,23 +16,20 @@ 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 - - destination files are generated fast - - standard reStructuredText or Markdown + - 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 + - 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 - - latex suite is quite substantial in amount of packages and consumed space (around 1.2 GB) + - 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 - Input files: .xml @@ -42,22 +38,19 @@ Description: It represents the standard tool to generate Openstack documentation - 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 + - 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 - Cons: - - 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 + - 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 - Tested: roughly, functional tests only - - **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 - Input files: .rst as default @@ -66,18 +59,18 @@ Description: The easiest to install, the cleanest in matter of folder & files st - Pros: - - 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 - - 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 - - can be used also for source-code documentation, specially if you use Python + - 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 + - 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 + - can be used also for source-code documentation, specially if you use Python - Cons: - - 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) + - 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 |