Merge pull request #11 from fabric-composer/develop

Merge develop into master

.gitignore

@@ -35,3 +35,6 @@ jspm_packages
 
 # Optional REPL history
 .node_repl_history
+
+# idea
+.idea

.gitmodules

@@ -0,0 +1,10 @@
+[submodule "packages/composer-runtime-hlf/vendor/github.com/hyperledger/fabric"]
+	path = packages/composer-runtime-hlf/vendor/github.com/hyperledger/fabric
+	url = https://github.com/hyperledger/fabric.git
+	branch = v0.6
+[submodule "packages/composer-runtime-hlf/vendor/gopkg.in/sourcemap.v1"]
+	path = packages/composer-runtime-hlf/vendor/gopkg.in/sourcemap.v1
+	url = https://gopkg.in/sourcemap.v1.git
+[submodule "packages/composer-runtime-hlf/vendor/github.com/robertkrimen/otto"]
+	path = packages/composer-runtime-hlf/vendor/github.com/robertkrimen/otto
+	url = https://github.com/robertkrimen/otto

.travis.yml

@@ -2,25 +2,40 @@ language: node_js
 node_js:
     - '4'
     - '6'
+matrix:
+    include:
+        - env: SYSTEST=embedded
+        - env: SYSTEST=web
+        - env: SYSTEST=hlf SYSTEST_HLF=hlf
+          sudo: required
+          services:
+            - docker
+        - env: SYSTEST=hlf SYSTEST_HLF=ibm
+          sudo: required
+          services:
+            - docker
 dist: trusty
 before_install: |
     set -ev
+    set -o pipefail
     npm install -g npm
-    npm config set @ibm:registry https://npm-registry.whitewater.ibm.com
-    npm config set //npm-registry.whitewater.ibm.com/:_authToken ${NPM_TOKEN}
+    npm install -g @alrra/travis-scripts
     wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
     sudo dpkg -i google-chrome*.deb
+    wget -q -O - https://packages.cloudfoundry.org/debian/cli.cloudfoundry.org.key | sudo apt-key add -
+    echo "deb http://packages.cloudfoundry.org/debian stable main" | sudo tee /etc/apt/sources.list.d/cloudfoundry-cli.list
+    sudo apt-get update && sudo apt-get install cf-cli
 install: |
     set -ev
+    set -o pipefail
     npm install 2>&1 | tee
-script: |
-    set -ev
-    export DISPLAY=:99.0
-    sh -e /etc/init.d/xvfb start
-    npm test 2>&1 | tee
+script: ./.travis/script.sh
 deploy:
     provider: script
-    script: npm run deploy 2>&1 | tee
+    script: ./.travis/deploy.sh
     skip_cleanup: true
     on:
         all_branches: true
+cache:
+    directories:
+        - $HOME/.npm

.travis/deploy.sh

@@ -0,0 +1,79 @@
+#!/bin/bash
+
+# Exit on first error, print all commands.
+set -ev
+set -o pipefail
+
+# Grab the Concerto directory.
+DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )/.." && pwd )"
+
+# Check that this is the right node.js version.
+if [ "${TRAVIS_NODE_VERSION}" != "" -a "${TRAVIS_NODE_VERSION}" != "4" ]; then
+    echo Not executing as not running primary node.js version.
+    exit 0
+fi
+
+# Check that this is not the system tests.
+if [ "${SYSTEST}" != "" ]; then
+    echo Not executing as running system tests.
+    exit 0
+fi
+
+# Check that this is the main repository.
+if [[ "${TRAVIS_REPO_SLUG}" != fabric-composer* ]]; then
+    echo "Skipping deploy; wrong repository slug."
+    exit 0
+fi
+
+# Set the NPM access token we will use to publish.
+npm config set registry https://registry.npmjs.org/
+npm config set //registry.npmjs.org/:_authToken ${NPM_TOKEN}
+
+# Set the GitHub deploy key we will use to publish.
+set-up-ssh --key "$encrypted_568b95f14ac3_key" \
+           --iv "$encrypted_568b95f14ac3_iv" \
+           --path-encrypted-key ".travis/github_deploy_key.enc"
+
+# Change from HTTPS to SSH.
+./.travis/fix_github_https_repo.sh
+
+# Push the code to npm.
+if [ -z "${TRAVIS_TAG}" ]; then
+
+    # Set the prerelease version.
+    npm run pkgstamp
+
+    # Publish with unstable tag. These are development builds.
+    echo "Pushing with tag unstable"
+    lerna exec --ignore 'composer-systests' -- npm publish --tag=unstable 2>&1 | tee
+
+else
+
+    # Publish with latest tag (default). These are release builds.
+    echo "Pushing with tag latest"
+    lerna exec --ignore 'composer-systests' -- npm publish 2>&1 | tee
+
+    # Push to public Bluemix.
+    pushd ${DIR}/packages/composer-ui/dist
+    touch Staticfile
+    cf login -a https://api.ng.bluemix.net -u ${CF_USERNAME} -p ${CF_PASSWORD} -o ${CF_ORGANIZATION} -s ${CF_SPACE}
+    cf push fabric-composer
+    popd
+
+    # Configure the Git repository and clean any untracked and unignored build files.
+    git config user.name "Travis CI"
+    git config user.email "[email protected]"
+    git checkout -b develop
+    git reset --hard
+    git clean -d -f
+
+    # Bump the version number.
+    npm run pkgbump
+    export VERSION=$(node -e "console.log(require('${DIR}/package.json').version)")
+
+    # Add the version number changes and push them to Git.
+    git add .
+    git commit -m "Automatic version bump to ${VERSION}"
+    git push origin develop
+
+fi

