The KBase Narrative Interface
This is the repository for the KBase Narrative Interface.
The KBase Narrative Interface builds on the Jupyter Notebook and contains elements to interact with various KBase tools and data stores.
This document contains links to various documentation in the docs directory, with a brief description of each.
The Narrative sits on top of the Jupyter Notebook, so most of its architecture is a mirror of that. However, the Narrative's interaction with other KBase elements - namely the data stores and job running services - merits its own description. This will be ongoing (and evolving!), but a brief description of how a job gets run and registered is available here:
When deployed in production, the Narrative Interface is compiled into a Docker container. When a user logs in, they have their own instance provisioned for them through an Nginx proxy, which provides a temporary server-side Narrative environment only for that user. Any changes made to a Narrative get saved as part of KBase data stores, but any changes to the file system or the Narrative kernel (e.g. local variables) are lost when the user logs out and their Docker instance gets shut down.
Local installation (for developers)
Developing in the Narrative is easiest to do on either your local system or a local VM environment, not a fully deployed server. Instructions for setting up a local development environment are available here:
Server installation (for administrators)
If you want to set up your own Narrative server that uses the Docker framework, the below document will walk you through it. Once the server is set up, you only need to pull new code and build a new Docker image from it.
The document specifically describes how you would build the system on a Vagrant image, but is applicable to any Ubuntu-based system.
Testing will be composed of three components:
travis.ymlfile for Travis-CI testing
- a set of Selenium-based end-to-end tests that simulate browser interactions
We currently use a modified version of the famous Git flow workflow, described below:
The short version is this - all development work is done on the
develop branch. After some stability occurs, this gets merged to
staging for internal testing, then to
master where it is tagged and released to production.
So when you want to submit code, please make a pull request against