BE-678 Create online documentation

* Link updates, cleanup

Signed-off-by: nfrunza <nfrunza@gmail.com>
Change-Id: Iff4311ae115abbf782f2354164428c8c9641f473

.gitignore

@@ -30,3 +30,4 @@ ssl-certs/*.pem
 ssl-certs/*.csr
 0
 app/test/.nyc_output/
+docs/build/

README.md

@@ -7,6 +7,7 @@
 [rocketchat-image]:https://open.rocket.chat/images/join-chat.svg
 [![Build Status](https://jenkins.hyperledger.org/buildStatus/icon?job=blockchain-explorer-merge-x86_64)](https://jenkins.hyperledger.org/view/fabric/job/blockchain-explorer-merge-x86_64)
 [![CII Best Practice](https://bestpractices.coreinfrastructure.org/projects/2710/badge)](https://bestpractices.coreinfrastructure.org/projects/2710)
+[![Documentation Status](https://readthedocs.org/projects/blockchain-explorer/badge/?version=latest)](https://blockchain-explorer.readthedocs.io/en/latest/?badge=latest)
 
 <!-- badges -->
 
@@ -324,6 +325,10 @@ On another terminal:
 - `./main.sh clean`
     - to clean the /node_modules, client/node_modules client/build, client/coverage, app/test/node_modules
    directories
+- `./main.sh test`
+    - to test REST API, and UI components
+    - to generate code coverage report
+
 
 Or
 
@@ -334,7 +339,7 @@ Or
 - `npm run test`
 - `cd client/`
 - `npm install`
-- `npm test -- -u --coverage`
+- `npm run test:ci -- -u --coverage`
 - `npm run build`
 
 <a name="Config-https-Hyperledger-Explorer" />

client/test/E2E-TEST-README.md

@@ -46,7 +46,7 @@ client/test/
 
 +-- docker-compose.yaml // Definition for Selenium Hub/Browser container service
 
-+-- e2e-setup.sh        // Bring up fabric network and explorer 
++-- e2e-setup.sh        // Bring up fabric network and explorer
 
 +-- wdio.conf.js        // webdriverIO configuration
 

devenv/submit_cr.rst

@@ -0,0 +1,228 @@
+Submitting your first change request (CR)
+-----------------------------------------
+
+We are using
+`Gerrit <https://gerrit.hyperledger.org/r/admin/repos/blockchain-explorer>`__ to
+manage code contributions and reviews. If you are unfamiliar with Gerrit,
+please review this :doc:`document <Gerrit/gerrit>` before proceeding.
+
+.. note:: Gerrit has a reputation of having a clunky user experience. However,
+          the Google team has been working on improving this, and they have
+          added a "New UI" option that will allow you to work with their new
+          and much improved UX. See the link at the bottom of the Fabric
+          Gerrit page, linked above.
+
+          .. image:: images/NewGerritUI.png
+
+Setting up your SSH key
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Before you can submit a change set for review, you will need to register your
+public SSH key. Login to
+`Gerrit <https://gerrit.hyperledger.org>`__ with your
+:doc:`LFID <Gerrit/lf-account>`, and click on your name in the upper
+right-hand corner of your browser window and then click 'Settings'.
+
+.. image:: images/Settings.png
+    :width: 300px
+
+In the left-hand margin, you should see a link for 'SSH Public Keys'.
+
+.. image:: images/SSHKeys.png
+    :width: 200px
+
+Press the ``Add Key...`` button
+
+.. image:: images/AddSSH1.png
+    :width: 400px
+
+Copy-n-paste your `public SSH key <https://help.github.com/articles/generating-an-ssh-key/>`__ into
+the window and press 'Add'.
+
+.. image:: images/AddSSH2.png
+    :width: 600px
+
+
+Clone your project
+~~~~~~~~~~~~~~~~~~
+
+First step is to clone your project to your laptop or development server.
+Navigate your browser to the Gerrit `Projects <https://gerrit.hyperledger.org/r/#/admin/projects/>`__
+page and scroll down to the ``blockchain-explorer`` project.
+
+.. image:: images/lf-sandbox.png
+    :width: 500px
+
+The project page will provide you with the full git clone command needed to
+clone the project. Select the ``clone with commit-msg hook`` option and copy the
+command to the clipboard.
+
+.. image:: images/GitCloneCmd.png
+    :width: 600px
+
+Now, in a terminal window on your laptop, paste and run the command. e.g.
+
+.. code::
+
+   git clone "ssh://<LFID>@gerrit.hyperledger.org:29418/blockchain-explorer" && scp -p -P 29418 <LFID>@gerrit.hyperledger.org:hooks/commit-msg "blockchain-explorer/.git/hooks/"
+
+Checkout a development branch
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now that you have cloned the repository, change directory to the ``lf-sandbox``
+directory. Now let's make a change. First, let's create a new branch in which
+to work:
+
+.. code::
+
+   git checkout -b <newbranchname>
+
+Now let's modify a file. Pick a file, any file and make a change. You can also
+add a new file or delete an existing file. Don't be shy, this is just a
+sandbox.
+
+Committing your change
+~~~~~~~~~~~~~~~~~~~~~~
+
+Once you've made your change, check to see what the current status is.
+
+.. code::
+
+   git status
+   On branch foo
+   Untracked files:
+    (use "git add <file>..." to include in what will be committed)
+
+	 README.md
+
+   nothing added to commit but untracked files present (use "git add" to track)
+
+Now let's add the changed file to the list of files tracked by git.
+
+.. code::
+
+   git add .
+
+Now let's commit that change.
+
+.. code::
+
+   git commit -s
+
+This will open up an editing session using your favorite command-line editor
+where you will fill in a commit message. Add a commit message.
+
+.. note:: Note that for the Hyperledger Fabric project(s) we would have a
+          title line that includes the JIRA number of the issue to which the
+          change request applies. Please review the
+          :doc:`guidelines <Gerrit/changes>` for change requests.
+
+.. code::
+
+   FAB-1234
+
+   I made a change
+
+   Signed-off-by: John Doe <john.doe@example.com>
+
+   # Please enter the commit message for your changes. Lines starting
+   # with '#' will be ignored, and an empty message aborts the commit.
+   # On branch foo
+   # Changes to be committed:
+   #       new file:   README.md
+   #
+
+Submitting your change request
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once you have saved the commit message, you can push the change request
+to Gerrit. Here, we have a couple of options.
+
+The first option is to use the full git syntax.
+
+.. code::
+
+   git push origin HEAD:refs/for/master
+
+This will yield results something like the following:
+
+.. code::
+
+   Counting objects: 3, done.
+   Delta compression using up to 4 threads.
+   Compressing objects: 100% (2/2), done.
+   Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
+   Total 3 (delta 1), reused 0 (delta 0)
+   remote: Resolving deltas: 100% (1/1)
+   remote: Processing changes: new: 1, refs: 1, done
+   remote: Missing issue-id in commit message
+   remote: Commit 539d9a1fe036f332db87d37b49cea705bdf6e432 not associated to any issue
+   remote:
+   remote: Hint: insert one or more issue-id anywhere in the commit message.
+   remote:       Issue-ids are strings matching ([A-Z][A-Z0-9]{1,9}-\d+)
+   remote:       and are pointing to existing tickets on its-jira Issue-Tracker
+   remote:
+   remote: New Changes:
+   remote:   https://gerrit.hyperledger.org/r/16157 I made a change
+   remote:
+   To ssh://gerrit.hyperledger.org:29418/lf-sandbox
+    * [new branch]      HEAD -> refs/for/master
+
+The second option,
+`git review <https://www.mediawiki.org/wiki/Gerrit/git-review>`__ simplifies
+things a bit. The link above will provide info on how to install and setup
+``git-review``.
+
+Once installed and configured, you can submit your change with ``git review``.
+
+::
+
+    $ git review
+
+
+Check that your change request is validated by the CI process
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To ensure stability of the code and limit possible regressions, we use
+a Continuous Integration (CI) process based on Jenkins which triggers
+a build on several platforms and runs tests against every change
+request being submitted. It is your responsibility to check that your
+CR passes these tests. No CR will ever be merged if it fails the
+tests and you shouldn't expect anybody to pay attention to your CRs
+until they pass the CI tests.
+
+To check on the status of the CI process, simply look at your CR on
+Gerrit, following the URL that was given to you as the result of the
+push in the previous step. The History section at the bottom of the
+page will display a set of actions taken by "Hyperledger Jobbuilder"
+corresponding to the CI process being executed.
+
+Upon completion, "Hyperledger Jobbuilder" will add to the CR a *+1
+vote* if successful and a *-1 vote* otherwise.
+
+In case of failure, explore the logs linked from the CR History. If
+you spot a problem with your CR and want to modify it, proceed to the
+following section.
+
+If you see nothing wrong with your CR it might be that the CI process
+simply failed for some reason unrelated to your change. In that case
+you may want to restart the CI process by posting a reply to your CR
+with the simple content "reverify".  Check the `CI management page
+<https://github.com/hyperledger/ci-management/blob/master/docs/source/fabric_ci_process.rst>`__
+for additional information and options on this.
+
+Modifying your change request
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you need to update your patch, say to address a review comment, or to fix
+something affecting CI, you can commit revised changes with
+
+.. code::
+
+   git commit --amend
+
+and then repeat the ``git review`` or full syntax as before. Then
+check the results of the CI process that gets triggered as a result.
+
+Should you have further questions, please don't hesitate to ask on the mailing
+list or rocket chat.

docs/Makefile

@@ -0,0 +1,19 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+SOURCEDIR     = source
+BUILDDIR      = build
+
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: help Makefile
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

docs/README.rst

@@ -0,0 +1,98 @@
+
+<!-- (SPDX-License-Identifier: CC-BY-4.0) -->  <!-- Ensure there is a newline before, and after, this line -->
+
+## Hyperledger Explorer
+
+- [Project Lifecycle](project_lifecycle/README.md)
+- [Hyperledger Explorer functionalities](project_functionalities/README.md)
+
+
+
+# Documentation README
+
+## Introduction
+
+This document contains information on how the Hyperledger Explorer documentation is
+built and published as well as a few conventions one should be aware of
+before making changes to the doc.
+
+The crux of the documentation is written in
+[reStructuredText](http://docutils.sourceforge.net/rst.html) which is
+converted to HTML using [Sphinx](http://www.sphinx-doc.org/en/stable/).
+The HTML is then published on http://hyperledger-fabric.readthedocs.io
+which has a hook so that any new content that goes into `docs/source`
+on the main repository will trigger a new build and publication of the
+doc.
+
+## Conventions
+
+* Source files are in RST format and found in the `docs/source` directory.
+* The main entry point is index.rst, so to add something into the Table
+  of Contents you would simply modify that file in the same manner as
+  all of the other topics. It's very self-explanatory once you look at
+  it.
+* Relative links should be used whenever possible. The preferred
+  syntax for this is: :doc:\`anchor text &lt;relativepath&gt;\`
+  <br/>Do not put the .rst suffix at the end of the filepath.
+* For non RST files, such as text files, MD or YAML files, link to the
+  file on github, like this one for instance:
+  https://github.com/hyperledger/blockchain-explorer/blob/master/README.md
+
+Notes: The above means we have a dependency on the github mirror
+repository. Relative links are unfortunately not working on github
+when browsing through a RST file.
+
+## Setup
+
+Making any changes to the documentation will require you to test your
+changes by building the doc in a way similar to how it is done for
+production. There are two possible setups you can use to do so:
+setting up your own staging repo and publication website, or building
+the docs on your machine. The following sections cover both options:
+
+### Building the docs on your machine
+
+Here are the quick steps to achieve this on a local machine without
+depending on ReadTheDocs, starting from the main fabric
+directory. Note: you may need to adjust depending on your OS.
+
+```
+sudo pip install Sphinx
+sudo pip install sphinx_rtd_theme
+sudo pip install recommonmark==0.4.0
+cd fabric/docs # Be in this directory. Makefile sits there.
+make html
+```
+
+This will generate all the html files in `docs/build/html` which you can
+then start browsing locally using your browser. Every time you make a
+change to the documentation you will of course need to rerun `make
+html`.
+
+In addition, if you'd like, you may also run a local web server with the following commands (or equivalent depending on your OS):
+
+- Ubuntu
+
+```
+sudo apt-get install apache2
+cd build/html
+sudo cp -r * /var/www/html/
+```
+
+- MacOS
+
+```
+brew install apache2
+cd build/html
+sudo cp -r * /usr/local/var/www
+```
+
+
+
+You can then access the html files at `http://localhost/index.html`.
+
+<a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>.
+
+
+.. Licensed under Creative Commons Attribution 4.0 International License
+   https://creativecommons.org/licenses/by/4.0/