.travis/fix_github_https_repo.sh

@@ -0,0 +1,33 @@
+#/bin/bash
+#-- Script to automate https://help.github.com/articles/why-is-git-always-asking-for-my-password
+
+REPO_URL=`git remote -v | grep -m1 '^origin' | sed -Ene's#.*(https://[^[:space:]]*).*#\1#p'`
+if [ -z "$REPO_URL" ]; then
+  echo "-- ERROR:  Could not identify Repo url."
+  echo "   It is possible this repo is already using SSH instead of HTTPS."
+  exit
+fi
+
+USER=`echo $REPO_URL | sed -Ene's#https://github.com/([^/]*)/(.*).git#\1#p'`
+if [ -z "$USER" ]; then
+  echo "-- ERROR:  Could not identify User."
+  exit
+fi
+
+REPO=`echo $REPO_URL | sed -Ene's#https://github.com/([^/]*)/(.*).git#\2#p'`
+if [ -z "$REPO" ]; then
+  echo "-- ERROR:  Could not identify Repo."
+  exit
+fi
+
+NEW_URL="[email protected]:$USER/$REPO.git"
+echo "Changing repo url from "
+echo "  '$REPO_URL'"
+echo "      to "
+echo "  '$NEW_URL'"
+echo ""
+
+CHANGE_CMD="git remote set-url origin $NEW_URL"
+`$CHANGE_CMD`
+
+echo "Success"

.travis/script.sh

@@ -0,0 +1,32 @@
+#!/bin/bash
+
+# Exit on first error, print all commands.
+set -ev
+set -o pipefail
+
+# Grab the Concerto directory.
+DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )/.." && pwd )"
+
+# Start the X virtual frame buffer used by Karma.
+if [ -r "/etc/init.d/xvfb" ]; then
+    export DISPLAY=:99.0
+    sh -e /etc/init.d/xvfb start
+fi
+
+# Are we running system tests?
+if [ "${SYSTEST}" != "" ]; then
+
+    # Run the system tests.
+    ${DIR}/packages/composer-systests/scripts/run-system-tests.sh
+
+# We must be running unit tests.
+else
+
+    # Run the unit tests.
+    npm test 2>&1 | tee
+
+    # Build the Composer UI.
+    cd ${DIR}/packages/composer-ui
+    npm run build:prod
+
+fi

CONTRIBUTING.md

@@ -0,0 +1,69 @@
+# Contributing to Concerto
+We welcome contributions to Concerto!
+
+This document explains how you should work with the Concerto repository.  More information is in the 'contrib-docs' directory.
+
+* [Suggested ATOM setup](./contrib-notes/atom-setup.md)
+* [Step-by-step developement environmnet setup](./contrib-notes/getting-started.md)
+
+## Our development process
+
+All work on Concerto is performed on GitHub Enterprise. Changes should be developed in a fork of the Concerto repository, and the changes submitted for approval in the form of pull requests.
+
+| Workflow |
+| :-----: |
+|![Workflow diagram](docs/source/png/Contributing.Diagram.png)|
+
+### `develop` branch
+
+All changes and pull requests should be targeted at the `develop` branch. The `develop` branch has been configured as the default branch for the Concerto repository. When you create a pull request, a Travis CI build will automatically run to confirm that your changes build cleanly and pass all known tests. Your changes will **not** be merged into the `develop` branch unless this build runs cleanly.
+
+### `master` branch
+
+We try to keep the `master` branch as stable as possible. Changes are regularly pushed from the `develop` branch up to the `master` branch once they have been confirmed to be *good*. Only specific members of the IBM Blockchain WW Labs team have permission to push to the `master` branch.
+
+### Testing
+
+All changes pushed to Concerto should include unit tests that ensure that the new functionality works as designed, or that fixed bugs stay fixed. Pull requests that add code changes which are not covered by automated unit tests will **not** be accepted.
+
+Unit testing is for ensuring that small units of code *Do The Right Thing*, with an extremely quick turnaround time. An example of this might be the `AssetRegistryFactory.create()` method. The code in this method *probably* needs to do two things; send the correct invoke request to the chain-code, and correctly handle all of the possible responses from that chain-code.
+
+We do not need to stand up the Hyperledger Fabric to unit test this method; we simply need to ensure that the correct calls are made to the **hfc** library. Infact, testing against a running Hyperledger Fabric can actually make this harder - especially when we need to test our code for handling errors and timeouts from the **hfc** library. It is much easier and quicker to inject errors and timeouts into a *mocked* **hfc** library.
+
+Additionally, the Hyperledger team have added unit test support for chain-code. This means that chain-code can be tested as a separate unit, leading to tests such as: given world state *X*, and invoke request *Y*, is the invoke request *Y* successful and is the world state updated correctly?
+
+Obviously, unit testing is not sufficient, and we do need to test the framework against a running Hyperledger Fabric to ensure that the system works as a whole. This is additional functional, system, and performance testing that should automatically be run after the unit test phase. However, these additional testing phases are not yet in place, and so are not currently documented.
+
+We use **mocha** to execute our JavaScript unit tests, and these unit tests can be executed locally with `npm test`. All JavaScript code should include unit tests that can be run without requiring a running Hyperledger Fabric.
+
+We use the testing package built into Go for our Go unit tests, and these unit tests can be executed with `go test`. All Go code (primarily chain-code) should include unit tests that can be run without requiring a running Hyperledger Fabric.
+
+Unit tests should aim for 100% code coverage. For JavaScript code, we use Istanbul is used to ensure that the unit tests meet minimum levels of code coverage.
+
+### Documentation
+
+We use **jsdoc** for our API documentation. If you change APIs, update the documentation. Note that the linter settings
+will enforce the use of JSDoc comments for all methods and classes. We use these comments to generate high-quality
+documentation and UML diagrams from source code. Please ensure your code (particularly public APIs) are clearly
+documented.
+
+### Pull requests
+
+*Before* submitting a pull request, please make sure the following is done:
+
+1. Fork the repo and create your branch from `develop`.
+2. If you've added code that should be tested (always), add tests!
+3. If you've changed APIs, update the documentation.
+4. Ensure the test suite passes (`npm test` and `go test`).
+5. Make sure your code lints.
+
+## Style guide
+
+Our linter **eslint** will catch most styling issues that may exist in your code. You can check the status of your code styling by simply running `npm lint`.
+
+### Code conventions
+
+* 4 spaces for indentation (no tabs)
+* Prefer `'` over `"`
+* `'use strict';`
+* JSDoc comments are required

README.md

@@ -1,2 +1,29 @@
-# Concerto
-Concerto is the Blockchain Solution Framework: a library of assets/functions for quickly creating blockchain-based applications.
+# Fabric Composer
+Fabric Composer is a blockchain Solution Framework for Hyperledger Fabric: a library of assets/functions for quickly creating blockchain-based applications.
+
+You must run the following commands in order to pull the chaincode dependencies down from
+their repositories:
+
+    $ git submodule init
+    $ git submodule update
+
+You should see messages indicating that the required git repositories have been cloned into the correct
+vendor subdirectory.
+
+You must install [Lerna](https://lernajs.io) to build this multi-package repository.
+
+    $ npm install -g lerna
+
+Once Lerna is installed, and this repository is cloned, then you must bootstrap the
+repository so that all of the dependencies are installed and all of the packages are
+linked together:
+
+    $ lerna bootstrap
+
+You can then work with the packages under [packages/](packages/) on a per-package
+basis as any normal node.js package.
+
+Alternatively, you can execute npm commands across all of the packages at once using
+Lerna:
+
+    $ lerna run test